第七章 数据库恢复技术

《第七章 数据库恢复技术》由会员分享，可在线阅读，更多相关《第七章 数据库恢复技术（39页珍藏版）》请在金锄头文库上搜索。

1、第七章 数据库恢复技术7.1 事务的基本概念一、事务(Transaction)所谓事务是用户定义的一个数据库操作序列，这些操作要 么全做要么全不做，是一个不可分割的工作单位。例如，在关系数据库中，一个事务可以是一条SQL语句、一 组SQL语句或整个程序。事务的开始与结束可以由用户显式控制。如果用户没有显式地定义事务，则由DBMS按缺省规定自动划 分事务。在SQL语言中，定义事务的语句有三条：BEGIN TRANSACTIONCOMMITROLLBACKCOMMIT表示提交，即提交事务的所有操作。具体地说就是 将事务中所有对数据库的更新写回到磁盘上的物理数据库中 去，事务正常结束。ROLLBAC

2、K表示回滚，即在事务运行的过程中发生了某种故 障，事务不能继续执行，系统将事务中对数据库的所有已完 成的操作全部撤销，滚回到事务开始时的状态。二、事务的特性事务具有四个特性（ ACID特性）：原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持续性(Durability)。1原子性 事务是数据库的逻辑工作单位，事务中包括的诸操作要么都 做，要么都不做。2一致性事务执行的结果必须是使数据库从一个一致性状态变到另一 个一致性状态。当数据库只包含成功事务提交的结果时，就说数据库处于一 致性状态。如果数据库系统运行中发生故障，有些事务尚未完成就被迫 中断，这

3、些未完成事务对数据库所做的修改有一部分已写入物 理数据库，这时数据库就处于一种不正确的状态，或者说是不 一致的状态。一致性与原子性是密切相关的。3隔离性一个事务的执行不能被其他事务干扰。即一个事务内部 的操作及使用的数据对其他并发事务是隔离的，并发执行的 各个事务之间不能互相干扰。4持续性持续性也称永久性(Permanence)，指一个事务一旦提交， 它对数据库中数据的改变就应该是永久性的。接下来的其他 操作或故障不应该对其执行结果有任何影响。事务ACID特性可能遭到破坏的因素有：(1)多个事务并发运行时，不同事务的操作交叉执行；(2)事务在运行过程中被强行停止。72数据库恢复概述数据库的恢复

4、:数据库管理系统必须具有把数据库从错误状 态恢复到某一已知的正确状态(亦称为一致状态或完整状态)的 功能，这就是数据库的恢复。恢复子系统是数据库管理系统的一个重要组成部分，而且还 相当庞大，常常占整个系统代码的百分之十以上。数据库系统所采用的恢复技术是否行之有效，不仅对系统的 可靠程度起着决定性作用，而且对系统的运行效率也有很大 影响，是衡量系统性能优劣的重要指标。7.3 故障的种类一、事务内部的故障事务内部的故障有的是可以通过事务程序本身发现的(见下面 转账事务的例子)，有的是非预期的，不能由事务程序处理的例如：银行转账事务，这个事务把一笔金额从一个账户甲转给 另一个账户乙。事务内部更多的故

5、障是非预期的，是不能由应用程序处理的 。如运算溢出、并发事务发生死锁而被选中撤销该事务、违反 了某些完整性限制等。以后，事务故障仅指这类非预期的故障 。事务撤销(UNDO): 数据库可能处于不正确状态。恢复程序 要在不影响其他事务运行的情况下，强行回滚(ROLLBACK)该 事务，即撤销该事务已经作出的任何对数据库的修改，使得该 事务好像根本没有启动一样。 这类恢复操作称为事务撤销 (UNDO)。二、系统故障系统故障是指造成系统停止运转的任何事件，使得系统要重 新启动。例如，特定类型的硬件错误(CPU故障)、操作系统故 障、DBMS代码错误、突然停电等。这类故障影响正在运行的所有事务，但不破坏

