第13章 数据库 数据库恢复技术_第1页
第13章 数据库 数据库恢复技术_第2页
第13章 数据库 数据库恢复技术_第3页
第13章 数据库 数据库恢复技术_第4页
第13章 数据库 数据库恢复技术_第5页
已阅读5页,还剩65页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第13章数据库恢复技术13.1恢复的基本概念13.2数据库故障的种类13.3数据库恢复的类型13.4恢复技术13.5缓冲区管理*1概述计算机同其他任何设备一样,都有可能发生故障。这种情况一旦发生,就有可能造成数据丢失。数据库系统必须采取必要的措施,以保证不会或尽可能减少数据丢失。数据库恢复是DBMS必须提供的功能。*213.1恢复的基本概念数据库恢复是指当数据库发生故障时,将数据库恢复到正确(一致性)状态的过程。数据库恢复是基于事务的原子性特性。数据库恢复过程通常遵循一个可预测的方案。恢复机制有两个关键问题:如何建立备份数据;如何利用备份数据进行恢复。*3数据转储数据库恢复采用的基本技术:数据转储(也称为数据库备份)。转储就是定期地将整个数据库复制到辅助存储设备上,比如磁带、磁盘。数据转储只能将数据库恢复到转储时的状态。如果想恢复到故障发生时的状态,则必须利用转储之后的事务日志。*4转储分类静态转储在系统中无运行事务时进行。在转储期间不允许对数据库进行任何操作。动态转储不用等待正在运行的事务结束。在转储期间允许运行新的事务。*5静态与动态转储比较静态转储实现简单,静态转储得到的一定是数据库的一个一致性副本。转储期间但会降低数据库的可用性。动态转储不能保证转储结束后的数据库副本是正确的必须利用日志将数据库恢复到一致性状态转储期间不会降低数据库的可用性。*6转储内容分类海量转储:每次转储全部数据库,增量转储:每次只转储上一次转储之后修改过的数据。从恢复的角度看,用海量转储的数据库副本进行恢复更方便,但如果数据量很大,事务处理又比较频繁,则增量转储会更有效。海量转储和增量转储可以是动态的,也可以是静态的。*713.2数据库故障的种类数据库故障是指导致数据库值出现错误描述状态的情况,影响数据库运行的故障有多种:事务内部的故障系统故障其它故障*8事务内部的故障可预期的这类故障可通过事务程序本身发现。如银行转账事务中,如果A账户金额不足,则不能进行转账。非预期性的这类故障不能由应用程序来处理。如运算溢出或因死锁而被撤销的事务。*9事务故障事务故障意味着事务没有达到终点,数据库可能处于不正确的状态。数据库的恢复机制要在不影响其他事务运行的情况下,强行撤销该事务中的全部操作,使该事务就像没发生过一样。这类恢复操作称为事务撤销(UNDO)。*10系统故障是指造成系统停止运转、系统要重启的故障。例如:硬件错误(CPU故障)操作系统故障突然停电等。这类故障会影响正在运行的所有事务,但不破坏数据库。*11系统故障产生的结果一些未完成事务的结果可能已经送入物理数据库中,从而造成数据库可能处于不正确状态;有些已经提交的事务可能有一部分结果还保留在缓冲区中,尚未写到物理数据库中,因此会丢失这些事务对数据的修改,使数据库处于不一致状态。*12系统故障恢复方法恢复子系统在系统重新启动时必须:撤销所有未完成的事务重做所有已提交的事务从而保证将数据库恢复到一致状态。*13其他故障介质故障或由计算机病毒引起的故障或破坏,均归为其他故障。介质故障指外存故障,如磁盘损坏等。这类故障会对数据库造成破坏,并影响正在操作的数据库的所有事务。这类故障虽然发生的可能性很小,但破坏性很大。计算机病毒的破坏性很大,而且极易传播,它也可以对数据库造成毁灭性的破坏。*14故障对数据库的影响有两种可能性:一种是数据库本身的破坏;另一种是数据库没有破坏,但数据可能不正确(因事务非正常终止)。数据库恢复就是保证数据库的正确和一致,其原理是:冗余。即数据库中任何一部分被破坏的或不正确的数据均可根据冗余数据来重建。恢复的原理很简单,但实现的技术细节却很复杂*1513.3数据库恢复的类型无论出现何种类型的故障,都必须终止或提交事务,以维护数据完整性。事务的恢复类型:向前恢复。向后恢复。介质故障恢复。*1613.3.1向前恢复也称为重做(REDO)用于物理损坏情形的恢复过程。如:磁盘损坏向数据库缓冲区写入数据时的故障将缓冲区中的信息传输到磁盘时出现的故障*17永久生效的更新事务的中间结果被写入到数据库缓冲区中,数据在缓冲区和数据库的物理存储之间进行传输。当缓冲区的数据被传输到物理存储器后,更新操作才是永久性的。*18缓冲区√重做事务如果在写入缓冲区和传输缓冲数据到物理存储器过程中发生故障,则恢复管理器必须确定故障发生时执行WRITE操作的事务的状态:如果事务已经执行了COMMIT语句,则恢复管理器将重做(也称为前滚)事务的操作并将事务的更新结果保存到数据库中。向前恢复保证了事务的持久性。*19向前恢复过程首先读取最新的数据库转储和修改数据的事务日志。然后读取日志记录,从数据库转储之后的第一个记录开始,一直读到物理损坏前的最后一次记录。(从后向前读)对于每一条日志记录,把数据库转储中相关的数据值修改为日志记录中修改后的值,使数据库中的值是事务执行完成后的最终结果。*20重做示意图*2113.3.2向后恢复向后恢复(也称为撤销,UNDO)用于数据库正常操作过程中发生错误时的恢复过程。这种错误可能是人为键入的数据,或是程序异常结束而留下的未完成的数据库修改。*22向后恢复(续)如果在故障发生时事务尚未提交,则将导致数据库的不一致性。因此恢复管理器必须撤销(回滚)事务对数据库的所有影响。向后恢复保证了事务的原子性。*23向后恢复过程从数据库的当前状态和事务日志的最后一条记录开始,按从前向后的顺序读取日志,将数据库中已更新的数据值改为记录在日志中的更新前的值(前像),直至错误发生点。*24回滚示意图*25示例1*26撤销撤销重做重做重做重做示例2有事务操作历史及相应的日志记录:时间事务操作日志记录说明时刻1R1(A,50)(S,1)启动事务T1的日志记录,无需在日志中记录读操作,但这个操作表示事务T1的开始时刻2W1(A,20)(W,1,A,50,20)将事务T1修改A的操作记入日志。A修改前的值是50,修改后的值是20时刻3R2(C,100)(S,2)启动事务T2的日志记录时刻4W2(C,50)(W,2,C,100,50)将事务T2修改C的操作记入日志。C修改前的值是100,修改后的值是50时刻5C2(C,2)提交T2(将日志缓冲区中的信息写入日志文件)时刻6R1(B,50)没有日志项时刻7W1(B,80)(W,1,B,50,80)将事务T1修改B的操作记入日志。B修改前的值是50,修改后的值是80时刻8C1(C,1)提交T1(将日志缓冲区中的信息写入日志文件)恢复完成之后:A=50,B=50,C=50系统崩溃X故障恢复过程在发生故障的系统被重启后,数据库的恢复经历了两个阶段:撤销:按逆向顺序读取日志文件中的记录直至第一条记录;重做:顺序向前读取日志文件中的记录直到最后一条记录。大多数商业DBMS都是先进行撤销,再进行重做。*28在W1(B,80)之后发生故障的事务操作撤销过程*29序号日志记录完成的撤销操作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的开始点,现在没有可撤销的活动了,因此撤销阶段结束在W1(B,80)之后发生故障的事务操作重做过程*30序号日志记录重做操作6(S,1)无动作7(W,1,A,50,20)事务T1未提交,无动作8(S,2)无动作9(W,2,C,100,50)由于事务T2已提交,因此重做该修改,即把C的值改为5010(C,2)无动作,恢复结束13.3.3介质故障恢复当发生介质故障时,磁盘上的物理数据和日志文件均遭到破坏,这是破坏最严重的一种故障。要从介质故障中恢复数据库,必须在故障前对数据库进行定期转储。在介质正常后,再利用转储恢复数据库。*3113.4恢复技术恢复技术依赖于数据库损坏的类型和程度。基本原则是事务的所有操作必须作为一个逻辑工作单元来对待,并且要保证数据库的一致性。数据库损坏的类型:物理损坏非物理或事务故障*32物理损坏需要利用数据库的最新转储进行恢复。如果事务日志文件没有损坏,还可利用事务日志重新执行已提交事务的更新操作。*33事务故障需要撤销(回滚)引起不一致的修改。为确保更新已到达物理存储设备,有必要重做(前滚)一些事务。通过使用事务日志文件中更新前的值(前像)和更新后的值(后像),使数据库恢复到一致性状态。这种技术也称为基于日志的恢复技术。有两种:延迟更新立即更新*3413.4.1延迟更新技术只有到达事务的提交点,更新才被写入数据库。即:数据库的更新要延迟到事务执行成功并提交时。在事务执行过程中,更新只被记录在事务日志和缓冲区中。当事务提交后,更新被记录到数据库。*35延迟更新技术(续)如果一个事务在到达提交点之前出现故障,将不会修改数据库,因此没必要进行撤销操作。但如果发生故障时事务的更新还未写入到数据库,则必须重做已提交事务的更新。*36延迟更新技术的日志内容当事务T启动时,将“事务开始”(或<T,BEGIN>)记录写入事务日志文件。在事务T执行期间,写入一条包含所有之前指定的日志数据的日志记录,例如,为属性A赋新值ai,则用<WRITE(A,ai)>表示。当事务T的所有活动都成功提交时,将记录<T,COMMIT>写入事务日志,并将该事务的所有日志记录写到磁盘上,然后提交该事务。如果事务T被撤销了,则忽略该事务的事务日志,并且不执行写操作。*37注意是在事务真正提交之前将日志记录写到磁盘因此,如果在数据库的真正更新过程中发生了故障,日志记录不会受损。当故障发生时,检查日志文件,找到故障发生时正在执行的所有事务。从日志文件的最后一个入口开始,回滚到最近的一个检查点(13.4.4介绍)记录。*38恢复过程所有出现了事务开始和事务提交日志记录的事务必须被重做。重做的顺序是日志记录被写入日志的顺序。如果在故障发生前已经执行了写操作,由于该写操作对数据项没有影响,因此即使再次写该数据也不会有问题。这种方法保证了一定会更新所有在故障发生前没有被正确更新的数据项。*39恢复过程(续)对所有出现了事务开始和事务撤销的日志记录的事务,不进行特别的操作,因为它们实际上并没有写数据库。如果在恢复过程中又发生了系统崩溃,则可以再次使用日志记录来恢复数据库。*40转账示例账户A转账给账户B2000元,假设账户A现余额10000元,账户B现余额3000元。转账事务T的正常执行过程:*41时间事务步骤动作时刻1READ(A,a1)读取账户A的当前余额时刻2a1=a1-2000将账户A的余额减去2000时刻3WRITE(A,a1)将新的余额写入到账户表中时刻4READ(B,b1)读取账户B的当前余额时刻5b1=b1+2000将账户B的余额加上2000时刻6WRITE(B,b1)将新的余额写入到账户表中立即更新转账示例(续)转账事务T的延时更新日志记录*42时间日志记录数据库存储的值事务开始之前A=10000B=3000时刻1<T,BEGIN>时刻2<T,A,8000>时刻3<T,B,5000>时刻4<T,COMMIT>事务执行之后A=8000B=5000转账示例(续)在<T,COMMIT>记录被写入事务日志之后、更新记录被写入数据库之前发生故障时,事务T的延时更新日志记录:*43时间日志记录数据库存储的值事务开始之前A=10000B=3000时刻1<T,BEGIN>时刻2<T,A,8000>时刻3<T,B,5000>时刻4<T,COMMIT>当系统进行恢复时,重做事务T的操作,账户A和B的新值8000和5000被写入到数据库中。转账示例(续)在WRITE(B,b1)操作执行之前发生故障的事务日志。事务T的延时更新日志记录:*44时间日志记录数据库存储的值事务开始之前A=10000B=3000时刻1<T,BEGIN>时刻2<T,A,8000>时刻3<T,B,5000>当系统进行恢复时,无需执行任何操作。数据库中账户A和B的值仍为10000和3000。13.4.2立即更新技术更新一旦发生即被施加到数据库中,而无需等到事务提交点以及所有的更改被保存在事务日志时。除了需要重做故障之前已提交的事务所做的更改外,还需要撤销当故障发生时仍未提交的事务所造成的影响。*45立即更新技术的日志内容当事务T开始时,“事务开始”(或<T,BEGIN>)被写入事务日志文件。当执行写操作时,向日志文件中写入一条包含必要数据的记录。一旦写入了事务日志记录,就对数据库缓冲区进行写更新。当缓冲区数据被转入辅存时,写入对数据库的更新读数据库自身的更新在缓冲区下一次被刷新到辅存时进行。当事务T提交时,“事务提交”(<T,COMMIT>)记录被写入事务日志。*46说明日志记录是在对应的写操作施加到数据库之前被写入的,这称为“先写日志协议”。通过使用先写日志协议,恢复管理器可以大胆假设,如果在日志文件中不存在某个事务的提交记录,则该事务在故障发生时一定处于活动状态,因此必须被撤销。*47说明如果事务被撤销,则可利用日志撤销事务所做的修改,因为日志中包含了所有被更新字段的原始值(前像)。由于一个事务可能对一个数据项进行过多次更改,因此对写的撤销应按逆序进行。无论事务的写操作是否被施加到了数据库,写入数据项的前像保证了数据库被恢复到事务开始前的状态。*48恢复过程对于任何在日志中同时有“事务开始”和“事务提交”记录的事务,用日志记录来重做,按日志记录的方式写入更新字段的后像值。对于任何在日志中只有“事务开始”记录而没有“事务提交”记录的事务,必须撤销它。这里使用日志记录得到被修改字段的前像值,并将前像值写入数据库,从而将数据库恢复到事务开始之前的状态。撤销操作按它们被写入日志的逆序进行。*49立即更新日志示例转账事务T的立即更新日志记录:*50时间日志记录数据库存储的值事务开始之前A=10000B=3000时刻1<T,BEGIN>时刻2<T,A,10000,8000>时刻3A=8000时刻4<T,B,3000,5000>时刻5B=5000时刻6<T,COMMIT>转账事务立即更新示例(续)写操作WRITE(B,b1)执行之前发生故障时的事务日志:*51时间日志记录数据库存储的值事务开始之前A=10000B=3000时刻1<T,BEGIN>时刻2<T,A,10000,8000>时刻3A=8000事务T必须被撤销,因此执行UNDO(T)操作,使A的值恢复为10000,且事务T需要重新开始。立即更新示例(续)当<T,COMMIT>被写入事务日志之后,但新值被写入数据库之前发生故障时的事务日志:时间日志记录数据库存储的值事务开始之前A=10000B=3000时刻1<T,BEGIN>时刻2<T,A,10000,8000>时刻3A=8000时刻4<T,B,3000,5000>时刻5B=5000时刻6<T,COMMIT>当系统恢复时,执行REDO(T)操作,A和B的值分别为8000和5000。13.4.3镜像页技术在镜像页模式中,数据库被认为是由固定大小的磁盘分区的逻辑存储单元组成。通过页表将页映射到物理磁盘分区,数据库中的每个逻辑页对应页表中的一条记录。每条记录包含页所存储的物理存储的分区号。在单用户环境下,镜像页技术不需要使用事务日志,在多用户环境下可能需要事务日志来支持并发控制。*53镜像页技术(续)镜像页方法在事务的生存期内,维护两个页表,:当前页表、镜像页表。当事务刚启动时,两个页表是一样的。此后,镜像页表不再改变,并在系统故障时用于恢复数据库。在事务执行过程中,当前页表被用于记录对数据库的所有更新。但事务结束时,当前页表转变成镜像页表。*54镜像页模式*55说明被事务影响的页被复制到新的物理存储区中,通过当前页表,这些分区和那些没有被修改的分区是事务可以访问的。被更改的页的老版本保持不变,通过镜像页表事务仍然可以访问这些页。镜像页表包含事务开始之前页表中存在的记录以及从未被事务修改的分区记录。镜像页表在事务发生时保持不变,用于撤销事务时使用。*56镜像页技术优缺点优点:消除了维护事务日志文件的开销,而且,由于不需要对操作进行撤销或重做,因此恢复速度非常快。缺点:数据碎片或分散,需要定期进行垃圾收集以回收不能访问的分区。*5713.4.4检查点技术在利用日志进行数据库恢复时,一般需要检查所有的日志记录。这有两个问题:搜索整个日志将耗费大量的时间,很多需要重做的事务实际上可能已经将它们的更新结果写到了数据库中,而恢复子系统又重新执行这些操作,同样浪费了大量时间。*58检查点技术为解决上述问题,发展了具有检查点的恢复技术。这种技术在日志文件中增加两个新的记录检查点记录重新开始记录检查点记录的内容包括:建立检查点时刻所有正在执行的事务列表;这些事务最近一个日志记录的地址。*59重新开始文件用于记录各个检查点记录在日志文件中的地址。图示为建立检查点Ci时对应的日志文件和重新开始文件。动态维护日志文件的方法周期性地执行建立检查点和保存数据库状态的操作。具体步骤:①

将日志缓冲区中的所有日志记录写到磁盘日志文件上。②

在日志文件中写入一个检查点记录,该记录包含所有在检查点运

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论