数据库第13章 数据库恢复技术.docx
《数据库第13章 数据库恢复技术.docx》由会员分享，可在线阅读，更多相关《数据库第13章 数据库恢复技术.docx（24页珍藏版）》请在冰豆网上搜索。
数据库第13章数据库恢复技术
第13章数据库恢复技术
计算机同其他任何设备一样，都有可能发生故障。
故障的原因有多种多样，包括磁盘故障、电源故障、软件故障、灾害故障、人为破坏等。
这些情况一旦发生，就有可能造成数据的丢失。
因此，数据库管理系统必须采取必要的措施，以保证即使发生故障，也不会造成数据丢失，或尽可能减少数据的丢失。
数据库恢复作为数据库管理系统必须提供的一种功能，保证了数据库的可靠性，并保证在故障发生时，数据库总是处于一致的状态。
这里的可靠性指的是数据库管理系统对各种故障的适应能力，也就是从故障中进行恢复的能力。
本章讨论各种故障的类型以及针对不同类型的故障采用的数据库恢复技术。
13.1恢复的基本概念
数据库恢复是指当数据库发生故障时，将数据库恢复到正确（一致性）状态的过程。
换句话说，它是将数据库恢复到发生系统故障之前最近的一致性状态的过程。
故障可能是软、硬件错误引起的系统崩溃，例如存储介质故障，或者是数据库访问程序的逻辑错误等应用软件错误。
恢复是将数据库从一个给定状态（通常是不一致的）恢复到先前的一致性状态。
数据库恢复是基于事务的原子性特性。
事务是一个完整的工作单元，它所包含的操作必须都被应用，并且产生一个一致的数据库状态。
如果因为某种原因，事务中的某个操作不能执行，则必须终止该事务并回滚（撤销）其对数据库的所有修改。
因此，事务恢复是在事务终止前撤销事务对数据库的所有修改。
数据库恢复过程通常遵循一个可预测的方案。
首先它确定所需恢复的类型和程度。
如果整个数据库都需要恢复到一致性状态，则将使用最近的一次处于一致性状态的数据库的备份进行恢复。
通过使用事务日志信息，向前回滚备份以恢复所有的后续事务。
如果数据库需要恢复，但数据库已提交的部分仍然不稳定，则恢复过程将通过事务日志撤销所有未提交的事务。
恢复机制有两个关键的问题：
第一，如何建立备份数据；第二，如何利用备份数据进行恢复。
数据转储（也称为数据库备份）是数据库恢复中采用的基本技术。
所谓转储就是数据库管理员定期地将整个数据库复制到辅助存储设备上，比如磁带、磁盘。
当数据库遭到破坏后可以利用转储的数据库进行恢复，但这种方法只能将数据库恢复到转储时的状态。
如果想恢复到故障发生时的状态，则必须利用转储之后的事务日志，并重新执行日志中的事务。
转储是一项非常耗费资源的活动，因此不能频繁地进行。
数据库管理员应该根据实际情况制定合适的转储周期。
转储可分为静态转储和动态转储两种。
静态转储是在系统中无运行事务时进行转储操作。
即在转储操作开始时数据库处于一致性状态，而在转储期间不允许对数据库进行任何操作。
因此，静态转储得到的一定是数据库的一个一致性副本。
静态转储实现起来比较简单，但转储必须要等到正在运行的所有事务结束才能开始，而且在转储时也不允许有新的事务运行，因此，这种转储方式会降低数据库的可用性。
动态转储是不用等待正在运行的事务结束就可以进行，而且在转储过程中也允许运行新的事务，因此转储过程中不会降低数据库的可用性。
但不能保证转储结束后的数据库副本是正确的，例如，假设在转储期间把数据A＝100转储到了磁带上，而在转储的过程中，有另一个事务将A改为了200，如果对更改后的A值没有再进行转储，则数据库转储结束后，数据库副本上的A就是过时的数据了。
因此，必须把转储期间各事务对数据库的修改操作记录下来，这个保存事务对数据库的修改操作的文件就称为事务日志文件（logfile）。
这样就可以利用数据库的备份和日志文件把数据库恢复到某个一致性状态。
转储还可以分为海量转储和增量转储两种。
海量转储是指每次转储全部数据库，增量转储是指每次只转储上一次转储之后修改过的数据。
从恢复的角度看，使用海量转储得到的数据库副本进行恢复一般会比较方便，但如果数据量很大，事务处理又比较频繁，则增量转储方式会更有效。
海量转储和增量转储可以是动态的，也可以是静态的。
13.2数据库故障的种类
数据库故障是指导致数据库值出现错误描述状态的情况，影响数据库运行的故障有很多种，有些故障仅影响内存，而有些还影响辅存。
数据库系统中可能发生的故障种类很多，大致可以分为如下几类：
1．事务内部的故障
事务内部的故障有些是可以预期到的，这样的故障可以通过事务程序本身发现。
如，在银行转账事务中，当把一笔金额从A账户转给B账户时，如果A账户中的金额不足，则应该不能进行转账，否则可以进行转账。
这个对金额的判断就可以在事务的程序代码中进行判断。
如果发现不能转账的情况，对事务进行回滚即可。
这种事务内部的故障就是可预期的。
但事务内部的故障有很多是非预期性的，这样的故障就不能由应用程序来处理。
如运算溢出或因并发事务死锁而被撤销的事务等。
我们后边所讨论的事务故障均指这类非预期性的故障。
事务故障意味着事务没有达到预期的终点（COMMIT或ROLLBACK），因此，数据库可能处于不正确的状态。
数据库的恢复机制要在不影响其他事务运行的情况下，强行撤销该事务中的全部操作，使得该事务就像没发生过一样。
这类恢复操作称为事务撤销（UNDO）。
2．系统故障
系统故障是指造成系统停止运转、系统要重启的故障。
例如，硬件错误（CPU故障）、操作系统故障、突然停电等。
这样的故障会影响正在运行的所有事务，但不破坏数据库。
这时内存中的内容全部丢失，这可能会有两种情况：
第一种：
一些未完成事务的结果可能已经送入物理数据库中，从而造成数据库可能处于不正确状态；另一种：
有些已经提交的事务可能有一部分结果还保留在缓冲区中，尚未写到物理数据库中，这样系统故障会丢失这些事务对数据的修改，也使数据库处于不一致状态。
因此，恢复子系统必须在系统重新启动时撤销所有未完成的事务，并重做所有已提交的事务，以保证将数据库恢复到一致状态。
3．其它故障
介质故障或由计算机病毒引起的故障或破坏，我们归为其它故障。
介质故障指外存故障，如磁盘损坏等。
这类故障会对数据库造成破坏，并影响正在操作的数据库的所有事务。
这类故障虽然发生的可能性很小，但破坏性很大。
计算机病毒的破坏性很大，而且极易传播，它也可以对数据库造成毁灭性的破坏。
不管是哪类故障，对数据库的影响有两种可能性：
一种是数据库本身的破坏；另一种是数据库没有被破坏，但数据可能不正确（因事务非正常终止）。
数据库恢复就是保证数据库的正确和一致，其原理很简单，就是：
冗余。
即，数据库中任何一部分被破坏的或不正确的数据均可根据存储在系统别处的冗余数据来重建。
尽管恢复的原理很简单，但实现的技术细节却很复杂。
13.3数据库恢复的类型
无论出现何种类型的故障，都必须终止或提交事务，以维护数据完整性。
事务日志在数据库恢复中起重要的作用，它使数据库在发生故障时能回到一致性状态。
事务是数据库系统恢复的基本单元。
恢复管理器保证发生故障时事务的原子性和持久性。
在从故障中进行恢复的过程中，恢复管理器确保一个事务的所有影响要么都被永久地记录到数据库中，要么都没被记录。
事务的恢复类型有两种：
●向前恢复。
●向后恢复。
13.3.1向前恢复（或重做）
向前恢复（也称为重做，REDO）用于物理损坏情形的恢复过程，例如：
磁盘损坏、向数据库缓冲区（数据库缓冲区是内存中的一块空间）写入数据时的故障、或将缓冲区中的信息传输到磁盘时出现的故障。
事务的中间结果被写入到数据库缓冲区中，数据在缓冲区和数据库的物理存储之间进行传输。
当缓冲区的数据被传输到物理存储器后，更新操作才被认为是永久性的。
该传输操作可通过事务的COMMIT语句触发，或当缓冲区存满时自动触发。
如果在写入缓冲区和传输缓冲数据到物理存储器的过程中发生故障，则恢复管理器必须确定故障发生时执行WRITE操作的事务的状态。
如果事务已经执行了COMMIT语句，则恢复管理器将重做（也称为前滚）事务的操作从而将事务的更新结果保存到数据库中。
向前恢复保证了事务的持久性。
为了重建由于上述原因而造成损坏的数据库，系统首先读取最新的数据库转储和修改数据的事务日志。
然后，开始读取日志记录，从数据库转储之后的第一个记录开始，一直读到物理损坏前的最后一次记录。
对于每一条日志记录，程序将把数据库转储中相关的数据值修改为日志记录中修改后的值，使得数据库中的值是事务执行完成后的最终结果。
从数据库转储之后，每个修改数据库的事务操作（日志中的每条记录）都会按照事务最初执行的顺序被记录下来，因此数据库可以恢复到被损坏时的最近状态。
图13-1说明了一个向前恢复的例子。
13.3.2向后恢复（或撤销）
向后恢复（也称为撤销，UNDO）是用于数据库正常操作过程中发生错误时的恢复过程。
这种错误可能是人为键入的数据，或是程序异常结束而留下的未完成的数据库修改。
如果在故障发生时事务尚未提交，则将导致数据库的不一致性。
因为在这期间，其他程序可能读取并使用了错误的数据。
因此恢复管理器必须撤销（回滚）事务对数据库的所有影响。
向后恢复保证了事务的原子性。
图13-1向前恢复（重做）
图13-2说明了一个向后恢复方法的例子。
向后恢复时，从数据库的当前状态和事务日志的最后一条记录开始，程序按从前向后的顺序读取日志，将数据库中已更新的数据值改为记录在日志中的更新前的值（前像），直至错误发生点。
因此，程序按照与事务中的操作执行相反的顺序撤销每一个事务。
图13-2向后恢复（撤销）
例1撤销和重做操作可以用图13-3中所示的例子解释。
图中并发执行的事务有：
T1，T2，…，T6。
现在假设DBMS在tS时刻开始执行事务，在tc时刻发生磁盘损坏而导致tf时刻的执行失败。
同时假设在tf时刻的故障前，事务T2和T3的数据已经写入到物理数据库中。
图13-3重做和撤销示例
从图13-3可以观察到：
在故障点时，事务T1和T6尚未提交，而T2、T3、T4和T5事务均已提交。
因此，恢复管理器必须撤销事务T1和T6的操作。
但从图13-3中无法得知：
其他已提交的事务对数据库的修改被传输到物理磁盘（数据库）上的程度，这种不确定性源于数据的修改是在缓冲区中进行的，当发生故障时，我们不能确定缓冲区中的数据是否已被传送到磁盘中。
因此，恢复管理器必须重新执行事务T2、T3、T4和T5。
例2表13-1所示为事务操作历史及相应的日志记录，该表除了操作记录之外，还同时列出了用于数据库恢复记入的日志记录（保存在内存或物理存储器上）。
其中在“事务操作”列，R（…）代表读数据操作，W（…）代表修改数据操作。
例如R1（A,50）表示事务T1读A的数据为50，W1（A,20）表示事务T1修改A的数据为20。
在“日志记录”列，读数据不需要写日志，（S,1）表示事务T1开始，（C,2）表示事务T2提交。
而（W,1,A,50,20）表示事务T1执行的是一个更改操作，将A的值从50（更改前）改为20（更改后）。
现在，按照表13-1中事件发生的顺序，假定在W1（B,80）操作完成后立即发生了系统崩溃。
这意味着，日志记录（W,1,B,50,80）已被放入日志缓冲区，但在日志缓冲区中，写入磁盘的最后一条记录是（C,2），而不是（W,1,B,50,80）。
这也是故障恢复时可用的最后一条日志记录。
这时，由于事务T2已经提交而事务T1尚未提交，因此，有关事务T2的所有更新都要被存入磁盘，而有关事务T1的所有更新都要被撤销。
恢复完成之后这些数据项的最终值应当为A=50，B=50，C=50。
表13-1事务历史及对应的日志记录
时间
事务操作
日志记录
说明
时刻1
R1（A,50）
（S,1）
启动事务T1的日志记录，无需在日志中记录读操作，但这个操作表示事务T1的开始
时刻2
W1（A,20）
（W,1,A,50,20）
将事务T1修改A的操作记入日志。
A修改前的值是50，修改后的值是20
时刻3
R2（C,100）
（S,2）
启动事务T2的日志记录
时刻4
W2（C,50）
（W,2,C,100,50）
将事务T2修改C的操作记入日志。
C修改前的值是100，修改后的值是50
时刻5
C2
（C,2）
提交T2（将日志缓冲区中的信息写入日志文件）
时刻6
R1（B,50）
没有日志项
时刻7
W1（B,80）
（W,1,B,50,80）
将事务T1修改B的操作记入日志。
B修改前的值是50，修改后的值是80
时刻8
C1
（C,1）
提交T1（将日志缓冲区中的信息写入日志文件）
在发生故障的系统被重新启动后，数据库的恢复过程经历了两个阶段：
一个是向后恢复或叫撤销；一个是向前恢复或叫重做。
在撤销阶段，按逆向顺序读取日志文件中的记录直至第一条记录。
在重做阶段，顺序向前读取日志文件中的记录直到最后一条记录。
大多数商业数据库管理系统，如IBM的R系统和DB2，都是先进行撤销，再进行重做。
表13-2和13-3列出了所有的日志记录以及在撤销和重做阶段发生的活动。
在表13-2的左边标出了撤销的步骤序号，并且与表13-3的重做步骤序号连在一起。
在撤销阶段，系统向后顺序读取日志文件中的记录，并且将所有已提交和未提交的事务分别列入不同的已提交事务列表和未提交事务列表中。
已提交事务列表在重做阶段使用，未提交事务列表用于确定何时撤销更新。
由于当系统处理到最后一条日志记录（向后读）时便知道哪些事务没有提交，因此它可以立即开始撤销未提交事务的写操作，并将更新前的值写入到被影响的行。
从而将所有被影响的数据项恢复到所有未提交事务更新前的值。
表13-2在W1（B,80）发生故障后的事务操作撤销过程
序号
日志记录
完成的撤销操作
1
（C,2）
将事务T2放入事务提交列表
2
（W,2,C,100,50）
由于事务T2在提交列表，因此不进行任何操作
3
（S,2）
记录事务T2不再活动
4
（W,1,A,50,20）
事务T1还未提交。
最后一部是写操作，因此系统执行撤销操作，把A改为修改前的值（50）。
将事务T1放入未提交事务列表
5
（S,1）
到达事务T1的开始点，现在没有可撤销的活动了，因此撤销阶段结束
表13-3表13-2所示的撤销过程完成后发生的重做过程
序号
日志记录
重做操作
6
（S,1）
无动作
7
（W,1,A,50,20）
事务T1未提交，无动作
8
（S,2）
无动作
9
（W,2,C,100,50）
由于事务T2已提交，因此重做该修改，即把C的值改为50
10
（C,2）
无动作，恢复结束
在表13-3所示的重做阶段，系统仅根据撤销阶段搜集到的已提交事务列表，来重做可能没有被写入到磁盘的事务的修改操作。
表13-3的第9步就是一个重做的例子。
重做阶段完成后，数据库中的数据项都具有了正确的值，所有已提交事务的更新均被应用，所有未完成事务的更新均被撤销。
注意，表13-2中撤销的第4步，数据项A被赋值为50。
在表13-3重做的第9步，数据项C被赋值为50。
回顾一下，故障恰好发生在操作W1（B，80）之后。
从表13-1中可以看出，由于该操作的日志记录没有写入磁盘，B的更新前的值不能恢复，将B的值修改为80的更新也不能写入磁盘。
因此，事务日志中涉及的三个数据项的最终值为：
A=50，B=50，C=50。
13.3.3介质故障恢复
当发生介质故障时，磁盘上的物理数据和日志文件均遭到破坏，这是破坏最严重的一种故障。
要想从介质故障中恢复数据库，则必须要在故障前对数据库进行定期转储，否则很难恢复。
从介质故障中恢复数据库的方法是首先排除介质故障，例如用新的磁盘更换损坏的磁盘。
然后重新安装数据库管理系统，使数据库管理系统能正常运行，最后再利用介质损坏前对数据库已做的转储或利用镜像设备恢复数据库。
13.4恢复技术
数据库管理系统使用的恢复技术依赖于数据库损坏的类型和程度。
基本原则是事务的所有操作必须作为一个逻辑工作单元来对待，事务包含的操作都必须执行，并且要保证数据库的一致性。
下面是可能发生的两种数据库损坏类型：
①物理损坏：
如果数据库发生物理损坏，例如磁盘损坏，则需要利用数据库的最新转储进行恢复。
如果事务日志文件没有损坏，还可利用事务日志重新执行已提交事务的更新操作。
②非物理或事务故障：
在事务的执行过程中，如果由于系统故障导致数据库不一致时，则需要撤销（回滚）引起不一致的修改。
为了确保更新已到达物理存储设备，有必要重做（前滚）一些事务。
这种情况下，通过使用事务日志文件中更新前的值（称为前像）和更新后的值（称为后像），使数据库恢复到一致性状态。
这种技术也称为基于日志的恢复技术。
下面是两种用于非物理或事务故障的恢复技术。
●延迟更新。
●立即更新。
13.4.1延迟更新技术
采用延迟更新技术时，只有到达事务的提交点，更新才被写入数据库。
换言之，数据库的更新要延迟到事务执行成功并提交时。
在事务执行过程中，更新只被记录在事务日志和缓冲区中。
当事务提交后，事务日志被写入磁盘，更新被记录到数据库。
如果一个事务在到达提交点之前出现故障，它将不会修改数据库，因此也没必要进行撤销操作。
然而，可能有必要重做某些已提交事务的更新，因为这些事务的更新可能还未写入到数据库。
使用延迟更新技术时，事务日志的内容如下：
●当事务T启动时，将“事务开始”（或）记录写入事务日志文件。
●在事务T执行期间，写入一条新的日志记录，该新记录包含所有之前指定的日志数据，例如为属性A赋新值ai，则用表示。
每一条记录包括事务的名称T，属性的名称A和属性的新值ai。
●当事务T的所有活动都成功提交时，将记录写入事务日志，并将该事务的所有日志记录写到磁盘上，然后提交该事务。
使用日志记录来完成对数据库的真正更新。
●如果事务T被撤销了，则忽略该事务的事务日志，并且不执行写操作。
注意，是在事务真正提交之前将日志记录写到磁盘，因此，如果在数据库的真正更新过程中发生了故障，日志记录不会受损，因此可在稍后再进行更新。
当故障发生时，检查日志文件，找到故障发生时正在执行的所有事务。
从日志文件的最后一个入口开始，回滚到最近的一个检查点（检查点在13.4.4介绍）记录。
所有出现了事务开始和事务提交日志记录的事务必须被重做。
重做的顺序是按日志记录被写入日志的顺序执行。
如果在故障发生前已经执行了写操作，由于该写操作对数据项没有影响，因此即使再次写该数据也不会有问题。
而且这种方法保证了一定会更新所有在故障发生前没有被正确更新的数据项。
对所有出现了事务开始和事务撤销的日志记录的事务，不进行特别的操作，因为它们实际上并没有写数据库，从而这些事务也不必被撤销。
如果在恢复过程中又发生了系统崩溃，则可以再次使用日志记录来恢复数据库。
写日志记录的方式决定了重写的次数。
考虑一个转账事务的例子，账户A要转账给账户B2000元，假设账户A现有余额10000元，账户B现有余额3000元。
表13-4列出了完成这个转账业务的事务步骤，相应的事务日志记录见表13-5。
表13-4事务T的正常执行
时间
事务步骤
动作
时刻1
READ（A,a1）
读取账户A的当前余额
时刻2
a1=a1-2000
将账户A的余额减去2000
时刻3
WRITE（A,a1）
将新的余额写入到账户表中
时刻4
READ（B,b1）
读取账户B的当前余额
时刻5
b1=b1+2000
将账户B的余额加上2000
时刻6
WRITE（B,b1）
将新的余额写入到账户表中
表13-5事务T的延时更新日志记录
时间
日志记录
数据库存储的值
事务开始之前
A=10000
B=3000
时刻1
时刻2
时刻3
时刻4
事务执行之后
A=8000
B=5000
现在假设数据库在下列情况下发生故障：
●恰好在COMMIT记录被写入事务日志之后和更新记录被写入数据库之前。
●恰好在WRITE操作执行之前。
表13-6说明了在记录被写入事务日志之后、更新记录被写入数据库之前发生故障时，事务T的延时更新日志记录。
由于延时更新日志中有事务T的COMMIT记录，因此当系统进行恢复时，重做事务T的操作，账户A和B的新值8000和5000被写入到数据库中。
表13-6当更新被写入数据库前发生故障时，事务T的延时更新日志记录
时间
日志记录
数据库存储的值
事务开始之前
A=10000
B=3000
时刻1
时刻2
时刻3
时刻4
表13-7说明在WRITE（B，b1）操作执行之前发生故障的事务日志。
因为事务日志中没有事务T的COMMIT记录，所以当系统进行恢复时，无需执行任何操作。
数据库中账户A和B的值仍为10000和3000。
在这种情况下，必须重新开始该事务。
表13-7当在写数据库操作执行之前发生故障时，事务T的延时更新日志记录
时间
日志记录
数据库存储的值
事务开始之前
A=10000
B=3000
时刻1
时刻2
时刻3
通过事务日志，数据库管理系统能够处理任何不丢失日志信息的故障。
预防事务日志丢失的方法是，将其同步备份到多个磁盘或其他辅助存储器上。
由于事务日志丢失的可能性非常小，因此这种方法通常被称为稳定存储。
13.4.2立即更新技术
采用立即更新技术时，更新一旦发生即被施加到数据库中，而无需等到事务提交点以及所有的更改被保存在事务日志时。
除了需要重做故障之前已提交的事务所做的更改外，现在还需要撤销当故障发生时仍未提交的事务所造成的影响。
在这种情况下，使用日志文件从以下几个方面来防止系统故障：
●当事务T开始时，“事务开始”（或）被写入事务日志文件。
●当执行一个写操作时，向日志文件中写入一条包含必要数据的记录。
●一旦写入了事务日志记录，就对数据库缓冲区进行写更新。
●当缓冲区数据被转入辅助存储器时，写入对数据库的更新。
●读数据库自身的更新在缓冲区下一次被刷新到辅助存储时进行。
●当事务T提交时，“事务提交”（）记录被写入事务日志。
实际上，日志记录（或至少是部分日志记录）是在对应的写操作施加到数据库之前被写入的，这称为“先写日志协议”（write-aheadlogprotocol）。
因为如果先对数据库进行更新，而在日志记录被写入之前发生了故障，则恢复管理器将无法进行撤销或重做。
通过使用先写日志协议，恢复管理器可以大胆假设，如果在日志文件中不存在某个事务的提交记录，则该事务在故障发生时一定处于活动状态，因此必须被撤销。
如果事务被撤销，则可利用日志撤销事务所做的修改，因为日志中包含了所有被更新字段的原始值（前像）。
由于一个事务可能对一个数据项进行过多次更改，因此对写的撤销应该按逆序进行。
无论事务的写操作是否被施加到了数据库本身，写入数据项的前像保证了数据库被恢复到事务开始前的状态。
如果系统发生了故障，恢复过程使用日志对事务进行如下的撤销或重做。
●对于任何“事务开始”和“事务提交”记录都出现在日志中的事务，用日志记录来重做，按日志记录的方式写入更新字段的后像值
升级会员 