第9篇 数据库恢复技术.ppt

第9章 数据库恢复技术 9.1 DB恢复问题及其处理概述 9.1.1 DB故障类型 9.1.2 DB故障恢复策略 1. 灾难性或磁盘失败恢复 可用的保障性技术 各种磁盘校验技术、RAID技术； 周期性数据转储备份，包括远程或异地备份。 2. 系统故障的恢复 系统故障会造成DB不一致状态 恢复方法 撤销(UNDO) 故障发生时未完成事务对DB的所有影响，确保事务的原子性。 重做(REDO)已成功提交的已完成事务,实现事务持久性 一般由系统在重新启动时自动完成，不需要用户干预。 9.1.3 数据存取的有关概念 9.1.4 事务写操作相关问题 1. 写缓存页到磁盘问题 只有事务写操作才存在需要恢复问题。出于简单性，本章讨论时，我们采用如下两点假设 : 写一个缓存页到磁盘的动作是原子的，即DBMS不会写不完整页到磁盘 . 在恢复机制中，总使用基于封锁的调度协议。特别地，在页面级封锁时采用Strict 2PL封锁协议。 当一个页输出到磁盘时, 其上不能有正在进行的更新。下列方法可以确保这一点： 修改数据元素之前，事务在包含数据元素的缓存页上获得排它锁；一旦完成写，锁即可释放。这种持有时间很短的锁称为闩(latch)。 2. 与缓冲池管理有关的两个额外问题 9.1.4 事务写操作相关问题 1. 写缓存页到磁盘问题 2. 与缓冲池管理有关的两个额外问题 当需要新页时, 如果缓冲池已满, 则需要置换一个缓存页，将一个现有页移出缓冲池。 如果所选的移出页被更新过, 则必须将它输出到磁盘。 9.2 数据库日志 9.2.3 检查点技术 1. 问题的提出 由于日志记录了所有修改动作的必要信息，使得我们可以重复历史，但代价可能非常昂贵。 撤销（UNDO）处理需要搜索整个日志 REDO处理：从头重新执行，浪费了大量时间 DB系统通过采用：周期性的创建一些检查点(checkpoint)技术，可大幅减小或降低恢复所需时间或工作量。 9.2.3 检查点技术 1. 问题的提出 2. 检查点实现的基本思想 在日志文件中增加检查点标志记录，并在检查点标志记录写到稳存之前，完成一些必要的、到现在为止的‘阶段性’归总工作； 当系统崩溃后重启时，重做扫描开始点和撤销回溯终点，就不再总是日志的首条记录。 它们都可通过分析最近可用检查点记录中的归总信息获得。 静态检查点和模糊检查点 系统建立一个检查点需要一定的时间。 根据建立检查点期间，是否允许继续执行事务，或启动新事务，可将检查点分为静态检查点和动态检查点。 静态检查点管理相对简单，但它会影响系统的性能。 动态检查点也称模糊检查点(fuzzy checkpoint )，它对系统系统影响不大，但管理相对复杂。 9.3 ARIES日志的系统崩溃恢复 ARIES恢复管理算法综述 采用基于“允许窃用页框且非强制页” 工作模式。 当系统崩溃后重启时，恢复管理器将被激活，并按以下三个阶段进行处理： 分析（Analysis）：鉴别崩溃发生时，缓冲区中的脏页和当时仍活跃的事务。 重做（Redo）：重做从日志的适当起点（比如，被修改的最早脏页对应日志记录）开始的所有动作，恢复系统到崩溃时的DB状态。 撤消（Undo）：撤消上次崩溃时所有未提交事务的动作效果，使DB只反映已提交事务的影响。 一个简单的ARIES日志片段示例 分析阶段将能分析识别出： 崩溃时仍活跃事务:T1,T3； 已提交事务T2 崩溃时的脏页P1、P3和P5。 注意，扫描LSN60不会再修改脏页表！ 在重做阶段，提交事务T2的所有动作，必须按日志顺序重新应用一次。 最后，在撤销阶段，T1和T3的所有动作，必须按日志记录的相反顺序，依次逐个撤销。 AREIS常规日志记录的结构模式 COMMIT、ABORT --LOGREC Commit LOGREC 当事务决定提交，它将先强制写一条类型为commit(内含该事务id)的日志记录到日志尾，并执行一次刷新当前日志尾到稳存的动作。 当事务的commit LOGREC写到稳存后，就可认为该事务已经提交 中止(abort) LOGREC 当一个事务中止时，一条类型为abort(内含事务id)的日志记录将被写到日志尾 还会启动一个撤消该事务的Undo过程。 end -LOGREC 当一个事务提交或中止后，除了稳定写commit或abort型日志记录外，DBMS还将执行一些额外的动作步骤。 当这些额外动作步都完成后，将会写一条(包含事务id、类型为)end日志记录到稳存。 稳定写end日志记录，也不能确保被修改的相关数据页已更新到磁盘。 对于commit事务，end记录只能保证该事务已被从事务表中移除。 CLR-LOGREC 当由一条更新日志记录U所记录的改变被撤销时，将会有一条类型为CLR的补偿日志记录C被写到