6-2

概 述
　　 在DBS运行时，可能会出现各式各样的故障，譬如磁盘损坏、电源故障、软件错误、机房火灾和恶意破坏等。在发生故障时，很可能丢失数据库中数据。DBMS的恢复管理子系统采取一系列措施保证在任何情况下保持事务的原子性和持久性，确保数据不丢失、不破坏。

数据库的可恢复性（Recovery）： 系统能把数据库从被破坏、不正确的状态、恢复到最近一个正确的状态，DBMS的这种能力称为数据库的可恢复性（Recovery）。   6.2.1 典型的恢复策略
　　 数据库的恢复，意味着要把数据库恢复到最近一次故障前的一致性状态。

1.平时做好两件事：转储和建立日志。
(1)周期地（比如一天一次）对整个数据库进行拷贝，转储到另一个磁盘或磁带一类存储介质中。
(2)建立日志数据库。记录事务的开始、结束标志，记录事务对数据库的每一次插入、删除和修改前后的值，写到“日志”库中，以便有案可查。

2.一旦发生数据库故障，分两种情况进行处理。
(1)如果数据库遇到灾难性故障，例如磁头脱落、磁盘损坏等，这时数据库已不能用了，就必须装入最近一次拷贝的数据库备份到新的磁盘，然后利用日志库执行“重做”（REDO）已提交的事务，把数据库恢复到故障前的状态。
(2)如果数据库未遭到物理性破坏，但破坏了数据库的一致性（某些数据不正确），此时不必去拷贝存档的数据库，只要利用日志库“撤销”（UNDO）所有不可靠的修改，再利用日志库执行“重做”（REDO）已提交的、但对数据库的更新可能还留在内存缓冲区的事务，就可以把数据库恢复到正确的状态。 6.2.2 故障类型和恢复方法
1.事务故障
(1)可以预期的事务故障，即在程序中可以预先估计到的错误，譬如存款余额透支，商品库存量达到最低量等，此时继续取款或发货就会出现问题。这种情况可以在事务的代码中加入判断和ROLLBACK语句。当事务执行到ROLLBACK语句时，由系统对事务进行回退操作，即执行UNDO操作。
(2)非预期的事务故障，即在程序中发生的未估计到的错误，譬如运算溢出、数据错误、并发事务发生死锁而被选中撤销该事务等。此时由系统直接对该事务执行UNDO处理。

2.系统故障
(1)系统故障的定义
　　 ①引起系统停止运转随之要求重新启动的事件称为“系统故障”。
　　 ②例如硬件故障、软件（DBMS、OS或应用程序）错误或掉电等几种情况，都称为系统故障。
(2)系统故障对数据库的影响
　　 ①系统故障要影响正在运行的所有事务，并且主存内容丢失，但不破坏数据库。
　　 ②由于故障发生时正在运行的事务都非正常终止，从而造成数据库中某些数据不正确。
　　 ③DBMS的恢复子系统必须在系统重新启动时，对这些非正常终止的事务进行处理，把数据库恢复到正确的状态。
(3)系统故障的恢复
　　 ①对未完成事务作UNDO处理。
　　 ②对已提交事务但更新还留在缓冲区的事务进行REDO处理。

3.介质故障
(1)发生原因
　　 ○在发生介质故障和遭受病毒破坏时，磁盘上的物理数据库遭到毁灭性破坏。
(2)恢复的过程
　　 ①重装最近转储的后备副本到新的磁盘，使数据库恢复到转储时的一致状态。
　　 ②在日志中找出最近转储以后所有已提交的事务。
　　 ③对这些已提交的事务进行REDO处理，将数据库恢复到故障前某一时刻的一致状态。

4.故障说明
(1)事务故障和系统故障的恢复由系统自动进行，而介质故障的恢复需要DBA配合执行。
(2)在实际中，系统故障通常称为软故障（Soft Crash），介质故障通常称为硬故障（Hard Crash）。 6.2.3 检查点技术
1.检查点方法
(1)检查点的设置方法
　　 ①前面多次提到REDO（重做）和UNDO（撤销）处理，实际上是采用检查点（Checkpoint）方法实现的，大多数DBMS产品都提供这种技术。
　　 ②在DBS运行时，DBMS定时设置检查点。
　　 ③在检查点时刻才真正做到把对DB的修改写到磁盘，并在日志文件写入一条检查点记录（以便恢复时使用）。
　　 ④当DB需要恢复时，只有那些在检查点后面的事务需要恢复。
　　 ⑤若每小时进行3~4次检查，则只有不超过20~15分钟的处理需要恢复。这种检查点机制大大减少了DB恢复的时间。
　　 ⑥一般DBMS产品自动实行检查点操作，无须人工干预。
(2)与检查点和系统故障有关的事务的可能状态

(3)检查点的说明
　　 ①设DBS运行时，在tc时刻产生了一个检查点，而在下一个检查点来临之前的tf时刻系统发生故障。我们把这一阶段运行的事务分成五类（T1~T5）。
　　 ②事务T1不必恢复。因为它们的更新已在检查点tc时写到数据库中去了。
　　 ③事务T2和事务T4必须重做（REDO）。因为它们结束在下一个检查点之前。它们对DB的修改仍在内存缓冲区，还未写到磁盘。
　　 ④事务T3和事务T5必须撤销（UNDO）。因为它们还未做完，必须撤销事务已对DB作的修改。
2.检查点方法的恢复算法
(1)根据日志文件建立事务重做队列和事务撤销队列。
　　 ①此时，从头扫描日志文件（正向扫描），找出在故障发生前已经提交的事务（这些事务执行了COMMIT），将其事务标识记入重做对列。
　　 ②同时，还要找出故障发生时尚未完成的事务（这些事务还未执行COMMIT），将其事务标识记入撤销队列。
(2)对重做队列中的事务进行REDO处理，对撤销队列中的事务进行UNDO处理。
　　 ①进行REDO处理的方法是：正向扫描日志文件，根据重做队列的记录对每一个重做事务重新实施对数据库的更新操作。
　　 ②进行UNDO处理的方法是：反向扫描日志文件，根据撤销队列的记录对每一个撤销事务的更新操作执行逆操作（对插入操作执行删除操作，对删除操作执行插入操作，对修改操作则用修改前的值代替修改后的值）。 6.2.4 SQL对事务的支持
1.SQL语言对事务的支持以及对基于事务的恢复的支持都遵循前面的概念。

2.SQL支持通常的COMMIT和ROLLBACK语句，但这些语句将强制每个打开的游标关闭，这就引起了所有数据库定位的丢失。

3.有些系统的SQL语言能在执行COMMIT语句时防止关闭游标，譬如DB2支持在游标说明时使用WITH HOLD选项，那么执行COMMIT语句时并不关闭游标，而是使其保持打开、定位的状态，这样下一个FETCH语句将按顺序将游标指向下一个元组。因此，原先在下一个游标打开时所需要的重定位就不再需要了。

4.SQL对事务的支持与本节前面的概念的区别之一在于，SQL不包括显式的BEGIN TRANSACTION语句。程序开始就是第一个事务的开始。在遇到COMMIT或ROLLBACK语句时，意味着一个事务结束，同时开始下一个事务。