数据库：数据库恢复技术

1，数据库恢复概述

故障是不可避免的，它包括计算机硬件故障、软件的错误、操作员的失误和恶意的破坏。

故障的产生将会使运行事务非正常中断，影响数据库中数据的正确性；另外会破坏数据库，造成全部或部分丢失数据。

因此DBMS必须具有将数据库从错误状态恢复到某一已知的正确（一致）状态的功能，这就是数据库恢复功能，这就是数据库的恢复管理系统对故障的对策。

DBMS提供恢复子系统，它保证故障发生后，能把数据库中的数据从错误状态恢复到某种逻辑一致的状态，保证事务的ACID的特性。

恢复子系统是数据库管理系统的一个重要组成部分。

恢复技术是衡量系统优劣的重要指标。

2，故障种类

2.1，事务内部的故障

某个事务在运行过程中由于种种原因未运行至正常终点就终止了。

★造成事务非正常终止的原因：

• 有的是可以通过事务程序本身发现的
• 有的故障是非预期的，不能由事务程序自己来处理

事务故障意味着：事务没有达到预期的终点(COMMIT或者显式的ROLLBACK)，数据库可能处于不一致状态。

事务故障的恢复：事务撤消（UNDO）强行回滚（ROLLBACK）该事务，撤销该事务已经作出的任何对数据库的修改，使得该事务象根本没有启动一样。

2.2，系统故障

指造成系统停止运转的任何事件，使得系统要重新启动。

★造成系统故障的常见原因：​​​​​​

• 特定类型的硬件错误（如CPU故障）
• 操作系统故障
• 数据库管理系统代码错误
• 系统断电​​​​​

★系统故障的特征：

• 整个系统的正常运行突然被破坏
• 所有正在运行的事务都非正常终止
• 不破坏数据库
• 内存中数据库缓冲区的信息全部丢失

系统故障的恢复：

发生系统故障时，一些尚未完成的事务的结果可能已送入物理数据库，造成数据库可能处于不正确状态。

恢复策略：系统重新启动时，恢复程序让所有非正常终止的事务回滚，强行撤消（UNDO）所有未完成事务。

发生系统故障时，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，系统故障使得这些事务对数据库的修改部分或全部丢失

恢复策略：系统重新启动时，恢复程序需要重做（REDO）所有已提交的事务，将数据库真正恢复到一致状态

2.3，介质故障

介质故障指外存故障，使存储在外存中的数据部分丢失或全部丢失。

★造成介质故障的常见原因：

• 磁盘损坏
• 磁头碰撞
• 瞬时强磁场干扰

★介质故障破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务

★介质故障比前两类故障的可能性小得多，但破坏性大得多

3，恢复的实现技术

3.1，恢复的基本原理

恢复操作的基本原理：利用存储在系统其他地方的冗余数据（数据转储、登记日志文件）来重建数据库汇总已被破坏或不正确的数据。

3.2，数据转储

转储： 是指数据库管理员定期地将整个数据库复制到磁带、磁盘或其他存储介质上保存起来的过程，这些备用的数据文本称为后备副本或后援副本。

恢复： 当数据库被破坏后可将后备副本重新装入，并重新运行转储以后的所有更新事务。重装后备副本只能将数据库恢复到转储时的状态。

转储状态

静态转储：转储期间  不允许  对数据库进行操作

特点：静态转储得到的一定是一个数据一致性的副本。因为转储必须等用户事务全部结束才能进行，而且新的事务必须等待转储完毕才能开始执行。但数据库的可用性被降低。

动态转储：转储期间    允许    对数据库进行操作

特点：转储和用户事务可并发执行，即不必等待正在运行的事务结束，也不影响新事务的运行。但转储的数据可能已过时。利用动态转储得到的副本进行故障恢复时，需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件，后备副本加上日志文件就能把数据库恢复到某一时刻的正确状态。

转储方式

海量转储：每次转储全部数据库。从恢复角度看，使用海量转储得到的后备副本进行恢复往往更方便。

增量转储：只转储上次转储后更新过的数据。如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效。

