第13章数据库数据库恢复技术.ppt

《第13章数据库数据库恢复技术.ppt》由会员分享，可在线阅读，更多相关《第13章数据库数据库恢复技术.ppt（70页珍藏版）》请在三一办公上搜索。

1、第13章 数据库恢复技术,13.1 恢复的基本概念13.2 数据库故障的种类13.3 数据库恢复的类型13.4 恢复技术13.5 缓冲区管理,2023年4月4日3时31分,1,概述,计算机同其他任何设备一样，都有可能发生故障。这种情况一旦发生，就有可能造成数据丢失。数据库系统必须采取必要的措施，以保证不会或尽可能减少数据丢失。数据库恢复是DBMS必须提供的功能。,2023年4月4日3时31分,2,13.1恢复的基本概念,数据库恢复是指当数据库发生故障时，将数据库恢复到正确（一致性）状态的过程。数据库恢复是基于事务的原子性特性。数据库恢复过程通常遵循一个可预测的方案。恢复机制有两个关键问题：如何

2、建立备份数据；如何利用备份数据进行恢复。,2023年4月4日3时31分,3,数据转储,数据库恢复采用的基本技术：数据转储（也称为数据库备份）。转储就是定期地将整个数据库复制到辅助存储设备上，比如磁带、磁盘。数据转储只能将数据库恢复到转储时的状态。如果想恢复到故障发生时的状态，则必须利用转储之后的事务日志。,2023年4月4日3时31分,4,转储分类,静态转储在系统中无运行事务时进行。在转储期间不允许对数据库进行任何操作。动态转储不用等待正在运行的事务结束。在转储期间允许运行新的事务。,2023年4月4日3时31分,5,静态与动态转储比较,静态转储实现简单，静态转储得到的一定是数据库的一个一致性

3、副本。转储期间但会降低数据库的可用性。动态转储不能保证转储结束后的数据库副本是正确的必须利用日志将数据库恢复到一致性状态转储期间不会降低数据库的可用性。,2023年4月4日3时31分,6,转储内容分类,海量转储：每次转储全部数据库，增量转储：每次只转储上一次转储之后修改过的数据。从恢复的角度看，用海量转储的数据库副本进行恢复更方便，但如果数据量很大，事务处理又比较频繁，则增量转储会更有效。海量转储和增量转储可以是动态的，也可以是静态的。,2023年4月4日3时31分,7,13.2 数据库故障的种类,数据库故障是指导致数据库值出现错误描述状态的情况，影响数据库运行的故障有多种：事务内部的故障系统

4、故障其它故障,2023年4月4日3时31分,8,事务内部的故障,可预期的这类故障可通过事务程序本身发现。如银行转账事务中，如果A账户金额不足，则不能进行转账。非预期性的这类故障不能由应用程序来处理。如运算溢出或因死锁而被撤销的事务。,2023年4月4日3时31分,9,事务故障,事务故障意味着事务没有达到终点，数据库可能处于不正确的状态。数据库的恢复机制要在不影响其他事务运行的情况下，强行撤销该事务中的全部操作，使该事务就像没发生过一样。这类恢复操作称为事务撤销（UNDO）。,2023年4月4日3时31分,10,系统故障,是指造成系统停止运转、系统要重启的故障。例如：硬件错误（CPU故障）操作系

5、统故障突然停电等。这类故障会影响正在运行的所有事务，但不破坏数据库。,2023年4月4日3时31分,11,系统故障产生的结果,一些未完成事务的结果可能已经送入物理数据库中，从而造成数据库可能处于不正确状态；有些已经提交的事务可能有一部分结果还保留在缓冲区中，尚未写到物理数据库中，因此会丢失这些事务对数据的修改，使数据库处于不一致状态。,2023年4月4日3时31分,12,系统故障恢复方法,恢复子系统在系统重新启动时必须：撤销所有未完成的事务重做所有已提交的事务从而保证将数据库恢复到一致状态。,2023年4月4日3时31分,13,其他故障,介质故障或由计算机病毒引起的故障或破坏，均归为其他故障。

