第10章事务管理与恢复.pptVIP

UNDO操作 对于要UNDO的事务T，日志中记录有T, START以及T对数据库的所有更新操作的日志记录。 UNDO过程为：从T的最后一条更新日志记录开始，从日志尾向日志头(反向)依次将T更新的数据元素值恢复为旧值(V1)。 如果增加一条规则：T对数据库的所有更新值在日志T, COMMIT写到磁盘前不能写到磁盘。这样，如果没有看到事务T 的T, COMMIT日志记录，就可以确定T的更新值一定没有写到磁盘，从而可避免UNDO操作。 * REDO操作 与UNDO相反，REDO操作是对已提交事务进行重做，将数据库状态恢复到事务结束后的状态。 对于要REDO的事务T，日志中已经记录了T, START、T的所有更新操作日志以及T, COMMIT。 REDO过程为：从T的第一条更新日志记录开始，从日志头向日志尾(顺向)依次将T更新的数据元素值恢复为新值(V2)。 如果增加一条规则：事务对数据库的所有更新值必须在提交日志Ti, COMMIT写到磁盘之前写到磁盘，就可以避免REDO操作。 * 基于日志恢复策略举例 [例10.10] 考虑订票事务T1和T2，除更新航班的剩余票数A外,还分别需更新售票点的售出票数X和Y。假设先执行T1，再执行T2，几种可能的日志记录如图10-19所示。 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-19 T1和T2串行执行的三种日志情形 * 基于日志恢复策略举例 情形(a)： T1完成WRITE(A)后系统发生崩溃。当系统重启动时，检查到有T1, START，但没有T1, COMMIT。因此恢复时执行UNDO(T1)，将X和A的值分别恢复为0和10。 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-19 T1和T2串行执行的三种日志情形 * 基于日志恢复策略举例 情形(b) ：T2完成WRITE(A)后系统发生崩溃。这时需分别执行两个恢复操作UNDO(T2)和REDO(T1)，因为T1既有T1, START，又有T1, COMMIT日志，而T2只有T2, START日志。恢复完成后X、Y和A的值分别为2、0和8。 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-19 T1和T2串行执行的三种日志情形 * 基于日志恢复策略举例 情形(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-19 T1和T2串行执行的三种日志情形 * 并发执行事务的基本恢复过程 三个阶段： 分析阶段：从日志头开始顺向扫描日志，确定重做事务集（REDO-set）和撤销事务集（UNDO-set）。将既有T, START又有T, COMMIT日志记录的事务T加入REDO-set；将只有