第7章-故障恢复课件

第7章故障恢复学习目的和要求◆事务管理概况◆故障恢复导论◆日志结构◆更新事务的执行与恢复◆消息的处理◆失效的类型及恢复对策7/23/20231DesignedbyTaoHongcai7.1事务管理概况

事务概念：有时，某个工作的完成要分若干步骤。只有所有步骤都成功做完，则该项工作才完成；否则，其中任一步失败，该工作亦失败。针对此类工作特点，引入“事务”（Transactoin）概念。在DBMS中，定义此类工作为事务，并保证其执行特点。一.事务基本概念

事务的执行保证：DBMS应保证事务执行特点以及数据库的数据完整性。如果事务执行成功，DBMS应保证事务中所有步骤对数据的更新有效；若事务失败，DBMS应撤销“已执行步骤”对数据的更新。

事务典型事例：银行A、B两个帐户间的转帐工作。该工作分二步来完成，第一步，从A帐户划出X款项，第二步，向B帐户划入X款项。只有这两步都完成了，该转帐工作才完成。否则，任一步失败，则该转帐工作失败。7/23/20232DesignedbyTaoHongcai

事务的组成及执行：事务是DBMS的最小执行单位，由有限的数据库操作序列组成，也是最小的故障恢复单位和并发控制单位。

DBMS中的事务控制：

(1)

隐式的事务控制：默认情况下，DBMS一般将一个数据库操作（如一条SQL语句）当作一个事务来控制执行。

(2)

显式的事务控制：对涉及多步操作的（一般含多条SQL语句）、有事务特点的工作，则需要人为地、显式地将这些操作“界定”组合成一个事务交DBMS控制执行。

说明：事实上，有时一条SQL语句的工作也有事务特点，例如一条删除多行数据的SQL语句。

说明：对数据库的操作必须自成/组合为一个事务单位，以事务为最小的单位执行之；在并发执行时，亦是以事务为单位进行；在事务不完整、需要恢复数据时，仍然是以事务为单位进行。7/23/20233DesignedbyTaoHongcai

事务的地位：是DBMS中并发执行(ConcurrentExecution)和故障恢复(Recoveryfromsystemfailure)的基础。有关概念：

①

DB对象：程序R/W信息的单位(如页、记录等)；

②

读DB对象：从磁盘读入内存，再送程序变量中；

③

写DB对象：修改内存中对象副本，后写入磁盘。

SYBASE/SQLSERVER提供的界定事务的常用语句：

①BEGIN{TRANSACTION|TRAN|WORK}[事务名]

②ROLLBACK{TRANSACTION|TRAN|WORK}[事务名]

③COMMIT{TRANSACTION|TRAN|WORK}[事务名]7/23/20234DesignedbyTaoHongcai二.事务的ACID准则

(1)原子性(Atomicity)：事务中的所有操作要么成功执行，要么都不执行(NothingorAll)。其保证由事务管理器(TransactionManager)负责，“提交(Commit)”和“回退(Rollback)”操作是其中的关键。

①COMMIT表明事务成功结束：告诉事务管理器事务成功完成，DB又处于一致状态，该事务的所有更新操作现可被提交或永久保留。

DBMS为保证在并发访问和故障情况下对数据的维护，要求事务有如下四个重要特征或准则(ACID)：

②ROLLBACK表明事务不成功结束：告诉事务管理器出现故障，DB可能处于不一致状态，该事务中已做的所有更新操作必须回退或撤销(Undo)。事务回退后，DB又处于一致状态。

说明：7/23/20235DesignedbyTaoHongcai

(2)一致性(Consistency)：在无其它事务并发执行时，单独运行的事务应保证DB从一个一致状态转到另一个一致状态，但事务内勿需保证一致性。该特性的一部分需由用户负责。

(4)持久性(Durability)：一旦DBMS告诉用户事务成功执行，其对数据库的影响应是持久的，即使事务导致的变化在写盘之前系统崩溃仍应如此。该特性和第一个特性由故障恢复通过日志负责。

(3)隔离性(Isolation)：DBMS为改善性能要交错执行几个事务的操作，但要求这些并发执行的事务，对用户而言象是单独执行一样。该特性由并发控制负责。7/23/20236DesignedbyTaoHongcai三.事务管理的内容

