第十章数据库恢复技术

第十章 数据库恢复技术
本章目的：数据库出现故障，使得部分或全部数据丢失，怎么办？
查询操作：将所需数据页从磁盘读入缓冲区，在内存中完成查询运算。该页不 必再写回磁盘。
更新操作：将所需数据页从磁盘读入缓冲区，在内存中完成数据的插入、修改 或删除。然后将该页写回磁盘。 数据库内存缓冲区 数据页 …… 数据页 磁盘
数据库镜像
问题：出现介质故障（也包括系统故障）时，数据库系统还能继续对外提供服 务吗？ • 可由镜像磁盘继续提供服务； • 同时DBMS自动利用镜像磁盘数据进行数据库的恢复； • 不需要关闭系统和重装数据库副本，当然也是有其他代价的。 例如
数据库镜像： • DBMS自动把整个数据库或其中的关键数据复制到另一个磁盘上； • DBMS自动保证镜像数据与主数据库的一致性，每当主数据库更新时， DBMS自动把更新后的数据复制过去。
故障示例
例如银行转账事务，把一笔金额从账户甲转给账户乙。 BEGIN TRANSACTION 读账户甲的余额BALANCE； BALANCE = BALANCE - AMOUNT； （AMOUNT 为转账金额） 写回BALANCE； IF( BALANCE < 0 ) THEN { 打印 '金额不足，不能转账'； 此即为事务内部可预期的故障。 ROLLBACK； 由于事务无法继续执行下去，由事务 } 自身进行处理。 ELSE { 读账户乙的余额BALANCE1； BALANCE1 = BALANCE1 + AMOUNT； 写回BALANCE1； COMMIT； 问题：这个事务编写的好吗？ }
事务内部故障的恢复
恢复方法：利用日志文件撤消此事务已对数据库进行的修改。 事务故障的恢复由DBMS自动完成，一般不需要用户干预。
具体过程： 1、反向扫描文件日志（即从后向前扫描），查找该事务的更新操作； 2、对该事务的更新操作执行逆操作； 3、继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理； 4、如此处理下去，直至读到此事务的开始标记，事务故障恢复完成。
故障示例（续）
对上述银行转账事务进行重新编写。 BEGIN TRANSACTION 读账户甲的余额BALANCE； BALANCE = BALANCE - AMOUNT； IF( BALANCE < 0 ) THEN { 打印 '金额不足，不能转账'； RETURN； } ELSE { 读账户乙的余额BALANCE1； BALANCE1 = BALANCE1 + AMOUNT； 写回BALANCE； 问题：要是在此处出现故障呢？ 写回BALANCE1； COMMIT； }
问题：你知道数据页什么时候写回磁盘吗？
事务
事务：用户定义的一个数据库操作序列，这些操作要么全做要么全不做。 • 是一个不可分割的工作单位，也是恢复和并发控制的基本单位； • 一个事务可以是一条或多条SQL语句，也可以是整个程序； • 一个程序通常包含多个事务（这也是事务与程序的区别之一）。 事务的显式定义 BEGIN TRANSACTION SQL语句1 SQL语句2 …… COMMIT BEGIN TRANSACTION SQL语句1 SQL语句2 …… ROLL省规定自动划分事务。 事务的提交：即将事务中所有对数据库的更新写回到磁盘的物理数据库中，事 务正常结束。 事务的回滚：即事务在运行过程中发生某种故障而不能继续执行，系统将事务 中对数据库的所有已完成的更新全部撤销，回滚到事务开始时的 状态。
事务的特性、事务故障及种类
日志及日志格式
日志：用来记录事务对数据库更新操作的文件。
日志文件的两种主要格式： 1、以记录为单位。日志记录的主要内容为： 事务开始标记 事务标识（标明是哪个事务） 操作类型（插入、删除或修改） 操作对象 更新前数据的旧值（对插入而言，则为空） 更新后数据的新值（对删除而言，则为空） 事务结束标记
系统故障的恢复
系统故障造成数据库不一致状态的原因： • 未完成的事务对数据库的更新可能已写入数据库； • 已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。
系统故障的恢复是由系统重新启动时DBMS自动完成，一般不需要用户干预。
恢复方法： 1、正向扫描日志文件（即从头扫描） ① 将既有事务开始，又有事务结束标志的已提交事务放至重做队列； ② 将只有事务开始，而无事务结束标志的事务放至撤销队列。 2、对撤销队列中的事务进行撤销处理，即将日志记录中“更新前的值”写入 数据库。 3、对重做队列中的事务进行重做处理，即将日志记录中“更新后的值”写入 数据库。 问题：这种恢复策略有什么问题吗？
事务的特性 • 原子性：即事务中的操作要么都做，要么都有不做； • 一致性：即事务的结果必须使数据库从一致性状态变到一致性状态； • 隔离性：即并发执行的各个事务之间不能互相干扰； • 持续性：即事务一旦提交，它对数据库中数据的改变就应该是永久性的。
事务故障：是指事务在运行至正常终止点前被终止。 常见故障大致可分为： 1、事务内务故障：是指事务本身存在问题。如运算溢出、并发事务死锁、违 反了某些完整性限制等。可以通过事务程序发现并处理； 也可能是非预期的，需要DBMS或DBA来处理。 2、系统故障：是指诸如CPU故障、操作系统故障、DBMS代码错误、系统断 电等，系统需要重新启动。 3、介质故障：是指数据库的物理存储介质出现问题，如磁盘损坏、外界强磁 干扰等。 4、计算机病毒：是指利用非正规程序更新数据库数据。 5、自然灾害等：可视为介质故障。
2、以数据块为单位。主要记录： 事务开始标记 事务标识 注意：此处不必记录操作类型和操作对象 更新前的数据块 更新后的数据块 事务结束标记
日志的作用和登记
日志文件的作用：后备副本和日志的结合才能有效地恢复数据库。 正常运行 Ta 介质故障恢复 静态转储 Tb 重装后备副本 运行事务 登记日志文件 利用日志文件恢复 继续运行 登记日志文件
具有检查点的恢复技术
上述系统故障恢复方法主要存在下列问题： • 搜索整个日志将耗费大量的时间。 • 很多需要重做的事务实际上已经将它们的更新数据写回到数据库中了，而 恢复时又重新执行了这些操作，又浪费了大量的时间。 解决办法：再增加一个“重新开始文件”，同时在日志文件中增加一类新的记 录 — 检查点记录。 • 检查点记录包括建立检查点时刻所有正在执行的事务清单； • 重新开始文件用来记录各个检查点记录在日志文件中的地址。
数据转储
数据恢复最常用的技术就是利用备份和日志。 转储：指DBA将整个数据库文件复制到磁带或另一磁盘上保存起来的过程。 • 备用的数据称为后备副本或后援副本。 • 转储十分耗费时间和资源，不能频繁进行。DBA应确定适当的转储周期。 • 静态转储：即系统中无运行事务时开始，转储期间不允许数据库更新。 • 动态转储：即转储和用户事务并发执行，转储期间允许数据库更新。 • 海量转储：即每次转储数据库的全部内容。 • 增量转储：即每次只转储上一次转储后更新过的数据。 • DBA应该制定适合的转储方式。 问题：若只有备份数据，当数据库数据发生灾难后，能恢复到什么程度呢？
问题：该结构如何 提高恢复效率?
利用检查点的恢复策略图示
系统出现故障时，恢复子系统将根据事务的不同状态采取不同的恢复策略。 Tc (检查点) T1 T2 T3 T4 T5 重做 撤销 无需处理 重做 撤销
Tf (系统故障)
时间
利用检查点的恢复策略
此时，维护日志文件的方法是周期性地执行下列操作： 1、将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上； 2、在日志文件中写入一个检查点记录； 3、将当前数据缓冲区的所有数据记录写入磁盘的数据库中； 4、把检查点记录在日志文件中的地址写入一个重新开始文件。 利用检查点的恢复策略： 1、从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地 址在日志文件中找到最后一个检查点记录； 2、由该检查点记录得到检查点建立时刻所有正在执行的事务清单A_LIST； 3、建立两个事务队列：UNDO_LIST队列和REDO_LIST队列； 4、将A_LIST暂时放入UNDO_LIST队列，REDO队列暂为空； 5、从检查点开始正向扫描日志文件，直到日志文件结束，如有新开始的事务 Ti，则将Ti暂时放入UNDO_LIST队列；如有已经提交的事务Tj，把Tj从 UNDO_LIST队列移到REDO_LIST队列； 6、对UNDO_LIST队列中的每个事务执行撤销操作； 7、对REDO_LIST队列中的每个事务执行重做操作。
问题：写日志内容和写数据库内容之间有先后顺序吗？ 日志登记的两条原则： • 登记的次序严格按并发事务执行的时间次序； • 必须先写日志，后写数据库。 问题：日志文件、数据文件、备份放在同一块磁盘上是好主意吗？ 若日志文件也损坏了呢？ 存放数据文件与日志文件的两块不同的磁盘同时损坏可能性大吗？ 日志文件大小会无限地增长吗？（不会的） 若进行了备份，则备份前的日志文件内容还有用吗？
数据库镜像的其它应用
• 当系统没出现故障时，数据库镜像还可以用于并发操作来提高系统效率。 • 但数据库镜像会降低系统效率。
介质故障的恢复
介质故障的恢复需要DBA介入。 • DBA需重装转储的数据库副本和有关的各日志文件副本； • 然后执行恢复命令，具体的由DBMS完成。 恢复方法： 1、 装入最新的后备数据库副本。 • 对静态转储的数据库副本，装入后数据库即处于一致性状态； • 对动态转储的数据库副本，还须装入转储开始时刻的日志文件副本。 2、 装入相应的日志文件副本，重做已完成的事务。