|
|
|
当系统运行过程中发生故障，利用数据库后备副本和日志文件就可以将数据库恢复到故障前的某个一致性状态。数据库故障主要分为事务故障、系统故障和介质故障，不同故障的恢复方法也不同。
|
|
|
|
|
|
事务故障是指事务在运行至正常终点前被终止，此时数据库可能处于不正确的状态，恢复程序要在不影响其他事务运行的情况下强行回滚（rollback）该事务，即撤销该事务已经做出的任何对数据库的修改，使得事务好像完全没有启动一样。事务故障的恢复由系统自动完成。恢复的步骤是：
|
|
|
|
（1）反向（从后向前）扫描日志文件，查找该事务的更新操作。
|
|
|
|
（2）对该事务的更新操作执行逆操作，也就是将日志记录更新前的值写入数据库。如果记录中是插入操作，则相当于做删除操作，如果记录中是删除操作则做插入操作，若是修改操作则相当于用修改前的值代替修改后的值。
|
|
|
|
（3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
|
|
|
|
（4）如此处理下去，直到读到了此事务的开始标记，事务故障恢复就完成了。
|
|
|
|
|
|
系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如，特定类型的硬件错误、操作系统故障、DBMS代码错误、突然停电等。这类故障影响正在运行的所有事务，但不会破坏数据库。此时主存内容（尤其是缓冲区中的内容）都将被丢失，所有运行事务都被非正常终止，有些已完成的事务可能有部分甚至全部留在缓冲区中尚未被写入磁盘，为了保证一致性，应将这些事务已提交的结果重新写入数据库；此外，一些尚未完成的事务结果可能已经被送入物理数据库，为了保证一致性，需要清除这些事务对数据库的所有修改。系统故障的恢复是由系统在重新启动时自动完成的，此时恢复子系统撤销所有未完成的事务并重做（redo）所有已提交的事务。具体的步骤是：
|
|
|
|
（1）正向（从头到尾）扫描日志文件，找出故障发生前已经提交的事务（这些事务既有Begin Transaction记录，也有commit记录），将其事务标识记入重做（redo）队列。同时找出故障发生时尚未完成的事务（这些事务只有Begin Transaction记录，无相应的commit记录），将其事务标识记入撤销（undo）队列。
|
|
|
|
（2）反向扫描日志文件，对每个undo事务的更新操作执行逆操作，也就是将日志记录中更新前的值写入数据库。
|
|
|
|
（3）正向扫描日志文件，对每个redo事务重新执行日志文件登记的操作，也就是将日志记录中更新后的值写入数据库。
|
|
|
|
|
|
系统故障常被称为软故障，介质故障常被称为硬故障。硬故障是指外存故障，例如磁盘损坏、磁头碰撞、瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务，日志文件也将被破坏。这类故障比前两类故障发生的可能性要小，但是破坏性最大。恢复方法是重装数据库，然后重做已完成的事务，具体的步骤是：
|
|
|
|
（1）装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态。
|
|
|
|
|
|
介质故障的恢复需要DBA的介入，DBA只需重装最近转储的数据库副本和有关的各日志文件副本，然后执行系统提供的恢复命令，具体的恢复操作仍由DBMS完成。
|
|
|