转储方式	转储状态
	动态转储	静态转储
海量转储	动态海量转储	静态海量转储
增量转储	动态增量转储	静态增量转储

转储的策略

• 应定期进行数据转储，制作后备副本
• 但转储又是十分耗费时间和资源的，不能频繁进行
• DBA应该根据数据库使用情况确定适当的转储周期和转储方法

3.3，登记日志文件

日志文件：是用来记录事务对数据库的更新操作的文件。

日志文件的作用：

• 进行事务故障恢复
• 进行系统故障恢复
• 协助后备副本进行介质故障恢复

日志文件的格式：以记录为单位的日志文件和以数据块为单位的日志文件

日志文件的内容：

• 各个事务的开始标记(BEGIN TRANSACTION)
• 各个事务的结束标记(COMMIT或ROLLBACK)
• 各个事务的所有更新操作

以记录为单位的日志文件，每条日志记录的内容：

• 事务标识（标明是哪个事务）
• 操作类型（插入、删除或修改）
• 操作对象（记录ID、Block NO.）
• 更新前数据的旧值（对插入操作而言，此项为空值）
• 更新后数据的新值（对删除操作而言, 此项为空值）

以数据块为单位的日志文件，每条日志记录的内容：

• 事务标识
• 被更新的数据块

★事务故障恢复和系统故障恢复必须用日志文件

★在静态转储方式中，也可以建立日志文件。

• 当数据库毁坏后可重新装入后援副本，把数据库恢复到转储结束时刻的正确状态
• 利用日志文件，把已完成的事务进行重做处理
• 对故障发生时尚未完成的事务进行撤销处理
• 不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态

★在动态转储方式中，必须建立日志文件。

• 后备副本和日志文件结合起来才能有效地恢复数据库

 ★登记日志文件的原则

为保证数据库是可恢复的，登记日志文件时必须遵循两条原则

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

为什么要先写日志文件

写数据库和写日志文件是两个不同的操作，在这两个操作之间有可能发生故障，若先写数据库数据，再写日志的话，万一在写日志前发生故障，则这次的数据库修改未登记，从而不能恢复。若写日志后发生故障而未修改数据库，则事务一定未完成，在恢复时会执行撤消处理

4，恢复策略

4.1，事务恢复故障

事务故障：事务在运行至正常终止点前被终止

恢复方法：由恢复子系统利用日志文件撤消（UNDO）此事务已对数据库进行的修改

事务故障的恢复由系统自动完成，对用户是透明的，不需要用户干预

恢复步骤：①反向扫描日志文件（即从最后向前扫描日志文件），查找未完成事务的更新操作；

②对该事务的更新操作执行逆操作；

• 插入操作， “更新前的值”为空，则相当于做删除操作
• 删除操作，“更新后的值”为空，则相当于做插入操作
• 若是修改操作，则相当于用修改前值代替修改后值

③继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理；

④当遇到某事务的开始标记时，停止对该事务的处理。

⑤重复上述过程，直到所有未完成事务全部UNDO完毕。

4.2，系统故障的恢复

系统故障：系统故障造成数据库不一致的原因，一是未完成事务对数据库的更新已写入数据库，二是已提交事务的结果在故障发生前留在缓冲区没来得及写入数据库。

恢复方法：撤消（ Undo ）未完成事务，重做（ Redo ）已完成事务

系统故障的恢复由系统在重新启动时自动完成，不需要用户干预

恢复步骤：①正向扫描日志文件，找出在故障发生前已提交的事务，将它们记入重做（REDO）队列，同时找出故障发生前尚未完成的事务，将它们记入撤消（UNDO）队列。

②反向扫描日志文件，对UNDO队列的每个事务执行逆操作，即将日志记录中“更新前的值”写入数据库 。

③正向扫描日志文件，对REDO队列中的每个事务重新执行日志文件登记的操作，即将日志记录中“更新后的值”写入数据库 。

4.3，介质故障的恢复

介质故障：介质故障发生后，磁盘上的数据文件和日志文件均被破坏。

恢复方法：重装数据库和日志文件，然后重做自转储以来已完成的事务

