数据库 - 恢复策略与数据库镜像

登记日志文件

基本原则
登记的次序严格按并行事务执行的时间次序
必须先写日志文件，后写数据库
写日志文件操作：把表示这个修改的日志记录
写到日志文件
写数据库操作：把对数据的修改写到数据库中

为什么要先写日志文件 (The Write-Ahead Log)
写数据库和写日志文件是两个不同的操作
在这两个操作之间可能发生故障
如果先写了数据库修改，而在日志文件中没有登记下这个修改，则以后就无法恢复这个修改了
如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性

事务故障的恢复

事务故障：事务在运行至正常终止点前被终止
恢复方法
由恢复子系统应利用日志文件撤消（UNDO）此事务已对数据库进行的修改
事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预

事务故障的恢复步骤

1. 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。
2. 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值” 写入数据库。
   插入操作， “更新前的值”为空，则相当于做删除操作
   删除操作，“更新后的值”为空，则相当于做插入操作
   若是修改操作，则相当于用修改前值代替修改后值
3. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
4. 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。

系统故障的恢复

系统故障造成数据库不一致状态的原因
未完成事务对数据库的更新已写入数据库
已提交事务对数据库的更新还留在缓冲区没来得及写入数据库
恢复方法
1. Undo 故障发生时未完成的事务
2. Redo 已完成的事务
系统故障的恢复由系统在重新启动时自动完成，不需要用户干预

1.正向扫描日志文件（即从头扫描日志文件）
重做(REDO) 队列: 在故障发生前已经提交的事务
这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录
撤销 (Undo)队列:故障发生时尚未完成的事务
 这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录