《事务管理》PPT课件

2.1Database System数据库系统的另一个核心功能数据库系统安全性和完整性的主要保障包括：恢复并发控制2.2Database Systemw事务：用户定义的一组逻辑上相关的数据库操作构成的序列，这些操作要么全做要么全不做，是一个不可分割的工作单位。w指应用逻辑上相关的操作读,写,修改,插入,删除等一般只考虑读和写(read/write)2.3Database System事务(c)可以仅仅由一个或多个操作构成例如交互命令状态下只有一个操作也可以把操作序列分散在应用程序中在begin-trans和commit之间的操作构成BEGIN TRANSACTIONCOMMIT 或 ROLLBACK 2.4Database Systemn事务执行对数据库的影响H执行前：数据库的状态必须是一致状态必须是一致的H执行中：状态可能不一致H执行后：数据库的状态必须是一致的2.5Database Systemn原子性(Atomicity):H事务在执行时，应“要么不做，要么全做”，不允许部分完成n一致性(Consistency)：H事务执行的结果必须是使数据库从一个一致性状态变到另一 个一致性状态n隔离性(Isolation)：H一个事务的执行不能被其他事务干扰。n持续性(Durability)：H一个事务提交后，对数据库中的数据的改变是永久性的，不应故障对其执行结果有影响。2.6Database Systembegin_transaction()read(A)A:=A-50write(A)If A0Then begindisplay“帐户余款不足”ROLLBACKendELSEbeginread(B)B:=B+50write(B)COMMITendend_transaction()款项从帐户转帐至帐户款项从帐户转帐至帐户2.7Database System2.8Database System2.9Database System2.10Database System2.11Database System2.12Database System保证事务的ACID准则，从以下两方面：1 事务在并发执行时并发控制技术2 事务在故障发生后恢复机制2.13Database Systemn事务失败H逻辑错误：一个事务由于其内部错误，导致不能正常结束（如事务内部的死循环）H系统错误：系统进入一个不良状态（如死锁），导致事务无法执行。但该事务在以后的某个时间可以重新执行。n系统崩溃：如电源问题、其它软硬件引起的系统停机。一般这种情况下非易失存储设备的数据不会丢失n硬盘故障：硬盘故障可能会导致数据的丢失。2.14Database Systemn复本：指数据库的数据备份H一般是指整个的数据库的备份H定期做备份在磁带上H增量备份，在一个完整备份的基础上，只备份被修改过的物理块或数据4能节约备份介质H实验DB2中的“backup/restore”命令2.15Database Systemn 日志（运行记录）一个日志保存在稳定的存储介质上。日志由日志记录按序组成，每个记录反映了对数据库的一次修改活动2.16Database Systemn一种日志是把写操作记录下来：n当事务Ti开始时，Ti先在日志文件中写入如下的记录：nn当Ti对记录X执行写操作write（X）时，首先写入日志记录,其中V1是上述写入操作前X的值，V2是新写入的值n当Ti结束最后一条语句时，写入的日志记录n这里可以先假设日志记录是不经过缓存直接写到稳定的存储介质上的。2.17Database Systemn另外一种日志形式中，把上述X取为一个物理块，则一个日志记录包含了如下三部分：1.前像（Before Image)：当一个事务更新数据时，所涉及的物理块在更新前的映像称为该事务的前像，可以据此使数据库恢复到更新前的状态（撤消更新undo）。2.后像（After Image)当一个事务更新数据时，所涉及的物理块在更新后的映像称为该事务的后像，可以据此使数据库恢复到更新后的状态（重做redo）。3.事务状态成功（committed)/失败（rollback,abort)这种形式的日志记录意味着一个事务的一次执行只对应一个日志记录。后面均指这种类型的日志。2.18Database System所谓恢复就是把数据库从错误的不一致状态，或者从以前的状态恢复所谓恢复就是把数据库从错误的不一致状态，或者从以前的状态恢复到到 一个一致状态（一般是最近的一致状态）。一个一致状态（一般是最近的一致状态）。1 用最近的数据库后备副本后备副本进行恢复（图7-1）时间数据库状态S备份1恢复备份1状态S失效更新丢失2.19Database System2 用数据库后备副本加增量转储进行恢复（图7-2）状态S备份1恢复备份1恢复增量备份1恢复增量备份2状态S2数据库状态S1增量备份1失效状态S2增量备份22.20Database System用最近的数据库后备副本加日志进行恢复3 向后恢复向后恢复（backward recovery)：对于未提交的事务，对于未提交的事务，用前像卷回，使数据库恢复到事务更新用前像卷回，使数据库恢复到事务更新前的状态，即撤消更新，称为前的状态，即撤消更新，称为UNDO（撤消）操作。撤消）操作。状态S备份1事务rollback状态S1数据库状态S1前像abortbackward事务时间时间2.21Database System4 向前恢复向前恢复(forward recovery)：对于已提交的事务，用后像重做，使数据库恢复到事务更新后的对于已提交的事务，用后像重做，使数据库恢复到事务更新后的状态，称为状态，称为REDO（重做）操作。重做）操作。状态S备份1redo事务状态S1数据库状态S1后像失效forward事务时间时间2.22Database Systemn用多复本进行恢复H系统中据有多个独立的数据库复本。各复本的支撑环境不同。H镜像磁盘技术2.23Database Systemn要用到的设施H事务的标记TID、活动事务表ATL、递交事务表CTL4事务的标识符：TID4活动事务表ATL：记录正在执行尚未提交的事务TID4提交事务表CTL：记录所有已提交的事务的标识符TID。H日志文件：前像文件（BI）、后像文件（AI）2.24Database Systemn遵循的规则H提交规则commit rule：在进行提交前，先保存后像到非易失存储器中（运行记录或数据库）4防止递交时出错，从而丢失处理结果H先记后写规则log ahead rule:如果后像在提交前就写入数据库，则前像应先保存在日志中。4防止在最后提交时失败，不能恢复到最初状态2.25Database Systemn 1 后像在提交点前完全写入数据库（p140）(1)TID-ATL(2)BI-log(3)AI-DB(4)TID-CTL(5)从ATL删除TID步骤(4)是提交点提交规则：后像在提交前写入了数据库 先记后写规则 ATLCTL有-有有-有思考：如果思考：如果(3)执行完执行完,(4)未执行完未执行完,则应如何处理则应如何处理?2.26Database Systemn2 后像在事务提交点后才写入数据库（p139）(1)TID-ATL(2)AI-log(3)TID-CTL(4)AI-DB(5)从ATL删除TID 步骤3是提交点提交规则：后像在提交前写入了日志先记后写规则？思考：如果思考：如果(2)执行完执行完,(3)未执行完未执行完,则应如何处理则应如何处理?2.27Database System3 部分后像在提交点前写入数据库,部分在提交点后(如数据库空闲时)才写入数据库(p140)TID-ATLAI,BI-logAI-DB（部分写入）TID-CTLAI-DB（继续完成）从ATL删除TID 提交点是步骤4 有利于并发操作有利于并发操作提交规则：后像在提交前写入了日志先记后写规则 2.28Database System消息序列的发送和接收也应具有原子性要么全部发送并接收到要么一个都没有发出和接收在事务结束前，不能发出任何消息（防止事务卷回），所有消息放在一个消息队列中，当提交后，再发出。发给操作者的临时性消息除外。MM（message manager)子系统：为每个事务建立消息队列，发送、丢弃消息。由事务通知发送消息。消息保存在不易失存储器中可靠地发送。（应答方式）消息处理在实际中是非常关键的。著名的产品有IBM的MQ，是一个中间件软件。2.29Database System1、事务失效：事务在运行至正常终止点前因各种原因被终止。q采用的恢复措施：HMM丢弃该事务的消息队列H如果需要，进行undoH从ATL删除该事务的TID，释放该事务所占资源q由系统自动完成，对用户透明由系统自动完成，对用户透明。2.30Database System2、系统失效：系统掉电、硬软件故障（除存储介质）造成数据库不一致：未完成的事务对数据库的更新已写入数据库；已提交的事务对数据库的更新还留在缓冲区没来得及写入数据库。q采用的恢复措施：4重新启动OS和DBMS4恢复数据库至一致状态（对未提交的事务进行undo，对已提交的事务进行redo）q系统在重启时自动完成，不需要用户干预。2.31Database System3、介质失效：磁盘上的物理数据和日志文件被破坏。q采用的恢复措施：4修复系统4如果系统崩溃，重启系统4加载最近后备复本4用运行记录中的后像，重做取最近后备复本以后提交的所有事务