6.1.4 恢复的基本原则和实现方法

各类故障对数据库的影响有两种可能性：一是数据库本身未被破坏；二是数据库遭到破坏。不管怎样，数据库中的数据已处于不正确的状态，必须有相应的策略来解决，实施数据库恢复。数据库具有可恢复性的原则很简单，就是冗余（Redundancy），即数据的重复存储。利用存储在系统中的冗余数据，重新建立数据库中被破坏的不正确的数据。

实现方法有以下几种。

1. 周期性对数据库进行复制或转储

数据库恢复采用的一种基本手段就是数据转储。数据转储是指数据库管理员定期将整个数据库复制到至少一种存储设备（磁带或磁盘）上保存起来的过程。数据转储比较重要的一种途径就是将数据通过网络转储到远地的“数据银行”。这些存储在其他存储介质中用于备用的数据文本称为后援副本或后备副本，如果重新装入后备副本，可有效恢复遭到破坏的数据库。将数据库恢复到转储时的状态，然后重新运行自转储以后的所有更新事务，就可以恢复到故障发生时的状态。显然，转储是十分耗费时间和资源的，不能频繁进行，数据库管理员应当根据数据库的使用情况确定一个适当的转储周期。

2. 建立日志文件

日志文件是用于记录事务对数据库的更新操作（插入、删除、修改）的文件。每次对数据库进行修改时，这个修改的运行记录都要写入运行日志中，以备查阅，这个过程由DBMS的一个日志处理程序负责。

1）日志的主要内容

(1) 更新数据库的事务标志，即标明是哪个事务。

(2) 操作类型，即插入、删除、修改。

(3) 更新前数据的旧值，即插入操作，无旧值。

(4) 更新前数据的新值，即删除操作，无新值。

(5) 记录事务处理中的各个关键时刻。

日志文件的信息量很大，必须具有极高的可靠性，所以是双副本的，并独立保存在两个不同的海量存储设备上。

每进行一次对数据库的修改，就在运行日志中写入表示这个修改的运行记录，否则当两个操作之间发生故障时，在运行日志中找不到这个修改记录，就无法撤销这个修改。

2）登记日志文件遵循的原则

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

(1) 登记的次序严格按并发事务执行的时间顺序进行。

(2) 必须先写日志文件，后写数据库修改。

这两条原则表明：如果发生了系统故障，在日志文件中登记了所做的修改，但数据库还没有被修改，那么在重新启动系统进行恢复时，只撤销或重做因发生故障而没有做完的修改，并不影响数据库的正确性。否则，若先写数据库修改，而又没有在运行记录中登记这个修改，则以后就无法恢复这个修改了。所以一定要先写日志文件，后写数据库修改。

3. 恢复

针对不同的故障，其恢复的策略和方法也是不相同的。

1）事务故障的恢复

事务故障的恢复是由数据库系统自动完成的，恢复步骤如下。

(1) 从最后向前反向扫描日志文件，查找该事务的更新操作。

(2) 对该事务的更新操作执行反操作，即将插入的新记录进行删除操作，将已删除的记录进行插入操作，将修改的记录值恢复为原来的值，以上操作也就是撤销操作。这样，就可将日志记录中“更新前的值”写入数据库。继续从后向前逐个扫描该事务所做的所有更新操作（插入、删除、修改），并做同样的处理。一直扫描到事务的开始标志，事务故障恢复工作才算完成。

2）系统故障的恢复

系统故障的恢复也是由数据库系统自动完成的，系统在重新启动时即可自动完成，用户完全不用干预。

一旦发生系统故障，就有可能使事务处于以下两种不一致状态：一种是未完成的事务对数据库的更新极有可能已写入数据库；另一种是部分已提交的事务对数据库的更新结果还保留在缓冲区里，尚未写到磁盘上的物理数据库中。

为此，系统故障的恢复必须完成两方面的工作：不仅要撤销所有未完成的事务，而且要重做所有已提交的事务，这样才能保证数据库恢复到一致状态。恢复步骤如下。

(1) 从前向后正向扫描日志文件，查找出所有已经提交的事务和尚未完成的事务，并将前者的事务标志列入重做（REDO）队列，将后者的事务标志列入撤销（UNDO）队列。

(2) 对重做队列中的事务进行重做操作。方法是：正向扫描日志文件，对每个重做事务顺序执行日志文件中登记的操作，即将日志记录中更新后的值写入数据库。

(3) 对撤销队列中的事务进行撤销操作，撤销的方法同事务故障重做中所介绍的撤销方法相同。

3）介质故障的恢复

对于较严重的介质故障，如数据库已被破坏，此时必须重装数据库。具体步骤如下。

(1) 装入最新的数据库副本，使数据库恢复到最近一次转储的正确状态。

(2) 装入最新的日志文件副本，根据日志文件的记录重做已经完成的事务。方法是：首先正向扫描日志文件，找出发生故障时已经提交的事务，将其插入重做队列；然后对重做队列中的各个事务进行重做处理。重做的方法同系统故障中所介绍的重做方法相同。