| 数据库系统中可能发生各种各样的故障，大致可以分以下几类：
|
|
|
| （1）事务内部的故障。事务内部的故障有的是可以通过事务程序本身发现的，有的是非预期的，不能由事务程序处理。例如，输入数据违反完整性约束、运算溢出、并行事务发生死锁而被选中撤销该事务等。事务故障意味着事务没有到达预期的终点（COMMIT或者显式的ROLLBACK），因此，数据库可能处于不正确状态。这样，系统就要强行回滚此事务，即撤销该事务已经做出的任何对数据库的修改，使得该事务好像根本没有启动一样。
|
|
|
| （2）系统范围内的故障。系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如，中央处理器故障、操作系统故障、突然停电等，这类故障影响正在运行的所有事务，但不破坏数据库。这时内存中的内容，尤其是数据库缓冲区中的内容都将丢失，使得运行事务都非正常终止，从而造成数据库可能处于不正确的状态，数据库恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，把数据库恢复到正确的状态。
|
|
|
| （3）介质故障。系统故障常称为软故障（soft crash），介质故障称为硬故障（hard crash）。硬故障指外存故障，如磁盘的磁头碰撞、瞬时的强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正存取这部分数据的所有事务，这类故障比前两类故障发生的可能性小得多，但破坏性最大。
|
|
|
| （4）计算机病毒。计算机病毒是一种人为的故障或破坏，是一些恶作剧者研制的一种计算机程序。这种程序与其他程序不同，它像微生物学所称的病毒一样可以繁殖和传播，并造成对计算机系统包括数据库的危害。
|
|
|
| 总结各类故障，对数据库的影响有两种可能性，一是数据库本身被破坏，二是数据库没有被破坏，但数据可能不正确，这是由事务的运行被终止所造成的。
|
|
|
|
|
| 备份（转储）是指DBA定期地将整个数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据文本称为后备副本（后援副本）。当数据库遭到破坏后就可以利用后备副本把数据库恢复，这时，数据库只能恢复到备份时的状态，从那以后的所有更新事务必须重新运行才能恢复到故障时的状态。
|
|
|
| 备份可分为静态备份（冷备份）和动态备份（热备份）。静态备份是指备份期间不允许（或不存在）对数据库进行任何存取、修改活动。静态备份简单，但备份必须等待用户事务结束才能进行，同样，新的事务必须等待备份结束才能执行。显然，这会降低数据库的可用性；动态备份是指备份期间允许对数据库进行存取或修改，即备份和用户事务可以并发执行。动态备份可克服静态备份的缺点，但是，备份结束时后援副本上的数据并不能保证正确有效。
|
|
|
| 备份还可以分为海量备份和增量备份。海量备份是指每次备份全部数据库。增量备份则指每次只备份上次备份后更新过的数据。如果数据库很大，事务处理又十分频繁，则增量备份方式是很有效的。
|
|
|
|
|
| 事务日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中，这种文件就称为日志文件。对于任何一个事务，事务日志都有非常全面的记录，根据这些记录可以将数据文件恢复成事务前的状态。从事务动作开始，事务日志就处于记录状态，事务执行过程中对数据库的任何操作都记录在内，直到用户提交或回滚后才结束记录。
|
|
|
| 日志文件是用来记录对数据库每一次更新活动的文件，在动态备份方式中，必须建立日志文件，后援副本和日志文件综合起来才能有效地恢复数据库；在静态备份方式中，也可以建立日志文件，当数据库毁坏后可重新装入后援副本把数据库恢复到备份结束时刻的正确状态，然后利用日志文件，把已完成的事务进行重做处理，对故障发生时尚未完成的事务进行撤销处理。这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态。
|
|
|
| 例如，在热备份期间的某时刻t1，系统把数据A=100备份到了磁带上，而在时刻t2，某一事务对A进行了修改使A=200。备份结束，后备副本上的A已是过时的数据了。为此，必须把备份期间各事务对数据库的修改活动登记下来，建立日志文件。这样，后备副本加上日志文件就能把数据库恢复到某一时刻的正确状态。
|
|
|
| 事务在运行过程中，系统把事务开始、事务结束（包括COMMIT和ROLLBACK），以及对数据库的插入、删除、修改等每一个操作作为一个登记记录存放到日志文件中。每个记录包括的主要内容有：执行操作的事务标识、操作类型、更新前数据的旧值（对插入操作而言此项为空值）、更新后的新值（对删除操作而言此项为空值）。登记的次序严格按并行事务操作执行的时间次序，同时遵循“先写日志文件”的规则。写一个修改到数据库中和写一个表示这个修改的日志记录到日志文件中是两个不同的操作，有可能在这两个操作之间发生故障，即这两个写操作只完成了一个，如果先写了数据库修改，而在日志记录中没有登记这个修改，则以后就无法恢复这个修改了。因此，为了安全，应该先写日志文件，即首先把修改记录写到日志文件上，然后再写数据库的修改。这就是“先写日志文件”的原则。
|
|
|
|
|
| 把数据库从错误状态恢复到某一个已知的正确状态的功能，称为数据库的恢复。数据恢复的基本原理就是冗余，建立冗余的方法有数据备份和登录日志文件等。可以根据故障的不同类型，采用不同的恢复策略。
|
|
|
|
|
| 事务故障的恢复是由系统自动完成的，对用户是透明的（不需要DBA的参与）。其步骤如下：
|
|
|
|
|
|
|
| （3）继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
|
|
|
| （4）如此处理下去，直至读到此事务的开始标记，事务故障恢复完成。
|
|
|
|
|
| 系统故障的恢复在系统重新启动时自动完成，不需要用户干预。其步骤如下：
|
|
|
| （1）正向扫描日志文件，找出在故障发生前已经提交的事务，将其事务标识记入重做（Redo）队列。同时找出故障发生时尚未完成的事务，将其事务标识记入撤销（Undo）队列。
|
|
|
| （2）对撤销队列中的各个事务进行撤销处理：反向扫描日志文件，对每个Undo事务的更新操作执行逆操作。
|
|
|
| （3）对重做队列中的各个事务进行重做处理：正向扫描日志文件，对每个Redo事务重新执行日志文件登记的操作。
|
|
|
|
|
|
|
| （1）装入最新的数据库后备副本，使数据库恢复到最近一次备份时的一致性状态。
|
|
|
| （2）从故障点开始反向扫描日志文件，找出已提交事务标识并记入Redo队列。
|
|
|
| （2）从起始点开始正向扫描日志文件，根据Redo队列中的记录，重做已完成的任务，将数据库恢复至故障前某一时刻的一致状态。
|
|
|
|
|
| 检查点记录的内容可包括建立检查点时刻所有正在执行的事务清单，以及这些事务最近一个日志记录的地址。采用检查点的恢复步骤如下：
|
|
|
| （1）从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录。
|
|
|
| （2）由该检查点记录得到检查点建立时所有正在执行的事务清单队列（A）。
|
|
|
| （3）建立重做队列（R）和撤销队列（U），把A队列放入U队列中，R队列为空。
|
|
|
| （4）从检查点开始正向扫描日志文件，若有新开始的事务T1，则把T1放入U队列；若有提交的事务T2，则把T2从U队列移到R队列，直至日志文件结束。
|
|
|
| （5）对U队列的每个事务执行Undo操作，对R队列的每个事务执行Redo操作。
|
|
|
