数据库的恢复

一、恢复的实现技术

恢复机制设计的两个关键问题：
1、 如何建立冗余数据
2、如何利用这些冗余数据实施数据库恢复。
建立冗余数据最常用的技术是数据转储和登记日志文件。

1、数据转储

数据转储是数据库恢复中常用的基本技术。数据转储就是数据库管理员定期将整个数据库复制存储介质上保存起来的过程。这些备用数据称为后备副本或后援副本。
当数据库遭到破坏后可以将后备副本重新装入，但重装后备副本只能将数据恢复到转储时的状态，要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务。
转储和恢复图例：

备注：转储十分耗费时间和资源，不能频繁进行。转储可分为静态转储和动态转储。
1、静态转储：在系统中无进行事务时进行的转储操作。即转储操作开始的时刻数据库处于一致性状态，而转储期间不允许（或不存在）对数据库的任何存取、修改活动。它必须等待正在进行的用户事务结束才能进行。同样新的事务必须等待转储结束才能进行。显然会降低数据库的可用性。
2、动态转储：转储期间允许对数据库进行存取或修改。即转储和用户事务可以并发执行。它可以克服静态转储的缺点，不用等到正在运行的用户事务结束，也不会影响新事务的运行，但是转储结束时后援副本上的数据并不能保证正确有效。
转储还可以分为海量转储和增量转储。
1、海量转储：每次转储全部数据库。
2、增量转储：每次只转储上一次转储后更新过的数据。
从恢复的角度看，使用海量转储得到的后备副本进行恢复一般说来会更方便，但如果数据库很大，事务处理又十分频繁，则使用增量转储更实用有效。

2、登记日志文件

为了克服动态转储的缺点，必须把转储期间各事务对数据库的修改活动登记下来，建立日志文件。这样后援副本加上日志文件就能把数据库恢复到某一时刻的正确状态。
日志文件是用来记录事务对数据库的更新操作的文件。它分为以记录为单位和以数据库为单位的日志文件。
1、以记录为单位的日志文件需要登记：
1. 各个事务的开始（BEGIN TRANSACTION）标记。
2. 各个事务的结束（COMMIT或ROLLBACK）标记。
3. 各个事务的所有更新操作。
以上均作为日志文件中的一个日志记录。每个日志记录的内容主要包括：
1）事务标识（标明是哪个事务）
2）操作的类型（增删改）
3）操作对象（记录内部标识）
4）更新前数据的旧值（对插入操作而言，此项为空值）
5）更新后数据的新值（度删除操作而言，此项为空值）
2、以数据库块为单位的日志文件，日志记录的内容包括事务标识和被更新的数据块。由于将更新前的整个块和更新后的整个块都放入日志文件中，操作类型和操作对象等信息就不必放入日志记录中了。
3、日志文件的作用
日志文件可以用来进行事务故障恢复和系统故障恢复，并协助后备副本进行介质故障恢复。
1）事务故障恢复和系统故障恢复必须用日志文件。
2）在动态转储方式中必须建立日志文件，后备副本和日志文件结合起来才能有效地恢复数据库。
3) 在静态转储方式中也可以建立日志文件，当数据库毁坏后可重新装入后援副本把数据库恢复到转储和结束时刻的正确状态，然后利用日志文件把已完成的事务重做处理，对故障发生时尚未完成的事务进行撤销处理。这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态。
日志文件恢复图示：

4、登记日志文件
登记日志文件时应该遵循：
1）登记的次序严格按并发事务执行的时间次序。
2）必须先写日志文件，后写数据库。
把对数据的修改写到数据库中和把表示这个修改的日志记录到日志文件中是两个不同的操作。

二、恢复策略

1、事务故障的恢复

事务故障的恢复是指事务在运行至正常终止前被终止，这时恢复子系统应利用日志文件撤销（UNDO）此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成，对用户是透明的。系统的恢复步骤：
1. 反向扫描日志文件（即从最后向前扫描日志文件），查找该事务的更新操作。
2. 对该事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。这样，如果记录中是插入操作，则相当于做删除操作（因此时“更新前的值”为空）；若记录中是删除操作，则做插入操作；若是修改操作，则相当于用修改前值代替修改后值。
3. 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
4. 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。

2、系统故障的恢复