6、介质故障指外存故障，如磁盘损坏等。这类故障会对数据库造成破坏，并影响正在操作的数据库的所有事务。这类故障虽然发生的可能性很小，但破坏性很大。计算机病毒的破坏性很大，而且极易传播，它也可以对数据库造成毁灭性的破坏。,2023年4月4日3时31分,14,故障对数据库的影响,有两种可能性：一种是数据库本身的破坏；另一种是数据库没有破坏，但数据可能不正确（因事务非正常终止）。数据库恢复就是保证数据库的正确和一致，其原理是：冗余。即数据库中任何一部分被破坏的或不正确的数据均可根据冗余数据来重建。恢复的原理很简单，但实现的技术细节却很复杂,2023年4月4日3时31分,15,13.3 数据库恢复的类型,无

7、论出现何种类型的故障，都必须终止或提交事务，以维护数据完整性。事务的恢复类型：向前恢复。向后恢复。介质故障恢复。,2023年4月4日3时31分,16,13.3.1 向前恢复,也称为重做（REDO）用于物理损坏情形的恢复过程。如：磁盘损坏向数据库缓冲区写入数据时的故障将缓冲区中的信息传输到磁盘时出现的故障,2023年4月4日3时31分,17,永久生效的更新,事务的中间结果被写入到数据库缓冲区中，数据在缓冲区和数据库的物理存储之间进行传输。当缓冲区的数据被传输到物理存储器后，更新操作才是永久性的。,2023年4月4日3时31分,18,缓冲区,重做事务,如果在写入缓冲区和传输缓冲数据到物理存储器过程

8、中发生故障，则恢复管理器必须确定故障发生时执行WRITE操作的事务的状态：如果事务已经执行了COMMIT语句，则恢复管理器将重做（也称为前滚）事务的操作并将事务的更新结果保存到数据库中。向前恢复保证了事务的持久性。,2023年4月4日3时31分,19,向前恢复过程,首先读取最新的数据库转储和修改数据的事务日志。然后读取日志记录，从数据库转储之后的第一个记录开始，一直读到物理损坏前的最后一次记录。（从后向前读）对于每一条日志记录，把数据库转储中相关的数据值修改为日志记录中修改后的值，使数据库中的值是事务执行完成后的最终结果。,2023年4月4日3时31分,20,重做示意图,2023年4月4日3时

9、31分,21,13.3.2 向后恢复,向后恢复（也称为撤销，UNDO）用于数据库正常操作过程中发生错误时的恢复过程。这种错误可能是人为键入的数据，或是程序异常结束而留下的未完成的数据库修改。,2023年4月4日3时31分,22,向后恢复（续）,如果在故障发生时事务尚未提交，则将导致数据库的不一致性。因此恢复管理器必须撤销（回滚）事务对数据库的所有影响。向后恢复保证了事务的原子性。,2023年4月4日3时31分,23,向后恢复过程,从数据库的当前状态和事务日志的最后一条记录开始，按从前向后的顺序读取日志，将数据库中已更新的数据值改为记录在日志中的更新前的值（前像），直至错误发生点。,2023年4

10、月4日3时31分,24,回滚示意图,2023年4月4日3时31分,25,示例1,2023年4月4日3时31分,26,撤销,撤销,重做,重做,重做,重做,示例2,有事务操作历史及相应的日志记录：,恢复完成之后：A=50，B=50，C=50,系统崩溃,X,故障恢复过程,在发生故障的系统被重启后，数据库的恢复经历了两个阶段：撤销：按逆向顺序读取日志文件中的记录直至第一条记录；重做：顺序向前读取日志文件中的记录直到最后一条记录。大多数商业DBMS都是先进行撤销，再进行重做。,2023年4月4日3时31分,28,在W1(B,80)之后发生故障的事务操作撤销过程,2023年4月4日3时31分,29,在W1

