chapter08_数据库恢复技术_2_数据库恢复

• 故障分类

  (1) 系统故障

  造成系统停止运行的故障，此时正在执行的所有事务将全部中断，内存中的事务数据丢失，可能会出现不一致的状态

  (2) 事务内部的故障

  死锁、运算溢出等导致事务处理出现错误、未达到预期终点(Commit或RollBack)的故障，导致事务的非正常结束

  (3) 存储设备故障

  介质破坏

  (4) 其他

• 数据库恢复策略综述

  (1) 事务故障的恢复

  利用__日志__文件撤销事务对数据的更改，系统回滚到事务执行前的状态，好像从来没有发生过事务一样

  日志文件：记录数据库所有更新操作，当事务故障发生时系统反向扫描日志文件、并逆向操作。

  (2) 系统故障的恢复

  系统故障不会破坏磁盘中的数据，但是会__丢失内存缓冲区中的数据__。

  此时有__两种可能__造成数据库状态不一致：一、未完成事务对数据的更新可能已经写入数据库；二、已完成事务对数据的更新可能还在缓冲区中未写入磁盘。

  恢复步骤：

  1° 扫描日志文件，找到__未完成事务__和__已完成事务__（区别是有无Commit）

  2° 正向扫描日志，重新执行Redo已完成事务

  3° 反向扫描日志，撤销Undo未完成事务

  (3) 存储故障的恢复

  依靠镜像磁盘

• 基于日志的数据库恢复

  (1) 日志记录的类型

  1° Start Ti：开始事务Ti

  2° Ti，Xj，V1，V2：Ti事务对数据项Xj进行写操作，操作前的值为V1，操作后的值为V2

  3° Commit Ti：提交事务Ti（表示事务执行成功，事务对数据库所做的任何更新都写入到__缓存区__中，但是不一定写到磁盘中了）

  4° Abort Ti：终止事务Ti

  (2) 事务操作写日志的过程

  1° 日志中写入 Start Ti

  2° Ti的每次write(X)操作__前__，都要__先__在日志中写入 Ti，Xj，V1，V2，然后才能更新数据

  3° 事务进入部分提交状态时，向日志中写入 Commit Ti

  (3) Redo技术

  故障发生后，系统扫描日志，对于日志中既包含 Start Ti 又包含 Commit Ti 的事务Ti，要重新执行Redo。

  系统按事务的提交顺序重做各个事务。

  (4) Undo技术

  故障发生后，系统扫描日志，对于日志中包含 Start Ti 但不包含 Commit Ti 的事务Ti，要重新执行Undo。

  Undo的过程是：从日志中读取Write记录(Ti，Xj，V1，V2)，按照写入时相反的顺序，将数据从新值恢复成旧值。即V2恢复成V1。

  (5) 日志文件可以恢复系统故障和事务故障，不能恢复存储故障

• 检查点恢复技术

  (1) 事务内部的故障仅需要恢复发生故障的个别事务，而系统故障可能会影响多个事务，此时扫描日志文件变成了一个耗时的过程。事实上，系统故障发生时仅影响少量事务，所以使用__检查点。__

  (2) 检查点；记录在日志中，表示数据库是否正常运行的一个标志。

  系统需要周期性的向日志中写入一条检查点，记录所有当前活动的事务。

  (3) 写检查点时的操作

  1° 把日志缓冲区中的内容写入日志

  2° 向日志文件写入一个检查点

  3° 把数据库缓冲区的内容写入数据库

  4° 把检查点在日志中的地址写入重启动文件

  写检查点时，不运行事务执行任何更新操作

  (4) 具有检查点的恢复时操作

  1° 从重启动文件找到最后一个检查点的地址

  2° 扫描得到检查点时刻的所有事务

  3° Redo已经完成的事务，Undo未完成的事务(判断完成/未完成的标准是是否Commit过)