| 尽管数据库系统采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并发事务正确执行，但计算机系统的硬件故障、软件错误、操作员失误和恶意破坏等仍然不可避免，所以数据库管理系统还必须具有把数据库从错误状态恢复到某一已知的正确状态的功能，这就是数据库的恢复。
|
|
|
| 数据库系统中可能发生的故障可以大致分为如下几类：事物内部的故障、系统故障、介质故障和计算机病毒。
|
|
|
|
|
| 恢复机制涉及两个关键问题：如何建立冗余数据；如何利用冗余数据实施数据库的恢复。建立冗余数据最常用的技术是数据转储和登录日志文件。
|
|
|
| 转储即DBA定期将整个数据库复制到磁带或另一个磁盘上保存起来的过程，这些备用的数据文本称为后备副本或后援副本。当数据库遭到破坏时，将后备副本装入，将系统恢复到转储时的状态，若要恢复到故障发生时的状态则需要重新运行转储后的所有更新事务。
|
|
|
| 日志文件是用来记录事务对数据库的更新操作的文件，有两种格式供数据库系统采用：以记录为单位的日志文件和以数据块为单位的日志文件。以记录为单位的日志文件包括各个事务的开始标记、结束标记和所有更新操作，每个日志记录的内容主要包括事务标识、操作的类型、操作对象、更新前数据的旧值和更新后数据的新值。以数据块为单位的日志文件记录的内容包括事务标识和被更新的数据块，由于已将更新前的整个块和更新后的整个块都放入日志文件中，所以操作的类型和操作对象等信息就不用放入日志记录中了。登记日志文件时必须严格按照并发事务执行的时间次序来登记，且要先写日志文件后写数据库。
|
|
|
| 在一个数据库系统中，数据转储和登录日志文件这两种方法是一起使用的。
|
|
|
|
|
| 当系统运行过程中发生故障，利用数据库后备副本和日志文件可以将数据库恢复到故障前的某个一致性状态。不同故障的恢复方法也不同。
|
|
|
|
|
| 事务故障是指事务在运行至正常终点前被终止，此时数据库可能出于不正确的状态，恢复程序要在不影响其他事务运行的情况下强行回滚（ROLLBACK）改事务，即撤销该事务已经做出的任何对数据库的修改，使得事务好像完全没有启动一样。事务故障的恢复由系统自动完成。恢复的步骤是：
|
|
|
| .反向（从后向前）扫描日志文件，查找该事务的更新操作。
|
|
|
| .对该事务的更新操作执行逆操作，也就是将日志记录更新前的值写入数据库。如果记录中是插入操作，则相当于作删除操作，如果记录中是删除操作则做插入操作，若是修改操作则相当于用修改前的值代替修改后的值。
|
|
|
| .继续反向扫描日志文件，查找该事务的其他更新操作，并作同样处理。
|
|
|
| .如此处理下去，直到读到了此事务的开始标记，事务故障恢复就完成了。
|
|
|
|
|
| 系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如，特定类型的硬件错误、操作系统故障、DBMS代码错误、突然停电等。这类故障影响正在运行的所有事务，但不破坏数据库。此时主存内容（尤其是缓冲区中的内容）都被丢失，所有运行事务都非正常终止，有些已完成的事务可能有部分甚至全部留在缓冲区中尚未写入磁盘，为了保证一致性，应将这些事务已提交的结果重新写入数据库；此外，一些尚未完成的事务结果可能已经送入物理数据库，为了保证一致性，需要清除这些事务对数据库的所有修改。系统故障的恢复是由系统在重新启动时自动完成的，此时恢复子系统撤销所有未完成的事务并重做（redo）所有已提交的事务。具体的步骤是：
|
|
|
| .正向（从头到尾）扫描日志文件，找出故障发生前已经提交的事务（这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录），将其事务标识记入重做（REDO）队列。同时找出故障发生时尚未完成的事务（这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录），将其事务标识记入撤销（UNDO）队列。
|
|
|
| .反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作，也就是将日志记录中更新前的值写入数据库。
|
|
|
| .正向扫描日志文件，对每个REDO事务重新执行日志文件登记的操作，也就是将日志记录中更新后的值写入数据库。
|
|
|
|
|
| 系统故障常称为软故障，介质故障称为硬故障。硬故障是指外存故障，例如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务，日志文件也被破坏。这类故障比前两类故障发生的可能性要小，但是破坏性最大。恢复方法是重装数据库，然后重做已完成的事务，具体的步骤是：
|
|
|
| .装入最新的数据库后备副本，使数据库恢复到最近一次转储时的一致性状态。
|
|
|
|
|
| 介质故障的恢复需要DBA的介入，DBA只需重装最近转储的数据库副本和有关的各日志文件副本，然后执行系统提供的恢复命令，具体的恢复操作仍由DBMS完成。
|
|
|