11、(B,80)之后发生故障的事务操作重做过程,2023年4月4日3时31分,30,13.3.3 介质故障恢复,当发生介质故障时，磁盘上的物理数据和日志文件均遭到破坏，这是破坏最严重的一种故障。要从介质故障中恢复数据库，必须在故障前对数据库进行定期转储。在介质正常后，再利用转储恢复数据库。,2023年4月4日3时31分,31,13.4 恢复技术,恢复技术依赖于数据库损坏的类型和程度。基本原则是事务的所有操作必须作为一个逻辑工作单元来对待，并且要保证数据库的一致性。数据库损坏的类型：物理损坏非物理或事务故障,2023年4月4日3时31分,32,物理损坏,需要利用数据库的最新转储进行恢复。如果事务日志

12、文件没有损坏，还可利用事务日志重新执行已提交事务的更新操作。,2023年4月4日3时31分,33,事务故障,需要撤销（回滚）引起不一致的修改。为确保更新已到达物理存储设备，有必要重做（前滚）一些事务。通过使用事务日志文件中更新前的值（前像）和更新后的值（后像），使数据库恢复到一致性状态。这种技术也称为基于日志的恢复技术。有两种：延迟更新立即更新,2023年4月4日3时31分,34,13.4.1 延迟更新技术,只有到达事务的提交点，更新才被写入数据库。即：数据库的更新要延迟到事务执行成功并提交时。在事务执行过程中，更新只被记录在事务日志和缓冲区中。当事务提交后，更新被记录到数据库。,2023年4

13、月4日3时31分,35,延迟更新技术（续）,如果一个事务在到达提交点之前出现故障，将不会修改数据库，因此没必要进行撤销操作。但如果发生故障时事务的更新还未写入到数据库，则必须重做已提交事务的更新。,2023年4月4日3时31分,36,延迟更新技术的日志内容,当事务T启动时，将“事务开始”（或）记录写入事务日志文件。在事务T执行期间，写入一条包含所有之前指定的日志数据的日志记录，例如，为属性A赋新值ai，则用表示。当事务T的所有活动都成功提交时，将记录写入事务日志，并将该事务的所有日志记录写到磁盘上，然后提交该事务。如果事务T被撤销了，则忽略该事务的事务日志，并且不执行写操作。,2023年4月4

14、日3时31分,37,注意,是在事务真正提交之前将日志记录写到磁盘因此，如果在数据库的真正更新过程中发生了故障，日志记录不会受损。当故障发生时，检查日志文件，找到故障发生时正在执行的所有事务。从日志文件的最后一个入口开始，回滚到最近的一个检查点（13.4.4介绍）记录。,2023年4月4日3时31分,38,恢复过程,所有出现了事务开始和事务提交日志记录的事务必须被重做。重做的顺序是日志记录被写入日志的顺序。如果在故障发生前已经执行了写操作，由于该写操作对数据项没有影响，因此即使再次写该数据也不会有问题。这种方法保证了一定会更新所有在故障发生前没有被正确更新的数据项。,2023年4月4日3时31分

15、,39,恢复过程（续）,对所有出现了事务开始和事务撤销的日志记录的事务，不进行特别的操作，因为它们实际上并没有写数据库。如果在恢复过程中又发生了系统崩溃，则可以再次使用日志记录来恢复数据库。,2023年4月4日3时31分,40,转账示例,账户A转账给账户B 2000元，假设账户A现余额10000元，账户B现余额3000元。转账事务T的正常执行过程：,2023年4月4日3时31分,41,立即更新,转账示例（续）,转账事务T的延时更新日志记录,2023年4月4日3时31分,42,转账示例（续）,在记录被写入事务日志之后、更新记录被写入数据库之前发生故障时，事务T的延时更新日志记录：,2023年4月