①由于出现异常，中途中止或不成功退出；

③遇到如不能访盘等异常状态而中止。引起事务不完全的三个故障原因：

ACID准则的保证：不仅在系统正常如此，在系统故障时也应如此；在单个事务执行时如此，在事务并发执行时也应如此。

②可能因电源等故障，系统崩溃；

故障恢复（CrashRecovery）：保证事务在故障时满足ACID准则的技术；

并发控制（ConcurrencyControl）：保证事务在并发执行时满足ACID准则的技术；

事务管理（TransactionManagement）：故障恢复和并发控制的合称。7/23/20237DesignedbyTaoHongcai7.2故障恢复导论

概念：周期性(天、周)转储（Dump）DB到磁带上。

故障→数据丢失→数据恢复。

备份时间：一般在夜间、周末；一.单纯以后备副本为基础的恢复技术

改进方法：增量转储(IncrementalDumping,ID)，只转储修改过的物理块，减少转储时间、存储空间和数据丢失。

技术特点：实现简单，缺点是不能恢复到尽可能近一点的一致状态。只适用于小型或不重要DBS。

备份副本（Copy）：恢复丢失数据的手段。

恢复：主要指恢复DB本身，即在故障引起DB当前状态不一致后，将DB恢复到某个正确状态或一致状态。要恢复，必冗余(Redundancy)。

恢复方法：DB失效时，取最近的后备副本来恢复DB。7/23/20238DesignedbyTaoHongcai二.以后备副本和日志为基础的恢复技术

前像（BI）：事务更新DB所涉及物理块更新前的映象(BeforeImage,BI)。如撤销(Undo)更新，可使DB恢复到更新前的状态。

日志（Log）：供恢复用的DB运行情况的记录。其内容有：前像、后像和事务状态。

后像（AI）：事务更新DB所涉及物理块更新后的映象(AfterImage,AI)。如重做(Redo)更新，可使DB恢复到更新后的状态。

事务状态：根据事务状态变迁，事务状态有：活动状态、操作结束、事务提交、事务结束、事务失败、回退。7/23/20239DesignedbyTaoHongcai

系统处理：事务一旦开始，即记入日志，并跟踪事务两种状态，一是活动状态（以记录正在执行的事务），二是提交状态（以区分事务是否提交）。

恢复方法：故障排除后，先取最近副本，然后根据日志中的事务是否提交作相应处理。对未提交事务，应用前像回退；对已提交事务一般用后像重做。

事务的两种结局：①提交而结束，其对DB的更新才能被其它事务访问；②事务失败，事务所作的DB更新必须回退。

故障事务处理的依据：事务是已提交，还是未提交。7/23/202310DesignedbyTaoHongcai三.基于多副本的恢复技术

NOS/OS级的可靠性技术：镜像磁盘（MirroringDisk）、双工磁盘（DuplexDisk）、镜像服务器（MirroringServer）、群集（Cluster）系统。

方法：利用多副本互为备份、恢复。

DBMS级的可靠性技术：数据库复制(Replication)、数据库镜像、日志镜像。数据复制要求:DBMS须采取一定手段用户对DB的修改能及时反映到所有副本上。数据复制技术：在多个场地保留多个数据库副本，各个场地的用户可以并发地存取不同的数据库副本。通过分布式的复制服务器（ReplicationServer）实现。数据复制优点:(1)

当一个用户为修改数据加锁时，其他用户可访问数据库副本；(2)

当数据库出现故障时，系统可用副本进行联机恢复，恢复过程中，用户可继续访问副本而不中断应用。7/23/202311DesignedbyTaoHongcai

对等复制：是理想的复制方式。各场地DB地位平等，可互相复制数据。用户可在任一场地读取/更新公共数据，DBMS应将更新数据复制到所有副本。

数据库复制的三种方式：对等(peer-to-peer)复制、主从(master/slave)复制和级联(cascade)复制。

