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过)