6、数据库。这时 主存内容，尤其是数据库缓冲区(在内存)中的内容都被丢失， 所有运行事务都非正常终止。发生系统故障时，一些尚未完成的事务的结果可能已送入物 理数据库，从而造成数据库可能处于不正确的状态。为保证 数据一致性，需要清除这些事务对数据库的所有修改。 恢复子系统必须在系统重新启动时让所有非正常终止的事务 回滚，强行撤销(UNDO)所有未完成事务。另一方面，发生系统故障时，有些已完成的事务可能有一 部分甚至全部留在缓冲区，尚未写回到磁盘上的物理数据库中 ，系统故障使得这些事务对数据库的修改部分或全部丢失，这 也会使数据库处于不一致状态，因此应将这些事务已提交的结 果重新写入数据库。所以系统重

7、新启动后，恢复子系统除需要 撤销所有未完成事务外，还需要重做(REDO)所有已提交的事务 ，以将数据库真正恢复到一致状态。三、介质故障系统故障常称为软故障(Soft Crash)，介质故障称为硬故障(HardCrash)。硬故障指外存故障，如磁盘损坏、磁头碰撞，瞬时强磁场 干扰等。这类故障将破坏数据库或部分数据库，井影响正 在存取这部分数据的所有事务。这类故障比前两类故障发 生的可能性小得多，但破坏性最大。四、计算机病毒总结各类故障，对数据库的影响有两种可能性：一 是数据库本身被破坏。二 是数据库没有破坏，但数据可能不正确，这是因为事务的 运行被非正常终止造成的。恢复的基本原理：冗余7.4 恢

8、复的实现技术恢复机制涉及的两个关键:第一、如何建立冗余数据；第二、利用这些冗余数据实施数据库恢复。建立冗余数据最常用的技术：是数据转储和登录日志文件通常在库系统中，这两种方法 是一起使用的。所谓转储即DBA定期地将整个敷据库复制到磁带或另一个 磁盘上保存起来的过程这些备用的数据文本称为后备副 本或后援副本当数据库遭到破坏后可以将后备副本重新装入，但重装后 备副本只能将数据库恢复到转储时的状态，要想恢复到故 障发生时的状态，必须重新运行自转储以后的所有更新事 务7.4.1 数据转储转储是十分耗费时间和资源的，不能频繁进行。DBA应该 根据数据库使用情况确定一个适当的转储周期静态转储:是在系统中无

9、运行事务时进行的转储操作即转 储操作开始的时刻，数据库处于一致性状态，而转储期间不 允许(或不存在)对数据库的任何存取、修改活动。显然，静 态转储得到的一定是一个数据一致性的副本动态转储:是指转储期间允许对数据库进行存取或修改。即 转储和用户事务可以并发执行。(1)动态转储可克服静态转储的缺点，它不用等待正在运行 的用户事务结束，也不会影响新事务的运行(2)转储结束时后援副本上的数据并不能保证正确有效必 须把转储期间各事务对数据库的修改活动登记下来，建立日 志文例如，在转储期间的某个时刻Tc，系统把数据A=100转储到 磁带上，而在下一时刻Td，某一事务将A改为200。转储结束 后，后备副本上

10、的A已是过时的数据了。转储还可以分为海量转储和增量转储两种方式海量转储是指每次转储全部数据库。增量转储则指每次只转储上一次转储后更新过的数据。（1）从恢复角度看，使用海量转储得到的后备副本进行恢复 一般说来会更方便些。（2）但如果数据库很大，事务处理又十分频繁，则增量转储 方式更实用更有效因此数据转储方法可以分为四类：动态海量转储、动态增量转储、静态海量转储、静态增量转储 ，7、4、2 登记日志文件 (Logging)一、日志文件的格式和内容日志文件主要有两种格式；以记录为单位的日志文件、以数据块为单位的日志文件。以数据块为单位的日志文件，日志记录的内容包括：事务标识和被更新的数据块。由于将

11、更新前的整个块和更新后的整个块都放入日志文件中，操作的类型和操作对象等信息就不必放入日志记录中。二、日志文件的作用具体作用是：(1)事务故障恢复和系统故障恢复必须用日志文件。(2)在动态转储方式中必须建立日志文件，后援副本和日志 文件综合起来才能有效地恢复数据库。(3)在静态转储方式中，也可以建立日志文件。当数据库毁 坏后可重新装入后援副本把数据库恢复到转储结束时刻的正 确状态，然后利用日志文件，把已完成的事务进行重做处理 ，对故障发生时尚未完成的事务进行撤销处理。三、登记日志文件(Logging)登记日志文件时必须遵循两条原则：(1)登记的次序严格按并发事务执行的时间次序。(2)必须先写日志

