数据库 的 恢复策略

事务故障的恢复

事务故障是指事务在运行至正常终止点前被终止，这时恢复子系统应利用日志文件撤销（UNDO）此事务已对数据库进行的修改。

系统恢复的步骤：

（1）反向扫描日志文件（即从最后向前扫描日志文件），查找该事物的更新操作。

（2）对该事务的更新操作执行逆操作。即将日志记录中"更新前的值"写入数据库。这样如果记录中是插入操作，则相当于做删除操作；若记录中是删除操作，则做插入操作；若是修改，则相当于修改前值代替修改后值。

（3）继续反向扫描日志文件，查找该事务的其他更新操作，并作同样处理。

（4）如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。

系统故障

系统故障的恢复是由系统在重新启动时候自动完成的，不需要用户干预。

系统的恢复步骤是：

（1）正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交的事务（这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录），将其事务标识记入重做（REDO）队列。同时找出故障发生时尚未完成的事务（这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录）,将其事务标识记入撤销队列。

（2）对撤销队列中的各个事务进行撤销（UNDO）处理。

进行UNDO处理的方法是，反向扫描日志文件，对每一个UNDO事务的更新操作执行逆操作，将将日志记录中"更新前的值"写入数据库（该方法和事务故障的解决方法一致）。

（3）对重做队列中的各个事务进行重做（REDO）处理。

进行REDO处理的方法是：正向扫描日志文件，对每一个REDO事务从新执行日志文件登记的操作。即将日志记录中"更新后的值"写入数据库。

具有检查点的恢复技术

利用日志技术进行数据库恢复时，恢复子系统必须搜索日志，确定哪些事务需要REDO,哪些事务需要UNDO。一般来说，需要检查所有的记录。这样做有两个问题。一是搜索整个日志将消耗大量的时间。二是很多需要REDO处理的事务实际上已经将它们的更新操作结果写到数据库中了，然而恢复子系统又重新执行了这些操作，浪费了大量时间。

检查点的理解

###首先查看有几个检查点，找到里故障最近的一次检查点，之后看看哪些事务执行的时间是在检查点之前完成的
（1）如果事务在检查点之前完成的则不需要REDO（如:T1）
（2）如果事务在检查点之前执行，在检查点之后故障之前提交则需要REDO(如：T2,T4)
（3）如果事务在故障后，则需要执行UNDO(如：T3,T5)