事务管理课件

第七章事务管理数据库系统的另一个核心功能数据库系统安全性和完整性的主要保障恢复并发控制事务事务：用户定义的一组逻辑上相关的数据库操作构成的序列，这些操作要么全做要么全不做，是一个不可分割的工作单位。指应用逻辑上相关的操作 读,写,修改,插入,删除等 一般只考虑读和写(read/write)事务(c)可以仅仅由一个或多个操作构成 例如交互命令状态下只有一个操作也可以把操作序列分散在应用程序中 在begin-trans和commit之间的操作构成

BEGINTRANSACTION ．．． COMMIT或ROLLBACK

事务的特性原子性(Atomicity):事务在执行时，应“要么不做，要么全做”，不允许部分完成一致性(Consistency)：事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态隔离性(Isolation)：一个事务的执行不能被其他事务干扰。持续性(Durability)：一个事务提交后，对数据库中的数据的改变是永久性的，不应故障对其执行结果有影响。begin_transaction() read(A) A:=A-50

write(A) IfA<0 Then begin display“Ａ帐户余款不足”

ROLLBACK end ELSE begin read(B) B:=B+50 write(B)

COMMIT endend_transaction()事务的例子银行转账款项从Ａ帐户转帐至Ｂ帐户故障类型事务失败逻辑错误：一个事务由于其内部错误，导致不能正常结束（如事务内部的死循环）系统错误：系统进入一个不良状态（如死锁），导致事务无法执行。但该事务在以后的某个时间可以重新执行。系统崩溃：如电源问题、其它软硬件引起的系统停机。一般这种情况下非易失存储设备的数据不会丢失硬盘故障：硬盘故障可能会导致数据的丢失。恢复所需要的设施复本：指数据库的数据备份一般是指整个的数据库的备份定期做备份在磁带上增量备份，在一个完整备份的基础上，只备份被修改过的物理块或数据能节约备份介质实验DB2中的“backup/restore”命令恢复所需要的设施（C）•

日志（运行记录）

一个日志保存在稳定的存储介质上。日志由日志记录按序组成，每个记录反映了对数据库的一次修改活动

日志种类二另外一种日志形式中，把上述X取为一个物理块，则一个日志记录包含了如下三部分：

1.前像（BeforeImage)：

当一个事务更新数据时，所涉及的物理块在更新前的映像称为该事务的前像，可以据此使数据库恢复到更新前的状态（撤消更新undo）。 2.后像（AfterImage)

当一个事务更新数据时，所涉及的物理块在更新后的映像称为该事务的后像，可以据此使数据库恢复到更新后的状态（重做redo）。 3.事务状态 成功（committed)/失败（rollback,abort)这种形式的日志记录意味着一个事务的一次执行只对应一个日志记录。后面均指这种类型的日志。恢复的方法所谓恢复就是把数据库从错误的不一致状态，或者从以前的状态恢复到

一个一致状态（一般是最近的一致状态）。

1用最近的数据库后备副本进行恢复 （图7-1）时间数据库状态S备份1恢复备份1状态S失效更新丢失恢复的方法2用数据库后备副本加增量转储进行恢复（图7-2）状态S备份1恢复备份1恢复增量备份1恢复增量备份2状态S2数据库状态S1增量备份1失效状态S2增量备份24向前恢复(forwardrecovery)：

对于已提交的事务，用后像重做，使数据库恢复到事务更新后的状态，称为REDO（重做）操作。状态S备份1redo事务状态S1数据库状态S1后像失效forward事务时间恢复的方法（C）用多复本进行恢复系统中据有多个独立的数据库复本。各复本的支撑环境不同。镜像磁盘技术事务的递交执行和恢复

要用到的设施事务的标记TID、活动事务表ATL、递交事务表CTL事务的标识符：TID活动事务表ATL：记录正在执行尚未提交的事务TID提交事务表CTL：记录所有已提交的事务的标识符TID。日志文件：前像文件（BI）、后像文件（AI）事务提交和恢复的三种实现策略1后像在提交点前完全写入数据库（p140）

(1)TID->ATL (2)BI->log (3)AI->DB (4)TID->CTL (5)从ATL删除TID 步骤(4)是提交点提交规则：后像在提交前写入了数据库

先记后写规则

ATLCTL有-有有-有思考：如果(3)执行完,(4)未执行完,则应如何处理?

事务提交和恢复的三种实现策略(C)2后像在事务提交点后才写入数据库（p139） (1)TID->ATL (2)AI->log (3)TID->CTL (4)AI->DB (5)从ATL删除TID

步骤3是提交点提交规则：后像在提交前写入了日志先记后写规则？思考：如果(2)执行完,(3)未执行完,则应如何处理?

失效的类型和恢复的对策1、事务失效：

事务在运行至正常终止点前因各种原因被终止。采用的恢复措施：MM丢弃该事务的消息队列如果需要，进行undo从ATL删除该事务的TID，释放该事务所占资源由系统自动完成，对用户透明。失效的类型和恢复的对策（续）2、系统失效：

系统掉电、硬软件故障（除存储介质）造成数据库不一致：未完成的事务对数据库的更新已写入数据库；已提交的事务对数据库的更新还留在缓冲区没来得及写入数据库。采用的恢复措施：重新启动OS和DBMS恢复数据库至一致状态（对未提交的事务进行undo，对已提