3.7.2数据库系统-数据库控制技术：数据库的安全性、数据库备份与恢复技术、数据备份、数据库故障与恢复
- 数据库的安全性
- 数据库备份与恢复技术
- 数据备份
- 数据库故障与恢复
数据库的安全性
在做信息系统开发的过程当中，数据库是其中很大的占比，信息系统的安全来说的话，数据库页式其中比较重要的一个板块。信息系统的安全性一方面可以通过数据库管理系统自身的机制来控制，也可以通过应用程序来实现对数据库的访问和控制。
这里介绍下数据库安全性的措施和方案。
| 措施 | 说明 |
|---|---|
| 用户标识和鉴定 | 最外层的安全保护措施，可以使用用户账户、口令及随机数检验等方式 |
| 存取控制 | 对用户进行授权，包括操作类型（如查找、插入、删除、修改等动作）和数据对象（主要是数据范围）的权限。（Grant和Revoke） |
| 密码存储和传输 | 对远程信息用密码传输 |
| 视图的保护 | 对视图进行授权 |
| 审计 | 使用一个专用文件或数据库，自动将用户对数据库的所有操作记录下来 |
数据库备份与恢复技术
数据备份
- 冷备份也称为静态备份，是将数据库正常关闭，在停止状态下，将数据库的文件全部备份（复制）下来。现在正常数据库都是7×24小时不间断运行，因此热备份比较多。
- 热备份也称为动态备份，是利用备份软件，在数据库正常运行的状态下，将数据库中的数据文件备份出来。
| 优点 | 缺点 | |
|---|---|---|
| 冷备份 | 非常快速的备份方法（只需复制文件）；容易归档（简单复制即可）；容易恢复到某个时间点上（只需将文件再复制回去）；能与归档方法结合，做到数据库”最佳状态“的恢复；低度维护，高度安全 | 单独使用时，只能提供到某一时间点上的恢复；在实施备份的全过程中，数据库必须要作备份而不能做其它工作；若磁盘空间有限，只能在复制到磁带等其他外部存储设备上，速度会很慢；不能按表或用户恢复 |
| 热备份 | 可在表空间或数据库文件级备份，备份的时间短；备份时数据库仍可使用；可达到秒级恢复（恢复到某一时间点上）；可对几乎所有数据库实体做恢复；恢复是快速的 | 不能出错，否则后果严重；若热备份不成功，所得结果不可用于时间点的恢复；困难于维护，所以要特别小心，不允许”以失败告终“ |
- 完全备份（海量备份）：备份所有数据，
- 差量备份：仅备份上一次完全备份之后变化的数据
- 增量备份：备份上一次备份之后变化的数据
完全备份，也叫海量备份：可以将所有数据都备份下来，数据量大，备份时间长，效率相比于其它(差量备份/增量备份)的较慢，但是后面的，差量备份/增量备份这种，必须遵循上一次备份变化后的数据来进行备份，一般是三者相结合来使用的。
差量备份和增量备份：数据量小，但是如果需要恢复的时候，需要找到前一次备份的文件才能进行恢复。
备份的时候都会有一个时间结点去执行，比如有些喜欢计划在星期天晚上的0点或1点进行备份，但是数据库的崩溃可不看你这个时间点，一般可能出现崩溃的时间点是在两次备份过程之间，这样除了要恢复备份文件，还需要去查看日志文件，做相应的恢复操作。
日志文件：事务日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。一个事务的完成，一般是遵循先写日志，再写数据库的原则，这样都完成了才算是一个事务完成。而在数据库崩溃的过程中，会有以下情况：
- 日志记录了，也写数据库：这个时候，根据记录的修改情况，重新写一遍
- 日志记录了，没写数据库：这个时候，因为没有真正的完成，因此要对这一部分数据内容进行撤销
- 日志没记录：这个时候，压根没看到事务
日志和备份通常会结合起来来使用。平时做数据库备份的时候，可以自己做计划，一般是数据库管理员去做计划。
如上图，假如周六崩溃了，需要恢复。流程如下
- 先找到完全备份的文件，A
- 找到离A最近的差备，即周五的，B+C+D+E+F
- 再找到离B+C+D+E+F最近的增备(没有就不管)，即G
- 综合才是完整的备份文件数据
- 再加上日志文件分析相关数据
数据库故障与恢复
| 故障关系 | 故障原因 | 解决方法 |
|---|---|---|
| 事务本身的可预期故障 | 本身逻辑 | 在程序中预先设置Rollback语句 |
| 事务本身的不可预期故障 | 算术溢出、违反存储保护 | 由DBMS的恢复子系统通过日志，撤销事务对数据库的修改，回退到事务初始状态 |
| 系统故障 | 系统停止运转 | 通常使用检查点法（系统重启时自动完成，用户不需干预，基本的步骤是： 通过日志文件，由日志的尾部，从尾部向头部反向扫描，扫描每一个事务有没有成功完成的标志； 如果成功完成了，说明数据库此时有修改，所以已完成的会重新做一遍相关的修改，这部分事务会放在重做的队列中去，即REDO队列； 那么有部分是没有看到正常完成状态的，此时就需要将前面没有完成事务操作的撤销，会把相应的事务放入UNDO队列，然后进行撤销） 系统故障通常可以使用检查点的方式进行恢复，所谓的检查点的方法：就是在一个检查点中记录它的内容，包括这个检查点的时间和当前时刻正在执行的事务的清单，以及这些事务最近一个日志它记录的地址，方便我们利用相应的检查点进行恢复，恢复的时候，从相应地址找到日志的位置(即最后一个检查点记录)，然后对正在执行的任务清单来建立UNDO和REDO的队列，建立队列之后，按之前的描述进行重做或者撤销，直到日志结束。 |
| 介质故障 | 外存被破坏 | 一般使用日志重做业务 |
- 撤销事务（UNDO）：反向扫描故障发生时未完成的事务，放入Undo撤销
- 重做事务（REDO）：正向扫描故障发生前已提交的事务，放入Redo重做