恢复步骤：①装入最近转储的数据库后援副本(离故障发生时刻最近的转储副本)，使数据库恢复到最近一次转储时的一致性状态；若是静态转储的数据库副本，装入后数据库即处于一致性状态；若是动态转储，则还还须同时装入转储时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。

②装入有关的日志文件副本(转储结束时刻的日志文件副本) ，重做已完成的事务。首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列；然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。

系统故障与事务故障的恢复由系统自动完成，对用户透明，介质故障的恢复，需要DBA重装数据库和日志文件副本，然后执行相应的恢复命令。不论那种恢复，一般都要扫描整个日志文件。

当数据库被破坏时, 要重装后备副本, 然后利用日志文件执行事务恢复，重建数据库

 数据库本身未被破坏，但有些内容可能不正确，则可只利用日志文件恢复，使数据库回到某一正确状态。

4.4，具有检查点的恢复技术

利用日志文件恢复数据库，一般要扫描整个日志文件，日志是个流水帐，往往很长，这样做具有两个问题：

• 搜索整个日志文件将耗费大量的时间；
• 许多已提交事务的更新结果实际上已写入数据库中，重新做这些事务只会浪费大量的时间。

★因此，确定哪些事务需REDO，哪些不需REDO，就很有意义。解决的方法是在日志文件中设置检查点记录，增加重新开始文件，恢复子系统在登录日志文件期间动态地维护日志。

检查点记录的内容：建立检查点时刻所有正在执行的事务清单，这些事务最近一个日志记录的地址。

重新开始文件的内容：记录各个检查点记录在日志文件中的地址。

动态维护日志文件的方法：周期性地执行建立检查点，保存数据库状态的操作

步骤：

• 将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上
• 在日志文件中写入一个检查点记录
• 将当前数据缓冲区的所有数据记录写入磁盘的数据库中
• 把检查点记录在日志文件中的地址写入一个重新开始文件

恢复子系统可以定期或不定期地建立检查点,保存数据库状态

• 定期：按照预定的一个时间间隔，如每隔一小时建立一个检查点
• 不定期：按照某种规则，如日志文件已写满一半建立一个检查点

使用检查点方法可以改善恢复效率：在检查点之前已提交的事务对数据库的修改在检查点之前或检查点建立时已记入磁盘，只要数据库未被破坏，不需要对这些事务执行重做（REDO）。

利用检查点的恢复步骤：

①从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录

②设置两个队列，将检查点中的所有事务放入UNDO-LIST，并令REDO-LIST暂为空集；

• UNDO-LIST：需要UNDO操作的事务集合；
• REDO-LIST：需要REDO操作的事务集合；

③从该检查点开始扫描日志文件到文件结束为止： 凡遇有begin_transaction的事务放入UNDO-LIST； 凡遇有commit的事务,  将它从UNDO-LIST移入REDO-LIST；

④对UNDO-LIST中的事务执行UNDO操作； 对REDO-LIST中的事务执行REDO操作

5，数据库镜像

数据库系统发生故障时，可利用日志文件进行数据库恢复，但前提是日志文件必须完好。然而当发生介质故障时，往往不仅数据库被摧毁，日志文件也难逃恶运，此时恢复操作就无法实施。

解决方案：数据库镜像

数据库镜像：整个数据库或其中的关键数据同时存放在两个分离的物理磁盘上。每当主数据库更新时，DBMS自动把更新后的数据复制到另一个磁盘上，从而自动保证主数据库与镜像数据库的一致性。

出现介质故障时：可由镜像磁盘继续提供使用，同时数据库管理系统自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。

没有出现故障时：可用于并发操作，一个用户对数据加排他锁修改数据，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁。

数据库镜像的缺点：频繁地复制数据自然会降低系统运行效率，需要使用更多的磁盘设备，因此在实际应用中用户往往只选择对关键数据和日志文件镜像，不是对整个数据库进行镜像。

磁盘双工：用两个不同控制器控制的磁盘存放同一内容，对数据库的每个写操作，两个控制器同时实现。

双机热备份：用两台机器存放同一内容。