主从复制：数据只能从主DB复制到从DB。更新数据也只能在主场地进行，从场地供用户读数据。当主场地出现故障时，更新数据的应用可转到某一从场地。7/23/202312DesignedbyTaoHongcai级联复制:从主场地复制来的数据又从该场地复制到其他场地。级联复制可平衡当前各种数据需求对网络流量的压力。7/23/202313DesignedbyTaoHongcai数据库镜像:DBMS为避免磁盘介质故障，提供日志与数据库镜像，由DBMS根据DBA要求，自动将整个DB或其中关键数据复制到另一个磁盘上。当主DB更新时，DBMS自动将更新后的数据复制过去。出现介质故障时，可由镜像磁盘提供应用服务，并利用它进行数据库恢复。其实现是通过复制数据进行。7/23/202314DesignedbyTaoHongcai7.3日志

日志(Log)记录：DB恢复所必需的数据。一.日志基本内容(不同DBMS略有差别)

①活动事务表(ActiveTransactionList,ATL)：记录正在执行、尚未提交的事务标识符(TransactionIdentifier,TID)。日志及DB的存放：日志丢失→DB无法恢复→日志、DB分别存放(分区、磁盘、磁带副本)。

②提交事务表(CommittedTransactionList,CTL)：记录已提交事务的标识符。

注意：提交时，要提交的TID→CTL，从ATL中删除该TID。

③前像(BI)文件：可看成堆(Heap)文件，每个物理块有块标识符(BlockIdentifier,BID)。

④后像(AI)文件：结构类似前像文件，但其记录的是后像。7/23/202315DesignedbyTaoHongcai

②回退时，从前像文件中找出该事务所有前像块，按逻辑块号写入关系对应块中。

③恢复时，可按CTL中的事务次序，按逻辑块号写入后像。

说明：

①BID组成：TID、关系名、逻辑块号。TID为执行更新操作的事务；关系名为被更新的关系；逻辑块号表示该块是关系中哪一块的前像。7/23/202316DesignedbyTaoHongcai二.恢复后对日志的处理

①不保留已提交事务的前像：已提交事务，只会做redo,不会做undo，故其前像可不保留；

②有选择地保留后像：当更新内容写入DB后，如磁盘不出故障，后像可不保留。而磁盘故障机率小，故有些DBMS(如ORACLE)允许用户作出是否保留后像的选择；

③合并后像：对给定逻辑块号，只需保留最近的后像即可。7/23/202317DesignedbyTaoHongcai7.4更新事务的执行与恢复回答如下问题:

1.DBMS需要对进行数据更新的事务做什么样的外围操作，才能在出现故障时顺利地恢复之？

2.如何安排这些事务外围操作的执行步骤？

3.安排事务外围操作步骤时应遵守的规则？7/23/202318DesignedbyTaoHongcai一.事务外围操作安排时应遵守的规则1.提交规则(CommitRule)

该规则要求：后像应在提交前写入DB或日志(均在不易失存储器上)中。说明：

②提交规则不要求后像一定在提交前写入DB，写入日志中亦可，即：如后像已写入日志，即使未写入DB或未完全写入DB，事务仍可提交，待事务提交后再继续写入DB。如此期间出现故障，可用日志的后像重做；其它事务可从缓冲区(未写入DB前更新内容仍在缓冲区)访问更新后的内容。2.先记后写规则(LogAheadRule)

①ACID持久性要求。

该规则要求：如后像在事务提交前写入DB，需先将前像写入日志，以便事务失败后，撤销事务所做的更新。7/23/202319DesignedbyTaoHongcai二.

事务外围操作步骤的安排方案1：后像在事务提交前完全写入DB(1)事务外围操作步骤的安排

①

TIDATL；

③

AIDB； //提交前，后像完全写入DB。

④TIDCTL；//提交。

②BILog； //先记后写规则。按后像写入DB时间的不同，外围操作有三种安排方案。

⑤

从ATL删除TID。※注：

①

该步骤设计涉及的操作：是事务提交操作、事务与日志和数据库有关的操作。可以说，是一些事务外围的操作。

②

该步骤安排：是对这些步骤的执行次序进行安排，而不是安排事务内部的其它操作。7/23/202320DesignedbyTaoHongcai(2)故障时的事务恢复措施如果事务按上步骤执行过程中发生故障，可根据下表进行恢复。ATLCTL事务所处状态恢复措施有无(未提交)步骤1已完成，但步骤4尚未完成①若BI已Log,则undo；否则勿需undo；②从ALT删除TID。有有(已提交)步骤4已完成从ALT删除TID无有(已提交)步骤5已完成勿需处理

