介质故障

系统故障常称为软故障，介质故障称为硬故障。硬故障指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。此类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。此类故障比前两类故障发生的可能性小得多，但破坏性最大。

介质故障是指由于各种原因引起的数据库数据文件、控制文件或重做日志文件的损坏，导致系统无法正常运行。例如，磁盘损坏导致文件系统被破坏。这就需要管理员提前做好数据库的备份，否则将导致数据库无法恢复。

介质故障比事务故障和系统故障发生的可能性小得多，但破坏性很大。这类故障将破坏数据库本身，影响到出故障前存储数据库的所有事务。

介质故障称为硬故障。硬故障指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。此类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。此类故障比前两类故障发生的可能性小得多，但破坏性最大。

计算机病毒可以繁殖、传播并造成计算机系统的危害，己成为计算机系统包括数据库的重要威胁。它也会造成介质故障同样的后果，破坏外存上的数据库，并影响正在存取这部分数据的所有事务。

在上述3种故障中，事务故障和系统故障都不会破坏外存中数据库的数据，而介质故障将破坏存放在外存的数据库中的部分数据或全部数据。因此，事务故障和系统故障可以由系统自动恢复，而介质故障必须借助数据库管理员的帮助，由数据库管理员和系统一起恢复。

介质故障在所有的故障中，对数据库系统造成的危害最大，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障，发生介质故障后，数据库的物理数据和日志记录将被破坏。要恢复介质故障，只能使用基于数据转储的数据恢复技术。恢复时，首先重装数据库，然后重做事务。具体步骤如下：

(1)装入最新的数据库后备副本(离故障发生时刻最近的转储副本)，使数据库恢复到最近一次转储时的一致性状态。对于动态转储的数据库副本，还需同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法，才能将数据库恢复到一致性状态。

(2)装入相应的日志文件副本(转储结束时刻的日志文件副本)，重做已完成的事务。即：首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写人数据库。这样就可以将数据库恢复至故障前某一时刻的一致状态了。
介质故障是当一个文件、个文件的部分或一磁盘不能读或不能写时出现的故障。介质故障的恢复有以下两种形式，它们决定于数据库运行的归档方式。

①如果数据库是可运行的，以致它的联机日志仅可重用但不能归档，此时介质恢复为使用最新的完全备份的简单恢复。在完全备份执行的工作必须手工重做。

②如果数据库可运行，且联机日志是被归档的，该介质故障的恢复是一个实际恢复过程，重构受损的数据库恢复到介质故障前的一个指定事务一致状态。不管哪种形式，介质故障的恢复总是将整个数据库恢复到与故障之前的一个事务保持一致状态。如果数据库是在ARCHIⅣ VELOG方式运行，可有不同类型的介质恢复：完全介质恢复和不完全介质恢复。

(1)完全介质恢复。

完全介质恢复可恢复全部丢失的修改，仅当所有必要的日志可用时才可能。有不同类型的完全介质恢复可使用，其决定于毁坏文件和数据库的可用性。

①关闭数据库的恢复。当数据库可被装配是关闭的，完全不能正常使用，此时可进行全部的或单个毁坏数据文件的完全介质恢复。

②打开数据库的脱机表空间的恢复。当数据库是打开时，完全介质恢复可以处理。损的数据库表空间是联机的，可以使用，而受损表空间是脱机的，其所有数据文件作为恢复的对象。

③打开数据库的脱机表空间的单个数据文件的恢复。当数据库是打开时，完全介质恢复可以处理。未损的数据库表空间是联机的，可以使用，而所损的表空间是脱机的，该表空间指定所损的数据文件可被恢复。

④使用备份的控制文件的完全介质恢复。当控制文件所有拷贝由于磁盘故障而受损时，可进行介质恢复而不丢失数据。

(2)不完全介质恢复

不完全介质恢复是在完全介质恢复不可能或不要求时进行的介质恢复。重构受损的数据库，使其恢复到介质故障前或用户出错之前的一个事务一致性状态。不完全介质恢复的类型包括：基于撤销、基于时间和基于修改的不完全恢复，它们决定于需要不完全介质恢复的情况。

①基于撤销恢复。在某种情况下，不完全介质恢复必须被控制，DBA可撤销在指定点的操作。基于撤销的恢复地在一个或多个日志组(联机的或归档的)已被介质故障所破坏不能用于恢复过程时使用，所以介质恢复必须控制，以致在使用最近的、未损的日志组于数据文件后中止恢复操作。

②基于时间和基于修改的恢复。如果DBA希望恢复到过去的某个指定点，不完全介质恢复可成功完成。可在下列情况下使用：

①当用户意外删除一表，并注意到错误提交的估计时间，DBA可立即关闭数据库，恢复它到用户错误之前的时刻。

②由于系统故障，一个联机日志文件的部分被破坏，所以活动的日志文件突然不可使用，实例被中止，此时需要介质恢复。在恢复中可使用当前联机日志文件的未损部分，DBA利用基于时间的恢复，一旦将有效的联机日志已应用于数据文件后停止恢复过程。

在这两种情况下，不完全介质恢复的终点可由时间点或系统修改号(SCN)来指定。

事务故障是指某个事务在运行过程中由于种种原因未能运行至终止点( COMMIT或ROLLBACK)，发生故障。

