数据库系统概论——恢复技术

一、数据库恢复概述

DBMS的子恢复系统必须确保故障发生后能够把数据库恢复到某种一致状态，最大限度地降低损失，并将崩溃后的数据库不能使用的时间减小到最小

1.1故障分类

1.1.1事务故障

某个事务在运行过程中由于种种原因未能运行到正常终止而夭折
两种错误导致事务执行失败

• 程序的逻辑错误
• 系统错误

1.1.2系统故障

由于某种原因造成整个系统的正常运行突然停止，致使所有正在运行的事务都以非正常方式终止
产生原因

• 操作系统或 DBMS代码错误
• 操作员操作失误
• 特定类型的硬件错误（CPU故障）
• 突然停电等

1.1.3介质故障

存储数据库的存储设备故障
产生原因

• 磁盘损坏
• 磁头碰撞
• 操作系统的某种潜在错误
• 瞬时强磁场干扰等

1.2恢复的基本思想

在系统正常运行时建立冗余数据，保证有足够的信息可用于故障恢复。故障发生后采取措施，将数据库内容恢复到某个一致性状态，保证事务原子性和持久性
数据库系统主要通过登记日志和数据转储建立冗余数据
利用冗余数据进行故障恢复考虑因素

• 存储器性质
• 事务的更新何时写入数据库
• 缓冲

二、基于日志的恢复技术

2.1日志

日志是日志记录的序列，记录了数据库中所有的更新活动

2.1.1日志记录的格式

一条更新日志记录了一个事务对数据库的一次 write操作，包括

• 事务标识符
• 操作类型
• 操作对象
• 旧值
• 新值

     --事务Ti开始
  --事务Ti对 Xj的一次更新，其中 V1是旧值，V2是新值。对于插入，V1为空；对于删除，V2为空
    --事务Ti正常提交
     --事务Ti异常终止

2.1.2登记日志的原则

日志记录必须严格按并发事务执行的时间次序登记
必须先记日志，后写数据库

2.1.3 redo和 undo

redo(Ti) 根据日志记录，按登记日志的次序，将事务 Ti每次更新的数据对象的新值用 write操作重新写到数据库（不是重新执行事务 Ti）
undo(Ti) 根据日志记录，按登记日志的相反次序，将事务 Ti每次更新的数据对象的旧值用 write操作写回数据库
redo和 undo都是幂等的，执行多次等价于执行一次

2.2延迟更新技术

延迟更新将事务对数据库的更新推迟到事务提交之后
遵循规则

1. 每个事务在到达提交点之前不能更新数据库
2. 在一个事务的所有更新操作的日志记录写入稳定存储器之前，该事务不能到达提交点

2.2.1基于延迟更新技术的事务故障恢复

事务 Ti发生故障时，Ti未到达提交点，因此Ti的更新操作都登记在日志中，并未输出到数据库
当事务 Ti发生故障时，只需清除日志中事务 Ti的日志记录，而无须对数据库本身做进一步处理。如果故障不是事务Ti本身的逻辑错误，则事务Ti可以在稍后重新启动

2.2.2基于延迟更新技术的系统故障恢复

1. 正向扫描日志文件，建立两个事务列表。一个是已提交事务列表，包含所有具有日志记录 的事务 Ti；另一个是未提交事务列表，包含所有具有日志记录 但不具有日志记录 的事务Tj
2. 对已提交事务列表的每个事务 Ti执行 redo(Ti)：正向扫描日志文件，对于每个形如 的日志记录，如果 Ti在已提交事务列表中，则将 Xj=V2写到数据库中

2.3即时更新技术

即时更新技术允许事务在活跃状态时就将更新输出到数据库当中
处于活动状态的事务直接在数据库上实施的更新称为非提交更新
遵循规则

1. 在日志记录 安全地输出到稳定存储器之前，事务 Ti不能用 Xi=V2更新数据库
2. 在所有 类型日志记录安全地输出到稳定存储器之前，不允许事务 Ti提交

2.3.1基于即时更新技术的事务故障恢复