16、4日3时31分,43,当系统进行恢复时，重做事务T的操作，账户A和B的新值8000和5000被写入到数据库中。,转账示例（续）,在WRITE（B，b1）操作执行之前发生故障的事务日志。事务T的延时更新日志记录：,2023年4月4日3时31分,44,当系统进行恢复时，无需执行任何操作。数据库中账户A和B的值仍为10000和3000。,13.4.2 立即更新技术,更新一旦发生即被施加到数据库中，而无需等到事务提交点以及所有的更改被保存在事务日志时。除了需要重做故障之前已提交的事务所做的更改外，还需要撤销当故障发生时仍未提交的事务所造成的影响。,2023年4月4日3时31分,45,立即更新技术的日志

17、内容,当事务T开始时，“事务开始”（或）被写入事务日志文件。当执行写操作时，向日志文件中写入一条包含必要数据的记录。一旦写入了事务日志记录，就对数据库缓冲区进行写更新。当缓冲区数据被转入辅存时，写入对数据库的更新读数据库自身的更新在缓冲区下一次被刷新到辅存时进行。当事务T提交时，“事务提交”（）记录被写入事务日志。,2023年4月4日3时31分,46,说明,日志记录是在对应的写操作施加到数据库之前被写入的，这称为“先写日志协议”。通过使用先写日志协议，恢复管理器可以大胆假设，如果在日志文件中不存在某个事务的提交记录，则该事务在故障发生时一定处于活动状态，因此必须被撤销。,2023年4月4日3时

18、31分,47,说明,如果事务被撤销，则可利用日志撤销事务所做的修改，因为日志中包含了所有被更新字段的原始值（前像）。由于一个事务可能对一个数据项进行过多次更改，因此对写的撤销应按逆序进行。无论事务的写操作是否被施加到了数据库，写入数据项的前像保证了数据库被恢复到事务开始前的状态。,2023年4月4日3时31分,48,恢复过程,对于任何在日志中同时有“事务开始”和“事务提交”记录的事务，用日志记录来重做，按日志记录的方式写入更新字段的后像值。对于任何在日志中只有“事务开始”记录而没有“事务提交”记录的事务，必须撤销它。这里使用日志记录得到被修改字段的前像值，并将前像值写入数据库，从而将数据库恢复

19、到事务开始之前的状态。撤销操作按它们被写入日志的逆序进行。,2023年4月4日3时31分,49,立即更新日志示例,转账事务T的立即更新日志记录：,2023年4月4日3时31分,50,转账事务,立即更新示例（续）,写操作WRITE(B,b1)执行之前发生故障时的事务日志：,2023年4月4日3时31分,51,事务T必须被撤销，因此执行UNDO(T)操作，使A的值恢复为10000，且事务T需要重新开始。,立即更新示例（续）,当被写入事务日志之后，但新值被写入数据库之前发生故障时的事务日志：,当系统恢复时，执行REDO(T)操作，A和B的值分别为8000和5000。,13.4.3 镜像页技术,在镜像

20、页模式中，数据库被认为是由固定大小的磁盘分区的逻辑存储单元组成。通过页表将页映射到物理磁盘分区，数据库中的每个逻辑页对应页表中的一条记录。每条记录包含页所存储的物理存储的分区号。在单用户环境下，镜像页技术不需要使用事务日志，在多用户环境下可能需要事务日志来支持并发控制。,2023年4月4日3时31分,53,镜像页技术(续),镜像页方法在事务的生存期内，维护两个页表，：当前页表、镜像页表。当事务刚启动时，两个页表是一样的。此后，镜像页表不再改变，并在系统故障时用于恢复数据库。在事务执行过程中，当前页表被用于记录对数据库的所有更新。但事务结束时，当前页表转变成镜像页表。,2023年4月4日3时31

21、分,54,镜像页模式,2023年4月4日3时31分,55,说明,被事务影响的页被复制到新的物理存储区中，通过当前页表，这些分区和那些没有被修改的分区是事务可以访问的。被更改的页的老版本保持不变，通过镜像页表事务仍然可以访问这些页。镜像页表包含事务开始之前页表中存在的记录以及从未被事务修改的分区记录。镜像页表在事务发生时保持不变，用于撤销事务时使用。,2023年4月4日3时31分,56,镜像页技术优缺点,优点：消除了维护事务日志文件的开销，而且，由于不需要对操作进行撤销或重做，因此恢复速度非常快。缺点：数据碎片或分散，需要定期进行垃圾收集以回收不能访问的分区。,2023年4月4日3时31分,57