系统故障造成数据库不一致状态的原因：
1. 未完成事务对数据库的更新可能已写入数据库。
2. 已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。
因此恢复操作就是要撤销故障发生时未完成的事务，重做已完成的事务。系统故障的恢复是由系统在重新启动时自动完成的，不需要用户干预。
系统的恢复步骤：
1. 正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交的事务（这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录），将其事务标识记入重做队列（REDO-LIST）。同时找出故障发生时尚未完成的事务（这些事务只有BEGIN TRANSACTION记录），将其事务标识记入撤销队列（UNDO-LIST）。
2. 对撤销队列中的各个事务进行撤销处理。进行撤销处理的方法：反向扫描日志文件，对每个撤销事务的更新操作执行逆操作，即将日志记录中的“更新前的值”写入数据库。
3. 对重做队列中的各个事务进行重做处理。进行重做处理的方法：正向扫描日志文件，对每个重做事务重新执行日志文件登记的操作，即将日志记录中“更新后的值”写入数据库。

3、介质故障的恢复

发生介质故障后，磁盘上的物理数据和日志文件被损坏，这是最严重的一种故障，恢复方式是重装数据库，然后重做已完成的事务。
1. 装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到最近一次转储时的一致性状态。
对于动态转储的数据库副本，还需同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO），才能将数据库恢复到一致性状态。
2. 装入相应的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务，即首先扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。
介质故障的恢复需要数据库管理员介入，但数据库管理员只需要按重装最近转储的数据库副本和有关的各日志文件副本，然后执行系统提供的恢复命令即可，具体的恢复操作仍由数据库管理系统完成。

三、具有检查点的恢复技术

利用日志技术进行数据库恢复时，恢复子系统必须搜索日志，确定哪些事务需要重做，哪些事务需要撤销。一般来说，需要检查所有日志记录，缺点是：搜索整个日志将耗费大量的时间，很多需要重做处理的事务实际上已经将它们的更新操作结果写到了数据库中，然而恢复子系统又重新执行了这些操作。浪费了大量时间。为了解决这些问题，又发展了具有检查点的恢复技术，就是在日志文件中增加一类新的记录–检查点记录，增加一个重新开始的文件，并让恢复子系统在登录日志文件期间动态第维护日志。
检查点记录包括：
1. 建立检查点时刻所有正在执行的事务清单。
2. 这些事务最近一个日志记录的地址。
重新开始文件用来记录各个检查点记录在日志文件中的地址。动态维护日志文件的方法是周期性地执行建立检查点、保存数据库状态的操作。具体步骤：
1. 将当前日志缓存区中的所有日志记录写入磁盘的日志文件上。
2. 在日志文件中写入一个检查点记录。
3. 将当前数据缓冲区的所有数据记录写入磁盘的数据库中。
4. 把检查点记录在日志文件中的地址写入一个重新开始文件。
恢复子系统可以定期或不定期地建立检查点，保存数据库状态。检查点可以按照预定的一个时间间隔建立（每一小时建立一个），也可也按照某种规则建立检查点（日志文件已写满一半建立一个）。
使用检查点可以改善恢复效率。当事务T在一个检查点之前提交，T对数据库所做的修改一定都已写入数据库，写入时间是在这个检查点建立之前或在这个检查点建立之时。这样，在进行恢复处理时，没有必要对事务T执行重做操作。
系统出现故障时，恢复子系统将根据事务的不同状态采取不同的恢复策略。系统使用检查点方法进行恢复的步骤：
1. 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录。
2. 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST。
这里建立两个事务队列：UNDO-LIST（需要执行UNDO操作的事务集合）和REDO-LIST（需要执行REDO操作的事务集合）。把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。
3. 从检查点开始正向扫描日志文件。
1）如有新开始的事务TI，把TI暂时放入UNDO-LIST队列；
2）如有提交的事务TJ，把TJ从UNDO-LIST队列移到REDO-LIST队列，直到日志文件结束。
4. 对UNDO-LIST中的每个事务执行UNDO操作，对REDO-LIST中的每个事务执行REDO操作。

四、数据库镜像

为避免磁盘介质出现故障影响数据库的可用性，许多数据库管理系统提供了数据库镜像功能用于数据库恢复。即根据数据库管理员的要求，字段把整个数据库或其中的关键数据恢复到另一个磁盘上，每当主数据库更新时，数据库管理系统自动把更新后的数据复制过去，由数据库管理系统自动保证镜像数据与主数据库的一致性。这样，一旦出现介质故障，可由镜像磁盘继续提供使用，同时数据库管理系统自动利用镜像磁盘数据库进行数据库的恢复，不需要关系系统和重装数据库副本。在没出现故障时，数据库镜像还可以用于并发操作，即当一个用户对数据加排他锁修改时，其他用户而言读镜像数据库上的数据，而不必等待该用户释放锁。
数据镜像图示：
由于数据库镜像是通过复制数据实现的，频繁地复制数据自然会降低运行效率，因此实际应用中用户往往只选择对关键数据和日志文件进行镜像，而不是对整个数据库进行镜像。