12、文件，后写数据库。7、5 恢复策略 一、事务故障的恢复事务故障是指事务在运行至正常终止点前被终止，这时恢 复子系统应利用日志文件撤销(UNDO)此事务已对数据库进 行的修改事务故障的恢复是由系统自动完成的，对用户是透明的系统的恢复步骤是：(1)反向扫描文件日志(即从最后向前扫描日志文件)，查找 该事务的更新操作。(2)对该事务的更新操作执行逆操作即将日志记录中“更 新前的值”写入数据库(3)继续反向扫描日志文件，查找该事务的其他更新操作， 并做同样处理。(4)如此处理下去，直至读到此事务的开始标记，事务故障 恢复就完成了。752 系统故障的恢复系统故障的恢复是由系统在重新启动时自动完成的，不需

13、要用 户干预系统的恢复步骤是：(1)正向扫描日志文件(即从头扫描日志文件)，找出在故障发生前已经提交的事务(这些事务既有BEGIN TRANSACTION记录，也有COMMIT记录)，将其事务标识记 入重做(REDO)队列同时找出故障发生时尚未完成的事务(这些事务只有BEGIN TRANSACTION记录，无相应的COMMIT记录)，将其事务标 识记入撤销(UNDO)队列。(2)对撤销队列中的各个事务进行撤销(UNDO)处理。进行UNDO处理的方法是，反向扫描日志文件，对每个 UNDO事务的更新操作执行逆操作，即将日志记录中“更新前 的值”写入数据库。(3)对重做队列中的各个事务进行重做(RE

14、DO)处理进行REDO处理的方法是：正向扫描日志文件，对每个 REDO事务重新执行日志文件登记的操作即将日志记录中“ 更新后的值”写入数据库。753 介质故障的恢复具体地说就是：1装入最新的数据库后备副本(高故障发生时刻最近的转储副 本)，使数据库恢复到最近一次转储时的一致性状态对于动态转储的数据库副本，还需同时装入转储开始时刻的 日志文件副本，利用恢复系统故障的方法(即REDO+UNDO)，才能将数据库 恢复到一致性状态。2装入相应的日志文件副本(转储结束时刻的日志文件副本) ，重做已完成的事务：即首先扫描日志文件，找出故障发生 时已提交的事务的标识，将其记入重做队列。然后正向扫描 日志文件

15、，对重做队列中的所有事务进行重做处理即将日 志记录中“更新后的值”写入数据库介质故障的恢复需要DBA介入具体的恢复操作仍由DBMS 完成7、6 具有检查点的恢复技术利用日志技术进行数据库恢复时，需要检查所有日志记 录这样做具有两个问题：一是搜索整个日志将耗费大量的时间二是很多需要REDO处理的事务实际上已经将它们的更新 操作结果写到数据库中了，然而恢复于系统又重新执行 了这些操作，浪费了大量时间具有检查点的恢复技术：这种技术在日志文件中增加一类 新的记录检查点(checkpoint)记录，增加一个重新开始文 件，并让恢复子系统在登录日志文件期间动态地维护日志检查点记录的内容包括：建立检查点时刻

16、所有正在执行的事务清单这些事务最近一个日志记录的地址动态维护日志文件的方法：周期性地执行如下操作：建 立检查点，保存据库状态具体步骤是：将当前日志缓冲中的所有日志记录写入磁盘的日志文件 上；在日志文件中写入一个检查点记录；将当前数据缓冲的所有数据记录写入磁盘的数据库中；把检查点记录在日志文件中的地址写入一个重新开始文 件恢复于系统可以定期或不定期地建立检查点保存敷据库状态 使用检查点方法可以改善恢复效率：当事务T在一个检查点 之前提交，T对数据库所做的修改一定都已写入数据库，写 入时间是在这个检查点建立之前或在这个检查点建立之时； 这样，在进行恢复处理时，没有必要对事务T执行REDO操作系统出现故障时恢复于系境将根据事务的不同状态 采取不同的恢复策略7、7 数据库镜像敷据库镜像是通过复制数据实现的，频繁地复制数据自然会 降怔系统运行效率，只选择对关键数据和日志文件镜像7、8 Oracle中恢