事务故障的常见原因包括输入数据有误、运算溢出、违反了完整性限制、应用程序出错、并行事务发生死锁等。

发生事务故障时，未完成的事务可能把对数据库的部分修改已写回物理数据库，此时的数据库可能处于不正确的状态，恢复程序要在不影响其他事务运行的情况下，强行回滚(ROLLBACK)该事务，清除该事务对数据库的所有修改，使得这个事务好像根本没有运行过一样。

系统故障是指操作系统或DBMS代码错误、特定类型的硬件错误（如CPU故障）或突然停电等原因，使得系统要重新启动。发生系统故障时，所有正在运行的事务都非正常终止，内存中数据库缓冲区的信息全部丢失，但外部存储设备上的数据未受影响。

一方面，发生系统故障时，一些尚未完成的事务的结果可能已被写人物理数据库，从而造成数据库可能处于不正确的状态。为保证数据一致性，需要清除这些事务对数据库的所有修改。恢复子系统必须在系统重新启动时让所有非正常终止的事务回滚，强行撤销(UNDO)所有未完成的事务。

另一方面，发生系统故障时，有些已完成事务的结果可能有一部分甚至全部留在缓冲区中，尚未写入磁盘上的物理数据库，系统故障使得这些事务对数据库的修改部分或全部丢失，这也会使数据库处于不一致状态，因此应将这些事务已提交的结果重新写入数据库。恢复子系统必须在系统重新启动时重做( REDO)所有已提交的事务，以将数据库恢复到一致状态。

系统故障称为“软故障”(SoftCrash)。介质故障称为“硬故障”(HardCrash)。介质故障是指由于磁盘损坏、磁头碰撞、瞬时强磁场干扰等原因，使得存储在外存中的数据部分丢失或全部丢失。

介质故障比前两类故障的可能性小得多，但破坏性大得多。关键概念：事务故障和系统故障不会破坏外存中数据库的数据，介质故障会破坏存放在外存的数据库中的部分或全部数据。

总结各类故障，对数据库的影响有两种可能性：一是数据库本身被破坏；二是数据库没有被破坏，但数据可能不正确。

数据库系统中的恢复机制主要指恢复数据库本身，即在故障引起数据库当前状态不一致后将数据库恢复到某个正确状态或一致性状态。

故障恢复的原理很简单，就是预先在数据库系统外，备份正确状态时的数据库影像数据，当发生故障时，再根据这些影像数据来重建数据库。恢复机制要做两件事情：第一，建立冗余数据；第二，根据冗余数据恢复数据库。故障恢复的原理虽然简单，但实现技术相当复杂。

建立冗余数据的常用方法是数据库转储法和日志文件法。

1．数据库转储法

由DBA(数据库管理员)定期地把整个数据库复制到磁带、另一个磁盘或光盘上保存起来，作为数据库的后备副本（也称后援副本），称为数据库转储法。

数据库发生破坏时，可把后备副本重新装入以恢复数据库。但重装副本只能恢复到转储时的状态。自转储以后的所有更新事务必须重新运行，才能使数据库恢复到故障发生前的一致状态。

由于转储的代价很大，因此必须根据实际情况确定一个合适的转储周期。

转储分为静态转储和动态转储两类。

1)静态转储

在系统中没有事务运行的情况下进行转储称为静态转储。这可保证得到一个一致性的数据库副本，但在转储期间整个数据库不能使用。

2)动态转储

允许事务并发执行的转储称为动态转储。动态转储克服了静态转储会降低数据库可用性的缺点，但不能保证转储后的副本是正确有效的。例如，在转储中，把某一数据存储到了副本，但在转储结束前，某一事务又把此数据修改了，这样，后备副本上的数据就不正确了。

因此必须建立日志文件，把转储期间任何事务对数据库的修改都记录下来。以后，后备副本加上日志文件就可把数据库恢复到前面动态转储结束时的数据库状态。

另外，转储还可以分为海量转储和增量转储。海量转储是指转储全部数据库：增量转储是指只转储上次转储后更新过的数据。

数据库中的数据一般只会部分更新。因此，采用增量转储可明显减少转储的开销。例如，每周做一次海量转储，每天做一次增量转储。也可每天做一次增量转储，当总的增量转储的内容达到一定量时，做一次海量转储。

2．日志文件法

前面已指出，重装副本只能使数据库恢复到转储时的状态，必须接着重新运行自转储后的所有更新事务才能使数据库恢复到故障发生前的一致状态。日志文件法就是用来记录所有更新事务的。

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

(1)事务每一次对数据库的更新都必须写入日志文件。一次更新在日志文件中有一条记载更新工作的记录。

(2)必须先把日志记录写到日志文件中，再执行更新操作，即日志先写原则。

曰志文件有三类记录：

(1)每个事务开始时，必须在日志文件中登记一条该事务的开始记录；

(2)每个事务结束时，必须在日志文件中登记一条结束该事务的记录(注明为(COMMIT或ROLLBACK);

(3)任一事务的任一次对数据库的更新，都必须在日志文件中登入一条记录，其格式为

（<事务标识>，<操作类型>，<更新前数据旧值>，<更新后数据的新值>）其中，<操作类型>有插入、删除和修改三种类型。