事务 Ti发生故障时，它可能已经将某些更新输出到数据库，因此必须执行 undo(Ti)
反向扫描日志文件直到遇到 ，对于每个形如 的日志记录，将 Xj=V1写到数据库当中

2.3.2基于即时更新技术的系统故障恢复

1. 正向扫描日志文件，建立两个事务列表。一个是已提交事务列表，包含所有具有日志记录 的事务 Ti；另一个是未提交事务列表，包含所有具有日志记录 但不具有日志记录 的事务Tj
2. 对未提交事务列表的每个事务 Ti执行 undo(Ti)：反向扫描日志文件直到遇到未提交事务列表每个事务 Tk的 ，对于每个形如 的日志记录，如果 Ti在未提交事务列表中，则将 Xj=V1写到数据库中
3. 对已提交事务列表的每个事务 Ti执行 redo(Ti)：正向扫描日志文件，对于每个形如 的日志记录，如果 Ti在已提交事务列表中，则将 Xj=V2写到数据库中

三、基于检查点的恢复技术

3.1检查点

提高系统故障恢复效率的基本方法是使用检查点技术
假设系统在时刻 Tc设立最后一个检查点，在时刻 Tf发生系统故障，如图可以把事务分为五类

1. T1：在检查点之前提交
2. T2：在检查点之前开始执行，在检查点之后故障点之前提交
3. T3：在检查点之前开始执行，在故障点时还未完成
4. T4：在检查点之后开始执行，在故障点之前提交
5. T5：在检查点之后开始执行，在故障点时还未完成

3.2基于检查点的系统故障恢复

当系统故障发生时，首先要重新启动系统。系统重启后，恢复子系统自动执行以下步骤

1. 得到最后一个检查点记录：找到最后一个检查点记录在日志文件中的地址，取出最后一个检查点记录
2. 初始化两个事务列表 UNDO-LIST（需要执行 undo操作的事务集合）和 REDO-LIST（需要执行 redo操作的事务集合）：将 L中的所有事务都放入 UNDO-LIST，而 REDO-LIST为空
3. 建立两个事务列表 UNDO-LIST和 REDO-LIST：从最近的检查点开始，正向扫描日志文件直到结束，遇到 就把 Ti加入 UNDO-LIST；遇到 就把 Ti从 UNDO-LIST移到 REDO-LIST
4. 对 UNDO-LIST中的每个事务 Ti执行 undo(Ti)：反向扫描日志文件直到遇到未提交事务列表每个事务 Tk的 ，对于每个形如 的日志记录，如果 Ti在未提交事务列表中，则将 Xj=V1写到数据库中
5. 对 REDO-LIST中的每个事务 Ti执行 redo(Ti)：正向扫描日志文件，对于每个形如 的日志记录，如果 Ti在已提交事务列表中，则将 Xj=V2写到数据库中

四、介质故障恢复技术

4.1转储

将整个或部分数据库复制到磁带或另一个磁盘上，产生数据库后备副本
后备副本可以脱机保存，供介质故障恢复时使用

4.1.1静态转储与动态转储

从转储时是否允许事务运行角度考虑
静态转储是在系统中无运行事务时进行的转储；一定得到一个一致的副本，但降低了数据库的并发性
动态转储允许转储操作与用户事务并发执行，转储期间允许事务对数据库进行存取和更新；不能保证副本中数据的一致性

4.1.2海量存储与增量存储

从转储时是转储整个数据库还是部分数据库角度考虑
海量转储制作数据库的完整副本
增量转储只复制上此转储后更新过的数据，形成数据库的增量副本，增量副本不能单独使用
恢复时，必须使用最后一个完整副本和之后的所有增量副本才能将数据库恢复到一致状态

4.2介质故障恢复

当数据库被破坏时，需要用转储的后备副本和日志进行恢复，这里只考虑海量转储

1. 装入最新的数据库后备副本，将数据库恢复到最近一次转储时的状态
2. 装入转储后的日志，redo已完成的事务