第十章数据库恢复技术.docx

第十章数据库恢复技术本章将引入新的概念：塞灸。它是一系列的数据库操作，是数据库应用程序的基本逻辑单元。事务处理技术主要包括数据库恢复技术和并发控制技术。§10.1事务的概念事务是用户定义的一个操作序列，这些操作要么全做要么全不做，是一个不可分割的工作单位。事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务，则由DBMS按缺省规定自动划分事务。在SQL语言中，定义事务的语句有三条：BEGINTRANSACTIONCOMMITROLLBACK事务通常是以BEGINTRANSACTION开始，以CoMMrr或RoLLBACK结束。CoMMlT表示提交，即提交事务的所有操作。具体地说就是将事务中所有对数据库的更新写回到磁盘上的物理数据库中去，事务正常结束。ROLLBACK表示回滚，即在事务运行的过程中发生了某种故障，事务不能继续执行，系统将事务中对数据库的所有已完成的操作全部撤消，滚回到事务开始时的状态。这里的操作指对数据库的更新操作。事务状态转换图10.1.2事务的特性事务具有四个特性：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持续性(Durability)。这个四个特性也简称为AeID特性。1 .原子性：事务是数据库的逻辑工作单位，事务中包括的诸操作要么都做，要么都不做。原子性由恢复机制实现。2 .一致性：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫中断，系统将事务中对数据库的所有已完成的操作全部撤消，滚回到事务开始时的一致状态。一致性状态由用户来负责。3 .隔离性：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能互相干扰。隔离性通过并发控制机制实现。4 .持续性：持续性也称永久性（Permanence）,指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。持续性通过恢复机制实现。事务是恢复和并发控制的基本单位。保证事务ACID特性是事务处理的重要任务。事务AClD特性可能遭到破坏的因素有：1 .多个事务并行运行时，不同事务的操作交叉执行。2 .事务在运行过程中被强行停止。在第一种情况下，数据库管理系统必须保证多个事务的交叉运行不影响这些事务的原子性。在第二种情况下，数据库管理系统必须保证被强行终止的事务对数据库和其它事务没有任何影响。这些就是数据库管理系统中恢复机制和并发控制机制的责任。§10.2 数据库恢复概述尽管数据库系统中采取了各种保护措施来防止数据库的安全性和完整性被破坏，保证并发事务的正确执行，但是计算机系统中硬件的故障、软件的错误、操作员的失误以及恶意的破坏仍是不可避免的，这些故障轻则造成运行事务非正常中断，影响数据库中数据的正确性，重则破坏数据库，使数据库中全部或部分数据丢失，因此数据库管理系统（恢复子系统）必须具有把数据库从错误状态恢复到某一已知的正确状态（亦称为一致状态或完整状态）的功能，这就是数据库的恢复。§10.3 故障的种类10.3.1 事务内部的故障事务内部的故障有的是可以通过事务程序本身发现的（见下面转帐事务的例子），有的是非预期的，不能由事务程序处理的。例如：银行转帐事务，这个事务把一笔金额从一个帐户甲转给另一个帐户乙。BEGINTRANSACTION读帐户甲的余额BALANCE；BALANCE=BALANCE-AMOUNT；*AMOUNT为转帐金额*/IF（BALANCE<0）THEN打印'金额不足，不能转帐'；ROLLBACK；（撤消刚才的修改，恢复事务）ELSE（读帐户乙的余额BALANCE1；Balancei=balancei+amount；写回Balancei；commit；）这个例子所包括的两个更新操作要么全部完成要么全部不做。否则就会使数据库处于不一致状态，例如只把帐户甲的余额减少了而没有把帐户乙的余额增加O在这段程序中若产生帐户甲余额不足的情况，应用程序可以发现并让事务滚回，撤消已作的修改，恢复数据库到正确状态。事务内部更多的故障是非预期的，是不能由应用程序处理的。如运算溢出、并发事务发生死锁而被选中撤消该事务、违反了某些完整性限制等。以后，事务故障仅指这类非预期的故障。事务故障意味着事务没有达到预期的终点（COMMIT或者显式的ROLLBACK）,因此，数据库可能处于不正确状态。恢复程序要在不影响其它事务运行的情况下，强行回滚（ROLLBACK）该事务，即：撤消该事务已经作出的任何对数据库的修改，使得该事务好象根本没有启动一样。这类恢复操作称为事务撤消（UNDO）o10.3.2 系统故障系统故障是指造成系统停止运转的任何事件，使得系统要重新启动。例如，特定类型的硬件错误（CPU故障）、操作系统故障、DBMS代码错误、突然停电等等。这类故障影响正在运行的所有事务，但不破坏数据库。这时主存内容，尤其是数据库缓冲区（在内存）中的内容都被丢失，所有运行事务都非正常终止。发生系统故障时，一些尚未完成的事务的结果可能已送入物理数据库，有些已完成的事务可能有一部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中，从而造成数据库可能处于不正确的状态。为保证数据一致性，恢复子系统必须在系统重新启动时:1,让所有非正常终止的事务回滚；2,强行撤消（UNDo）所有未完成事务；3,重做（Redo）所有已提交的事务，以将数据库真正恢复到一致状态。10.3.3 介质故障系统故障常称为软故障（SoftCrash）,介质故障称为硬故障（HardCrash）。硬故障指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场干扰等。这类故障将破坏数据库或部分数据库，并影响正在存取这部分数据的所有事务。这类故障比前两类故障发生的可能性小得多，但破坏性最大。10.3.4 计算机病毒计算机病毒是具有破坏性、可以自我复制的计算机程序。计算机病毒已成为计算机系统的主要威胁，自然也是数据库系统的主要威胁。因此数据库一旦被破坏仍要用恢复技术把数据库加以恢复。总结各类故障，对数据库的影响有两种可能性。一是数据库本身被破坏。二是数据库没有破坏，但数据可能不正确，这是因为事务的运行被非正常终止造成的。恢复的基本原理十分简单。可以用一个词来概括：国金。这就是说，数据库中任何一部分被破坏的或不正确的数据可以根据存储在系统别处的冗余数据来重建。尽管恢复的基本原理很简单但实现技术的细节却相当复杂，下面我们将略去许多细节，仅介绍数据库恢复的实现技术。§10.4 恢复的实现技术恢复机制涉及的两个关键问题是：第一，如何建立冗余数据；第二，如何利用这些冗余数据实施数据库恢复。建立冗余数据最常用的技术是数据转储和登录日志文件。通常在一个数据库系统中，这两种方法是一起使用的。10.4.1 数据转储所谓转储即DBA定期地将整个数据库复制到磁带或另一个磁盘上保存起来的过程。这些备用的数据文本称为后备副本或后援副本。当数据库遭到破坏后可以将后备副本重新装入，但重装后备副本只能将数据库恢复到转储时的状态，要想恢复到故障发生时的状态，必须重新运行自转储以后的所有更新事务。如在下图中，系统在h时刻停止运行事务进行数据库转储，在Tb时刻转储完毕，得到Tb时刻的数据库一致性副本。系统运行到Tf时刻发生故障。为恢复数据库，首先由DBA重装数据库后备副本，将数据库恢复至Tb时刻的状态，然后重新运行自Tb时刻至Tf时刻的所有更新事务，这样就把数据库恢复到故障发生前的一致状态。转储运行事务故障发生点正常运行T1JTaTbTf重装后备副本重新运行事务恢复I1>图7转储和恢复转储是十分耗费时间和资源的，不能频繁进行。DBA应该根据数据库使用情况确定一个适当的转储周期。转储可分为：静态转储和动态转储O趣态楚能是在系统中无运行事务时进行的转储操作。即转储操作开始的时刻，数据库处于一致性状态，而转储期间不允许（或不存在）对数据库的任何存取、修改活动。显然，静态转储得到的一定是一个数据一致性的副本。静态转储简单,但转储必须等待正运行的用户事务结束才能进行，同样，新的事务必须等待转储结束才能执行。显然，这会降低数据库的可用性。动态转储是指转储期间允许对数据库进行存取或修改。即转储和用户事务可以并发执行。动态转储可克服静态转储的缺点，它不用等待正在运行的用户事务结束，也不会影响新事务的运行。但是，转储结束时后援副本上的数据并不能保证正确有效。伤”如，在转储期间的某个时刻系统把数据A=IOO转储到磁带上，而在下一时刻Td,某一事务将A改为200。转储结束后，后备副本上的A已是过时的数据了。为此，必须把转储期间各事务对数据库的修改活动登记下来，建立日志文件（Iogfiie）。这样，后援副本加上日志文件就能把数据库恢复到某一时刻的正确状态。转储还可以分为海量转储和增量转储两种方式。海量转储是指每次转储全部数据库。增量转储则指每次只转储上一次转储后更新过的数据。从恢复角度看，使用海量转储得到的后备副本进行恢复一般说来会更方便些。但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效。数据转储有两种方式，分别可以在两种状态下进行，因此数据转储方法可以分为四类：动态海量转储、动态增量转储、静态海量转储和静态增量转储。10.4.2登录日志文件一、日志文件的格式和内容日志文件是用来记录事务对数据库的更新操作的文件。不同数据库系统采用的日志文件格式并不完全一样。概括起来日志文件主要有两种格式：以记录为单鱼的日志文件和以数据块为单位的日志文件。对于以记录为单位的日志文件,日志文件中需要登记的内容包括： 各个事务的开始（BEGlNTRANSACTlON）标记 各个事务的结束（COMMrr或ROLLBACK）标记 各个事务的所有更新操作这里每个事务开始的标记、每个事务的结束标记和每个更新操作均作为日志文件中的一个日志记录（IOgrecord）o每个日志记录的内容主要包括： 事务标识（标明是那个事务） 操作的类型（插入、删除或修改） 操作对象（记录内部标识） 更新前数据的旧值（对插入操作而言，此项为空值） 更新后数据的新值（对删除操作而言，此项为空值）二、日志文件的作用日志文件在数据库恢复中起着非常重要的作用。可以用来进行事务故障恢复和系统故障恢复，并协助后备副本进行介质故障恢复。具体地讲：事务故障恢复和系统故障必须用日志文件。在动态转储方式中必须建立日志文件，后援副本和日志文件综合起来才能有效地恢复数据库。在静态转储方式中，也可以建立日志文件。当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态，然后利用日志文件，把已完成的事务进行重做处理，对故障发生时尚未完成的事务进行撤消处理。这样不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态,如下图所示：Ta静态转储Tb运行事务Tf故障发生点正常运行T11一登记日志文件I重装后备副本利用日志文件恢复事务继续运行介质故障恢复11-j>登记日志文件I>三、登记日志文件（logging）为保证数据库是可恢复的，登记日志文件时必须遵循两条原则：1.登记的次序严格按并发事务执行的时间次序。2.必须先写日志文件,后写数据库。把对数据的修改写到数据库中和把写表示这个修改的日志记录写到日志文件中是两个不同的操作。有可能在这两个操作之间发生故障，即这两个写操作只完成了一个。如果先写了数据库修改，而在运行记录中没有登记下这个修改，则以后就无法恢复这个修改了。如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性。所以为了安全，一定要先写日志文件，即首先把日志记录写到日志文件中，然后写数据库的修改。这就是“先写日志文件”的原则。§10.5 恢复策略10.5.1 事务故障的恢复事务故障是指事务在运行至正常终止点前被中止，这时恢复子系统应利用日志文件撤消（UNDo）此事务已对数据库进行的修改。事务故障的恢复是由系统自动完成的，对用户是透明的。系统的恢复步骤是：1 .反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。2 .对该事务的更新操作执行逆操作。即将日志记录中“更新前的值”写入数据库。这样，如果记录中是插入操作，则相当于做删除操作（因此时“更新前的值”为空）。若记录中是删除操作，则做插入操作，若是修改操作，则相当于用修改前值代替修改后值。3 .继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。4 .如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。10.5.2 系统故障的恢复前面已讲过，系统故障造成数据库不一致状态的原因有两个，一是未完成事务对数据库的更新可能已写入数据库，二是已提交事务对数据库的更新可能还留在缓冲区没来得及写入数据库。因此恢复操作就是要撤消故障发生时未完成的事务，重做已完成的事务。系统故障的恢复是由系统在重新启动时自动完成的，不需要用户干预。系统的恢复步骤是：1 .正向扫描日志文件（即从头扫描日志文件），找出在故障发生前已经提交事务（这些事务既有BEGINTRANSAcTION记录，也有CoMMrr记录），将其事务标识记入重做（REDO）队列。同时找出故障发生时尚未完成的事务（这些事务只有BEGlNTRANSAenoN记录，无相应的CoMMn记录），将其事务标识记入撤消队列。2 .对撤消队列中的各个事务进行撤消（UNDo）处理。进行UNDo处理的方法是，反向扫描日志文件，对每个UNDO事务的更新操作执行逆操作，即将日志记录中“更新前的值”写入数据库。3 .对重做队列中的各个事务进行重做（REDo）处理。进行REDO处理的方法是：正向扫描日志文件，对每个REDo事务重新执行日志文件登记的操作。即将日志记录中“更新后的值”写入数据库。10.5.3 介质故障的恢复发生介质故障后，磁盘上的物理数据和日志文件被破坏，这是最严重的一种故障，恢复方法是重装数据库，然后重做已完成的事务。具体地说就是：1 .装入最新的数据库后备副本（离故障发生时刻最近的转储副本），使数据库恢复到最近一次转储时的一致性状态。对于动态转储的数据库副本，还须同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法（即REDO+UNDO）,才能将数据库恢复到一致性状态。2 .装入相应的日志文件副本（转储结束时刻的日志文件副本），重做已完成的事务。即：首先扫描日志文件，找出故障发生时已提交的事务的标识，将其记入重做队列。然后正向扫描日志文件，对重做队列中的所有事务进行重做处理。即将日志记录中“更新后的值”写入数据库。这样就可以将数据库恢复至故障前某一时刻的一致状态了。介质故障的恢复需要DBA介入。但DBA只需要重装最近转储的数据库副本和有关的各日志文件副本，然后执行系统提供的恢复命令即可，具体的恢复操作仍由DBMS完成。§10.6 具有检查点的恢复技术利用日志技术进行数据库恢复时，恢复子系统必须搜索日志，确定哪些事务需要RED0,哪些事务需要UND0。一般来说，我们需要检查所有日志记录。这样做具有两个问题。一是搜索整个日志将耗费大量的时间。二是很多需要REDo处理的事务实际上已经将它们的更新操作结果写到数据库中了，然而恢复子系统又重新执行了这些操作，浪费了大量时间。为了解决这些问题，又发展了具有检查点的恢复技术。这种技术在日志文件中增加一类新的记录一检查点记录（checkpoint）,增加一个重新开始文件，并让恢复子系统在登录日志文件期间动态地维护日志。检查点记录的内容包括：1 .建立检查点时刻所有正在执行的事务清单。2 .这些事务最近一个日志记录的地址。重新开始文件用来记录各个检查点记录在日志文件中的地址。动态维护日志文件的方法是，周期性地执行如下操作：建立检查点，保存数据库状态。具体步骤是：1 .将当前日志缓冲中的所有日志记录写入磁盘的日志文件上。2 .在日志文件中写入一个检查点记录。3 .将当前数据缓冲的所有数据记录写入磁盘的数据库中。4 .把检查点记录在日志文件中的地址写入一个重新开始文件。恢复子系统可以定期或不定期地建立检查点保存数据库状态。检查点可以按照预定的一个时间间隔建立，如每隔一小时建立一个检查点；也可以按照某种规则建立检查点，如日志文件已写满一半建立一个检查点。使用检查点方法可以改善恢复效率。当事务T在一个检查点之前提交，T对数据库所做的修改一定都已写入数据库，写入时间是在这个检查点建立之前或在这个检查点建立之时。这样，在进行恢复处理时，没有必要对事务T执行REDo操作。系统出现故障时恢复子系统将根据事务的不同状态采取不同的恢复策略。如下图所示：Te停测点）T4系统故障）时间不要REDCT21REDO13IT做消T4I1REDOT5IH做消Tl:在检查点之前提交。T2：在检查点之前开始执行,T3：在检查点之前开始执行,T4：在检查点之后开始执行,T5：在检查点之后开始执行,在检查点之后故障点之前提交。在故障点时还未完成。在故障点之前提交。在故障点时还未完成。T3和T5在故障发生时还未完成，所以予以撤消；T2和T4在检查点之后才提交，它们对数据库所做的修改在故障发生时可能还在缓冲区中，尚未写入数据库，所以要RED0；Tl在检查点之前已提交，所以不必执行REDo操作。系统使用检查点方法进行恢复的步骤是：1 .从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录。2 .由该检查点记录得到检查点建立时刻所有正在执行的事务清单Active-LISTo我们建立两个事务队列：UND0-LIST:需要执行UndO操作的事务集合；RED0-LIST:需要执行redo操作的事务集合；把ACTlVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。3 从检查点开始正向扫描日志文件如有新开始的事务Ti,把Ti暂时放入UNDO-LIST队列；如有提交的事务Tj,把Tj从UNDO-LIST队列移到REDO-LIST队列；直到日志文件结束。4.对UNDo11ST中的每个事务执行UNDO操作，对REDo-LIST中的每个事务执行REDo操作。§10.7数据库镜像介质故障是对系统影响最为严重的一种故障。系统出现介质故障后，用户应用全部中断，恢复起来也比较费时。而且DBA必须周期性地转储数据库，这也加重了DBA的负担。如果不及时而正确地转储数据库，一旦发生介质故障，会造成较大的损失。随着磁盘容量越来越大，价格越来越便宜，为避免磁盘介质出现故障影响数据库的可用性，许多数据库管理系统提供了数据库镜像（Miiror）功能用于数据库恢复。即根据DBA的要求，自动把整个数据库或其中的关键数据复制到另一个磁盘上。每当主数据库更新时，DBMS自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性（课本图10.5a）o这样，一旦出现介质故障，可由镜像磁盘继续提供使用，同时DBMS自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本（课本图10.5b）o在没有出现故障时，数据库镜像还可以用于并发操作，即当一个用户对数据加排他锁修改数据时，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁。由于数据库镜像是通过复制数据实现的，频繁地复制数据自然会降低系统运行效率，因此在实际应用中用户往往只选择对关键薮据和日志文件镜像，而不是对整个数据库进行镜像。§10.8小结保证数据一致性是对数据库的最基本的要求。事务是数据库的逻辑工作单位，只要DBMS能够保证系统中一切事务的原子性、一致性、隔离性和持续性，也就保证了数据库处于一致状态。为了保证事务的原子性、一致性与持续性，DBMS必须对事务故障、系统故障和介质故障进行恢复。数据库转储和登记日志文件是恢复中最经常使用的技术。恢复的基本原理就是利用存储在后备副本、日志文件和数据库镜像中的冗余数据来重建数据库。事务不仅是恢复的基本单位，也是并发控制的基本单位，为了保证事务的隔离性更一般地，为了保证事务的一致性，DBMS需要对并发操作进行控制。