22、,13.4.4 检查点技术,在利用日志进行数据库恢复时，一般需要检查所有的日志记录。这有两个问题：搜索整个日志将耗费大量的时间，很多需要重做的事务实际上可能已经将它们的更新结果写到了数据库中，而恢复子系统又重新执行这些操作，同样浪费了大量时间。,2023年4月4日3时31分,58,检查点技术,为解决上述问题，发展了具有检查点的恢复技术。这种技术在日志文件中增加两个新的记录检查点记录重新开始记录检查点记录的内容包括：建立检查点时刻所有正在执行的事务列表；这些事务最近一个日志记录的地址。,2023年4月4日3时31分,59,重新开始文件用于记录各个检查点记录在日志文件中的地址。图示为建立检查点Ci

23、时对应的日志文件和重新开始文件。,动态维护日志文件的方法,周期性地执行建立检查点和保存数据库状态的操作。具体步骤：将日志缓冲区中的所有日志记录写到磁盘日志文件上。在日志文件中写入一个检查点记录，该记录包含所有在检查点运行的事务的标识。将数据缓冲区中所有修改过的数据写入到磁盘数据库中。将检查点记录在日志文件中的地址写入一个重新开始文件，以便在发生系统故障而重启时可利用该文件找到日志文件中的检查点记录地址,2023年4月4日3时31分,61,关于检查点,检查点可以按照预订的时间间隔建立，如：每隔固定时间建立一个检查点，比如15分钟、30分钟也可以按照某种规则建立检查点，如：日志文件写满一半时建立一

24、个检查点,2023年4月4日3时31分,62,检查点优点,可以改善恢复效率。如果事务T在某个检查点之前提交，则T对数据库所做的修改均已写入数据库中，因此，在进行恢复时，没有必要对事务T执行重做操作。,2023年4月4日3时31分,63,示例,2023年4月4日3时31分,64,当系统在tf时刻发生故障时，只需扫描事务日志至最近的一个检查点tc,无操作,重做,重做,撤销,13.5 缓冲区管理,对数据库缓冲区的管理，在恢复过程中起着重要的作用。缓冲区管理器负责对在主存和辅存间传送数据页的数据库缓冲区进行高效的管理，包括从磁盘读页到缓冲区直到缓冲区满，然后使用一种替代策略来决定将哪个或哪些缓冲区的数

25、据强制写到磁盘，以此来为从磁盘上读取的新页的操作提供空间。,2023年4月4日3时31分,65,缓冲区管理（续）,缓冲区管理器使用的替代策略有：先进先出（FIFO）最近最少使用(LRU)。当某页已经在数据库缓冲区时，缓冲管理器不会再从磁盘上读取该页。,2023年4月4日3时31分,66,DBMS虚拟内存缓冲区示意,2023年4月4日3时31分,67,缓冲区作用,缓冲区管理器有效地提供了数据库页的临时副本。因此，可被应用到数据库恢复系统中。在这种模式中，修改是在临时副本中完成的，原始的页仍然保留在辅存中不被修改。事务日志和数据页都被写入到虚拟内存中的缓冲区页中。,2023年4月4日3时31分,68,二阶段提交,事务的COMMIT操作分两个阶段完成，因此又被称为二阶段提交。在第一个阶段，事务日志缓冲区被写出（先写日志）。在第二个阶段，数据缓冲区被写出。,2023年4月4日3时31分,69,日志,说明,由于日志总是在COMMIT操作的第一阶段强制写出，因此它不会引起任何问题。由于数据库中没有未提交的修改，因此这种数据库恢复方法不需要撤销事务日志。,2023年4月4日3时31分,70,