adb08_系统故障与恢复分析报告.ppt

2、基于Redo日志的恢复 恢复的基础 没有Commit,T记录的操作必定没有改写磁盘数据，因此在恢复时可以不理会 Differ from Undo logging 有Commit,T记录的结果可能还未写回磁盘，因此在恢复时要Redo Still differ from Undo logging 3、Undo vs. Redo Undo基于立即更新 (Immediately Update) Redo基于延迟更新 (Deferred Update) 3、Undo vs. Redo T1:  Read (A,t); t ? t －100; Write (A,t); Flush Log Output (A); Read (B,t); t ? t + 100; Write (B,t); Flush Log Output (B); Flush Logcommit T2:  Read (A,t); t ? t －100; Write (A,t); Read (B,t); t ? t + 100; Write (B,t); Flush Log commit Output (A); Output (B); 立即更新日志(Undo log) 延迟更新日志(Redo log) More IOs But less buffers More buffers But less IOs 六、Undo/Redo日志 在x被写到磁盘之前，对应该修改的日志记录必须已被写到磁盘上 (WAL) 日志中的数据修改记录 T, x, v, w  - - v is the old value, w is the new value 可以立即更新，也可以延迟更新 1、基于Undo/Redo日志的恢复 正向扫描日志，将commit的事务放入Redo列表中，将没有结束的事务放入Undo列表 反向扫描日志，对于T,x,v,w，若T在Undo列表中，则 Write(x,v); Output(x) 正向扫描日志，对于T,x,v,w，若T在Redo列表中，则 Write(x,w)； Output(x) 对于Undo列表中的T,写入abort,T 1、基于Undo/Redo日志的恢复 发生故障时的日志 Start,T1 T1,B,2000,1900 Start,T2 T2,A,1000,900 Commit,T1 Start,T3 T3,C,3000,2000 T3,B,1900,1800 Commit,T2 Start,T4 T4,D,1000,1200 Undo列表 {T3,T4}; Redo {T1,T2} UndoT4: D=1000T3: B=1900T3: C=3000 RedoT1:B=1900T2:A=900 Write logAbort,T3Abort,T4 1、基于Undo/Redo日志的恢复 先Undo后Redo 发生故障时的日志 Start,T1 Start,T2 T1,A,1000,1200 T2,A,1000,1100 Commit,T2 T1要UNDO，T2要REDO 如果先REDO，则A＝1100；然后在UNDO，A＝1000。不正确 先UNDO，A＝1000；然后REDO，A＝1100。正确 七、检查点(checkpoint) 当系统故障发生时，必须扫描日志。需要搜索整个日志来确定UNDO列表和REDO列表 搜索过程太耗时，因为日志文件增长很快 会导致最后产生的REDO列表很大，使恢复过程变得很长 1、简单的检查点 Periodically: (1) Do not accept new transactions (2) Wait until all transactions finish (commit/abort) (3) Flush all log records to disk (log) (4) Flush all buffers to disk (DB) (5) Write “checkpoint” record on disk (log) (6) Resume transaction processing 2、基于检查点的恢复 t0 t1 t2 检查点 运行事务 故障发生点 扫描t0开始的日志文件进行恢复 无检查点时 扫描检查点开始的日志文件进行恢复 基于检查点的恢复 检查点技术保证检查点之前的所有commit操作的结果已写回数据库，在恢复时不需REDO 2、基于检查点的恢复 T1 T2 T3 T4 T5 Start CHPT ts te tf 故障点 时间 恢复时：UNDO＝{T5}, REDO＝{T4} T1、T2和T3由于