数据库课件CH10事务管理与恢复幻灯片.ppt

基于日志恢复策略举例 情形(c)：T2完成提交后系统发生崩溃。这时也需执行两个恢复操作REDO(T1)和REDO(T2)，因为T1和T2都有START和COMMIT日志。恢复完成后X、Y和A的值分别为2、3和5。 T1, START T1, X, 0, 2 T1, A, 10, 8 T1, START T1, X, 0, 2 T1, A, 10, 8 T1, COMMIT T2, START T2, Y, 0, 3 T2, A, 8, 5 T1, START T1, X, 0, 2 T1, A, 10, 8 T1, COMMIT T2, START T2, Y, 0, 3 T2, A, 8, 5 T2, COMMIT (a) (b) (c) 图10-18 T1和T2串行执行的三种日志情形 并发执行事务的基本恢复过程 三个阶段： 分析阶段：从日志头开始顺向扫描日志，确定重做事务集（REDO-set）和撤销事务集（UNDO-set）。将既有T, START又有T, COMMIT日志记录的事务T加入REDO-set；将只有T, START没有T, COMMIT日志记录的事务T加入UNDO-set。 撤销阶段：从日志尾反向扫描日志，对每一条属于UNDO-set中事务的更新操作日志依次执行UNDO操作。 重做阶段：从日志头顺向扫描日志，对每一条属于REDO-set中事务的更新操作日志依次执行REDO操作。 UNDO与REDO必须是幂等的，即重复执行任意次的结果与执行一次的结果是一样的。 引入检查点目的 利用日志文件恢复主要有两个问题： 日志扫描过程太耗时。因为日志文件必须保存在磁盘中，而且随着时间的不断推进，日志文件在不断扩大，扫描的时间也就变得越来越长。 许多要求REDO事务的更新实际上在恢复时都写入了磁盘的物理数据库中。尽管对它们做REDO操作不会造成不良后果，但会使恢复过程变得更长，导致数据库系统停止服务延长，从而降低了数据库的可用性。 为了减少扫描开销和提高恢复效率，引入了检查点技术。 检验点技术 检查点是周期性地向日志中写一条检查点记录并记录所有当前活跃的事务，为恢复管理器提供信息，以决定从日志的何处开始恢复。 检查点工作主要包括： 将当前位于日志缓冲区的所有日志记录输出到磁盘上； 将当前位于数据缓冲区的所有更新数据块输出到磁盘上； 记录日志记录Checkpoint L并输出到磁盘上，其中L是做检查点时活跃事务的列表。 静态检查点技术 在检查点执行过程中，不允许事务执行任何更新动作，如写缓冲块或写日志记录，称其为静态检查点技术。 如果事务T在做检查点之前就已提交，那么它的T, COMMIT记录一定出现在Checkpoint L记录前，并且其更新在做Checkpoint时都已写到磁盘中，因此不需要对T做任何恢复操作，这样可大大减少恢复工作量。 如果数据缓冲区及日志缓冲区中缓存的更新数据很多时，就会导致系统长时间不能接受事务处理，这对响应时间要求较严格的系统来说是不可忍受的。为避免这种中断，可使用模糊检查点(fuzzy checkpoint)技术，允许在做检查点的同时接受数据库更新操作。 基于检验点恢复方法 图10-19是系统崩溃时的不同事务状态类型，其中tc为完成最近检查点时刻，tf为故障发生时刻。 t tc tf T1 T5 UNDO T4 REDO T3 UNDO T2 REDO 图10-19 系统崩溃时不同状态事务的不同恢复处理 基于检验点恢复方法 T1类事务的更新在做检查点之前已经写到磁盘上，故不用做任何恢复操作。 t tc tf T1 T5 UNDO T4 REDO T3 UNDO T2 REDO 图10-19 系统崩溃时不同状态事务的不同恢复处理 基于检验点恢复方法 T2类事务在tc前的更新已写到磁盘，故重做时只需根据tc之后的日志记录进行REDO即可。 t tc tf T1 T5 UNDO T4 REDO T3 UNDO T2 REDO 图10-19 系统崩溃时不同状态事务的不同恢复处理 基于检验点恢复方法 T3类事务为在tc之前开始且在tf之前仍未结束的事务，这类事务需要全部撤销。 t tc tf T1 T5 UNDO T4 REDO T3 UNDO T2 REDO 图10-19 系统崩溃时不同状态事务的不同恢复处理 基于检验点恢复方法 T4类事务为在tc之后开始且在tf之前已完成的事务，这类事务需要全部重做。 t tc tf T1 T5 UNDO T4 REDO T3 UNDO T2 REDO 图10-19 系统崩溃时不同状态事务的不同恢复处理 基于检验点恢复方法 T5类事务为在tc之后开始且在tf之前仍未完成的事务，这类事务应全部撤销。 t tc tf T1 T5 UNDO T4 RE