※注：①“有”与“无”,表示事务标识符TID是否在ATL或CTL表中。

②CTL表中的“有”与“无”,表示事务“已提交”与“未提交”。7/23/202321DesignedbyTaoHongcai方案2：后像在事务提交后才写入DB(1)事务外围操作步骤安排

①

TIDATL；

③

TIDCTL；//提交。

④AIDB；

②AILog； //提交规则。

⑤

从ATL删除TID。7/23/202322DesignedbyTaoHongcai(2)故障时的事务恢复措施如果事务按上步骤执行过程中发生故障，可根据下表进行恢复。ATLCTL事务所处状态恢复措施有无步骤1已完成，但步骤3未完成从ALT删除TID。有有步骤3已完成，步骤5未完成①redo；②从ALT删除TID。无有步骤5已完成勿需处理7/23/202323DesignedbyTaoHongcai方案3：后像在事务提交前后写入DB(1)事务外围操作步骤安排

①

TIDATL；

③

AIDB； //部分写入

④TIDCTL； //提交

②AI，BILog； //提交规则及先记后写规则

⑤AIDB； //继续完成

⑥

从ATL删除TID。7/23/202324DesignedbyTaoHongcai(2)故障时的事务恢复措施如果事务按上步骤执行过程中发生故障，可根据下表进行恢复。ATLCTL事务所处状态恢复措施有无步骤1已完成，但步骤4尚未完成①若BI已Log,则undo；否则勿需undo；②从ALT删除TID。有有步骤4已完成，但步骤6未完成①redo；②从ALT删除TID。无有步骤6已完成勿需处理7/23/202325DesignedbyTaoHongcai7.5事务内消息的处理

消息及处理要求：事务一般会给用户发送消息，告之其执行情况或要求用户做某些动作。发送消息也是事务执行结果的一部分，亦应遵循NothingorAll原则。但消息与数据不同，在很多情况下很难用undo来消除其影响。一.问题提出

消息管理器及其作用：一般，要求在事务结束(提交或回退)前，不能发送消息。这样，发送消息就不是事务的任务，必须委托第三方执行，一般委托给系统的消息管理器(MessageManager,MM)完成。7/23/202326DesignedbyTaoHongcai

③

事务中止时：MM在恢复时将该事务的消息丢弃，以消除其影响；(1)方法

④

事务结束时：MM将消息队列存入不易失存储器中。MM允许事务在正常结束前增加或删除消息。

注意：消息仅指事务中发送给用户的消息，不包括事务执行过程中，由系统发给用户的消息，如语法错等。

方法：MM采用“发送—确认”方式传送。消息发出后，如确认超时，则再发送一次，直到收到确认信号为止。为防止用户端重复收到同一消息，对消息编号，当用户端收到同一消息时不予理睬。

②事务正常结束时：事务通知MM发送消息；

①

事务执行时：将消息送给MM，MM为每个事务建立一个消息队列；二.消息的具体处理(2)MM的发送处理7/23/202327DesignedbyTaoHongcai7.6失效类型及恢复对策一.失效类型故障恢复能力不是无限的，它只针对某些概率较高类型的失效。

③

介质失效

②系统失效

①

事务失效二.事务失效及恢复

事务的成功执行与结束：一个事务以BEGINTRANSACTION语句的成功执行开始，以COMMIT或ROLLBACK语句的成功执行结束。

提交点：COMMIT建立了一个提交点(CommitPoint)，在商用DBMS产品中也叫同步点(Syncpoint)。

提交点含义：提交点标志着逻辑工作单元的结束，要求DB处于一致状态。(1)基本概念7/23/202328DesignedbyTaoHongcai

③因系统调度差错而中止。

②用户主动撤销事务；

①事务无法执行而中止；

③从ATL删除该事务TID，释放该事务所占资源。

②如需要，进行undo操作；

①MM丢弃该事务的消息队列；(2)事务失效的原因(3)事务失效的恢复措施

④因电源故障而中止。

⑤因介质故障而中止。7/23/202