1、第九章 分布式事务管理与恢复事务概念 事务是访问或更新各种数据项的程序执行单元.事务必须保证数据库的一致性 事务执行期间数据库可能不一致事务概念-续 当事务提交（commit）时数据库必须是一致的DataBaseConsistentConsistentT事务概念-续 两个问题:故障 各种软硬件故障 并发执行 多个事务同时执行事务性质 ACID 原子性（原子性（Atomicity）事务的操作要么全部执行,要么全部不执行 一致性（一致性（Consistency）并发执行的多个事务,其操作的结果应与以某种顺序串行执行这几个事务所得的结果相同.持久性（持久性（Durability）当事务提交后,其操作
2、的结果将永久化,而与提交后发生的故障无关 事务性质-续 独立性（Isolation）虽然可以有多个事务同时执行，但是单个事务的执行不应该感知其他事物的存在，因此事务执行的中间结果应该对其他并发事务隐藏 一对事务 Ti 和 Tj的执行,看起来好像是或者 Ti 在Ti 执行结束之后才开始执行，或者Tj,是在 Ti执行结束之后才开始执行举例 从账号A向账号B转账$50:1.read(A)2.A:=A 50 3.write(A)4.read(B)5.B:=B+50 6.write(B)举例-续 一致性要求 事务执行后A 和 B账号的总金额不变 原子性要求 如果事物在第3步和第6步之间故障,系统应该保证
3、事务对数据库的修改没有产生,否则将导致不一致性举例-续 持久性要求 一旦用户通知说事务已经完成（即$50 转账成功），那么由该事务对数据库的修改就必须保证是永久的，即使是发生故障也如此举例-续 独立性要求 如果在第 3步和第6步之间,允许其他事务访问被修改的数据库的中间结果,那么它将见到一个不一致的数据库(也就是说，A+B 的和少于它的正确值）当然事务的串行执行将不会出现这种情况，但是数据库中事务并行执行的优点就损失了事务状态 活动 从事务开始执行的初始状态始，事务执行中保持该状态 部分提交 事务的最后一个语句执行后进入该状态.失败 一旦发现事务不能正常执行时进入该状一旦发现事务不能正常执行时
4、进入该状态态 夭折 当事务被回滚后，数据库恢复到事务开当事务被回滚后，数据库恢复到事务开始执行前的状态。始执行前的状态。事务夭折后有两种选择 重启动 仅当没有内部逻辑错误时 杀死 提交 当事务成功执行后.事务状态-续SQL中的事务定义 数据操作语言中包含说明一组操作组成一个事务的结构.SQL中,事务隐含的开始.SQL中,如下语句结束事务:Commit work 提交当前的事务,开始一个新的事务.Rollback work 是当前的事务夭折.SQL中事务定义-续 SQL-92中事务一致性级别:Serializable 缺省 Repeatable read Read committed Read
5、uncommitted分布式事务 分布式事务是由若干个不同Site上的子事务组成的事务 事务的ACID性质此时事务的原子性、一致性、持久性、独立性等都要将每个Site上的子事务考虑在内分布式事务结构Begin Trans .Abort/CommitBegin Trans T1 T2 .Tn Abort/Commit进程协作 进程 系统中可以并行执行的一段操作序列，分布式事务中的子事务序列是进程方式完成 过程 不可并行执行的操作序列 事务代理（Agent）应用在各个Site上执行的若干进程，称作应用在该Site上的代理。代理可以执行应用程序员写的程序，也可以执行系统的原语函数，不同代理间通过报文
6、实现通讯 根代理（Root Agent）应用启动Site上的代理。根代理所在的Site称作原发Site.一般，根代理负责发系统原语，只有根代理可以请求创建新代理。转账应用事务在两个账户之间执行“基金汇兑”操作。全局关系 Account(Account-number,Amount)假设账户分布在网络的不同站点上。全局级转帐事务FUND_TRANSFER:read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);begin_transaction;select AMOUNT into$FROM_AMOUNT from ACCOUNT where ACCOUNT_NUMBER
7、=$FROM_ACC;if$FROM_AMOUNT-$AMOUNT0 then abortelse begin update ACCOUNT set AMOUNT=AMOUNT$AMOUNT where ACCOUNT_NUMBER=$FROM_ACC;update ACCOUNT set AMOUNT=AMOUNT$AMOUNT where ACCOUNT_NUMBER=$TO_ACC;commitend输入：汇出金额和转入/转出帐号事务开始：检查转出帐号中是否 有足够的转出资金？更新转出帐号存款余额创建AGENT1向代理1送消息：转入帐号，金额等待来自AGENT1的消息成功？提交事务：成功
8、结束撤消事务：失败结束ROOT_AGENTAGENT接收来自根代理的信息更新转入帐号存款余额发送执行消息给根代理(成功或失败)是否否转账应用处理流程ROOT_AGENT;read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);begin_transaction;select AMOUNT into$FROM_AMOUNT from ACCOUNT where ACCOUNT_NUMBER=$FROM_ACC;if$FROM_AMOUNT-$AMOUNT0 then abortelse begin update ACCOUNT set AMOUNT=AMOUNT-$AM
9、OUNT where ACCOUNT_NUMBER=$FROM_ACC;create AGENT;send to AGENT($AMOUNT,$TO_ACC);commit/*这里省略了等待消息和判别*/endAGENT;receive from ROOT_AGENT($AMOUNT,$TO_ACC);update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where ACCOUNT=$TO_ACC;send to ROOT_AGENT(SUCCESS/FALL)转账事务的两个代理事务管理目标 目的 事务能有效、可靠、并发的执行 效率的几个重要方面 CPU和主存的使用
10、 控制报文 响应时间 可用性 目标 维护事务的ACID性质 获得最小的主存和CPU开销，降低报文数目，加快响应时间 获得最大限度的可靠性和可用性事务管理 DTM功能 保证分布式Trans的特征，特别是原子性 支持分布式Trans执行的位置传递 LTM功能 保证本地Trans的特征 代替DTM把分布Trans的执行与恢复信息记入Log 接收并遵从本Site上DTM发来的Log原语，记入Log并执行之DTMLTMSiteLog原语：Local Begin-Trans,Local-Commit,Local-Abort分布式Trans执行的控制模型 主从模型 LTM之间无通信 三角模型 LTM之间有通
11、信 层次控制模型 LTM之间有通信，并且LTM还可再创建Agent，控制其它LTM执行分布式事务管理器局部事务管理器局部事务管理器局部事务管理器数据库数据库数据库命令命令命令回答回答回答主从控制分布式事务管理器局部事务管理器局部事务管理器数据库数据库命令命令回答回答临时数据三角控制分布式事务管理器局部事务管理器数据库命令命令回答回答局部事务管理器局部事务管理器局部事务管理器局部事务管理器局部事务管理器命令命令命令命令回答回答回答回答数据库数据库数据库数据库数据库层次控制故障类型 事务故障由非预期的、不正常的程序结束所造成的故障，即事务没有执行到Commit或显示Rollback语句的故障，如：
12、溢出、死循环等内存、磁盘上信息没有损失，使用Log做Rollback 系统故障造成系统停止运行的任何事件，要求系统重启动内存、I/O Buffer内容皆丢失，DB没有破坏，恢复时，搜索Log,确定Rollback的Trans。设置检查点故障类型-续 介质故障辅助存储器介质遭破坏 数据丢失,日志无损失 从某个Dump状态开始执行已提交事务 数据与日志都丢失 不可能完全恢复 通讯故障前三种统称为站点故障.通讯故障 通讯发生,既有某个报文Message从Site x 发往Site y,正常情况:(a)在Dmax 之后,x 站点收到y发回的应答信息(Ack)(b)y收到的Message是一个合适的次序
13、(c)Message本身的信息是正确的 但是当某个Dmax之后,x还没收到y的Ack,则可能发生:(a)Message 或 Ack 信息丢失 (b)网络分割,及网络不通通讯故障-续 问题可以进一步分为:a)是否是所在Site故障,还是系统慢下来了?b)若是故障,是通讯故障,还是 y 站点故障?c)Message 是否已到达 y 站点?对上述故障,其恢复程序可以有不同级别:一级:仅处理Site故障二级:Site故障及Message故障三级:Site故障及Message故障,还包括网络分割日志 Log 记录所有对DB的操作 事务标识 每个事务给定一个具有唯一性 的标识符 Log记录项:开始,T,提
14、交,T,夭折,T,读,T,x,写,T,x,旧值,新值 DB写动作 Log优先 Log存储 一般存在盘上,事务提交时,Log Buffer强迫写Log举例Log Write Output A=950 B=2050 C=600 BB,BA BC注:BX 表示含有X的存储块.数据访问xYABx1y1 缓冲区缓冲块 A 缓冲块 Binput(A)output(B)read(X)write(Y)磁盘 T1工作区T2 工作区主存x2日志缓冲区数据库缓冲区(易变数据库)局部恢复管理器数据库缓冲区管理器主存取出读/写读/写日志档案库DB档案库稳定日志稳定DB读/写读/写日志恢复举例 两个事务 T0 和 T1(
15、T0 在 T1前执行):T0:read(A)T1:read(C)A:=A-50C:=C-100Write(A)write(C)read(B)B:=B+50write(B)日志恢复举例-续 事务执行在不同时刻的日志.日志恢复举例-续 故障发生时刻不同，处理不同:(a)无动作(b)由于有，必须 redo(T0)(c)由于 和 都出现，必须依次执行 redo(T1)和 redo(T0)检查点 日志恢复问题日志恢复问题:搜索整个日志非常耗时搜索整个日志非常耗时 某些已经写入数据库的更新还要重复执行某些已经写入数据库的更新还要重复执行.检查点-续 检查点检查点 设置一个周期性操作点a)Log Buffe
16、r写入Log数据集b)写检查点Log项,当前活动事务表,每个事务最近一次Log记录在Log文件中的位置c)DB Buffer写入DBd)将检查点Log项在Log文件中的位置记入“重启动文件”检查点-续 T1 可以忽略(因为有检查点，更新已经被写入磁盘)T2 和 T3 redone.T4 undoneTcTfT1T2T3T4checkpointsystem failure事务故障恢复 恢复原则 孤立和逐步退出事务的原则 undo 事务已对DB的修改 (不影响其他事务的可排除性局部故障)成功结束事务原则 Redo 已成功事务的操作 夭折事务原则 撤销全部事务,恢复到初态(Undo)事务故障恢复-续
17、 本地事务恢复 (与集中式恢复相同)从“重启动文件”读出最近Checkpoint的地址,并定出Checkpoint在Log文件中的位置 创建Redo表,Undo表(即Checkpoint相应内容中的活动事务表)检查得出Redo事务与Undo事务 反向检索Log,将Undo表中事务,直到遇到对应的Begin Trans 正向检索Redo事务的Log记录,并执行之,直到对应的Commit记录重启动文件UNDOREDO活动事务表故障发生地址c0c1(1)(3)(5)(2)(4)Log data set利用日志进行事务恢复过程 分布式事务恢复参考模型RootAgentAgentAgentDTM-Age
18、nt站点1的LTMDTM-AgentDTM-Agent站点2的LTM站点n的LTM全局事务分布式事务管理器(DTM)局部事务 管理器 (LTM).Begin Transaction.Create Agent1Send to Agent1.Local-begin.Send Create ReqWriteBegin-transactionin Local LogRoot AgentDTM-AgentLTMReceive.Local CreateLocal-begin.WriteBegin-transactionin Local LogLTMDTM-Agent Agent1132456782PC协议
19、 基本思想 将本地原子性提交行为的效果扩展到分布式事务,保证了分布式事务提交的原子性,并在不损坏Log的情况下,实现快速故障恢复,提高DDB系统的可靠性.第一阶段 表决阶段 第二阶段 执行阶段 两类代理 协调者(Coordinator)参与者(Participants)初始写begin_commit到日志等待有要求撤消的？写commit到日志提交写end_of_transt到日志初始准备提交？写ready到日志就绪消息类型？写abort到日志写commit到日志提交撤消撤消写abort到日志写abort到日志协调者参与者nonoabortcommit准备撤消提交全局撤消全局提交ACKACK2P
20、C的通讯结构 集中式通讯只发生在协调者和参与者之间，参与者之间不交换信息 分层式协调者是在树根的DTM代理者，协调者与参与者之间的通讯不用直接广播的方法进行，而是使报文在树中上下传播。每个DTM代理这是通信树的一个内部节点，它从下层节点除收集报文或向他们广播报文。线性 参与者之间可以互相通信。系统中的站点间要排序 分布式允许所有参与者在第一阶段相互通信，从而可以独立做出事务终止决定。23451234511协调者参与者协调者协调者参与者第一阶段第二阶段准备建议撤消/提交全局撤消/提交提交/撤消集中式34251511协调者参 与 者协调者协调者参 与 者第一阶段第二阶段准备建议撤消/提交全局撤消/
21、提交提交/撤消23422分层式1234n第一阶段第二阶段准备建议提交/撤消建议提交/撤消建议提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消全局提交/撤消线性式1n4324321n协调者协调者协调者+参与者第一阶段准备建议撤消/提交全局撤消/提交可独立做决定分布式 信息协议程序 p.96-982PC与故障恢复1.站点故障a 参与者在将“Ready”记录入Log之前故障此时协调者达到超时，Abort发生。站点（P）恢复时，重启动程序将执行Abort，不必从其他站点获取信息。b 当将“Ready”写入Log后，P故障此时所有运行的站点都将正常结束事务（Commit/Abort)。P恢复时，因为
22、P已Ready，所以不可判定C的最终决定。因此恢复时，重启动程序要询问C或其他站点。c 当C将“Prepare”写入Log，但“G-commit”/”G-abort”还没有写入是故障所有回答“Ready”的P等待C恢复。C重启动时，将重开提交协议，重发“Prepare”，于是P要识别重发。d C在将“G-commit”/”G-abort”写入Log后，“Complete”没有写入前故障收到命令的P正常执行，C重启动程序必须再次向所有P重发命令。以前没有收到命令的P也必须等待C恢复，P要识别两次命令。e“Complete”写入Log后故障无任何动作发生2PC与故障恢复-续2.报文丢失a 从P发出
23、的“Ready”/“Abort”报文丢失C达到超时，整个事务执行“G-abort”。该故障仅能被C识别，此时C认为P故障，但P并无故障，不需执行重启动程序。b “Prepare”报文丢失P等待，C得不到回答，结果同2.ac “G-commit”/”G-abort”报文丢失P处于不确定状态。回答“Abort”的可以确定其工作，回答“Ready”的不行。此时可以修改加入计时器，超时则申请重发命令。d “Ack”报文丢失C超时，可重发“G-commit”/”G-abort”命令，P无论是否有活动，都重发“Ack”报文2PC与故障恢复-续3.网络分割假设分成两组。一组是协调者，一组是参与者。于是从协调
24、者看是参与者组故障，结果同1.a,1.b。从参与者组看是协调者站点故障，动作如1.c,1.d。初始写begin_commit到日志等待有要求撤消的？写commit到日志提交写Complete到日志初始准备提交？写ready到日志就绪消息类型？写abort到日志写commit到日志提交撤消撤消写abort到日志写abort到日志协调者参与者nonoabortcommit 2.b 准备2.a撤消2.a 提交2.c全局撤消全局提交ACKACK1.c1.d1.e1.a1.b2.d业务规则的一致性 有效性约束 域约束 数据依赖约束 实体完整性和引用完整性 例子 取现金时 一个账户的存款余额必须等于或大于
25、零 转账时一个账户的存款余额必须等于或大于零.事务结束时,两账户中存款总和,必须与事务开始时两账户存款之和相同 定期利息计算事务执行后,所有账户存款之和比事务开始前各账户存款总和大于10%冗余数据的一致性 冗余数据必须保持一致 例子site1 site2T1:Read(x)x=x*1.1 write(x)T2:Read(x)x=x-20 write(x)设数据x在两个站点都有副本.两个事务分别执行,这样两个事务的执行会产生不同的结果.处置x=50,T2T1的执行顺序得到 x=33 (x-20)*1.1=(50-20)*1.1 T1T2的执行顺序得到 x=35 (x*1.1)-20=50*1,1
26、)冗余数据的一致性-续 异步复制器 冗余数据绝对保持一致是不可能的,一般允许对冗余数据的修改有暂时的不一致.复制数据库的应用 向分站点发送只读数据 在一个周期结束时从分站点对中心站点复制这个周期内改变过的数据 复制数据并建立决策支持系统 建立关键数据的备份副本冗余数据的一致性-续 不同复制器的差别a 何时在主copy上获取数据b 何时把主副本上的数据用到辅助副本上 对a有方法 1.数据驱动:当事务修改主副本时,获取有关数据修改信息,并将其写到一个获取文件或队列中.2.计时器驱动:由系统在用户定义的时间间隔自动获取相关数据修改信息 3.应用程序驱动:有应用中的事件引发系统从主副本把数据复制到获取
27、文件或队列中 冗余数据的一致性-续 对b有方法 1.数据驱动:在主副本上由修改Trans所做的修改,立即复制,传输和应用于辅存储器 2.计时驱动:修改Trans在主副本上的修改,在用户定义的区间应用于辅助副本 3.应用程序驱动:由应用中的事件引发系统获取文件或队列对辅助副本进行修改 DDB中的更新 多站点数据更新 方法 站点A上有Trans T对x更新,x在B1,Bn和C1,Cm上有副本,则也要对这些副本更新 问题 多个站点同时更新不现实 对未连通站点上的副本更新增多时出错,更新的顺序也不一定是连通顺序DDB中的更新-续 主副本更新 思想 指定主副本,修改只对主副本进行,修改辅助副本时,也按在
28、主副本上执行的更新顺序执行 问题 修改传播必须在段时间内完成,否则将获得“过时”数据 主副本不可用,引得其他副本也不可用“移动主副本”方法DDB中的更新-续 快照(Snapshot)与视图相似,是导出的关系 实数据库 周期地更新 用于某些需要“冻结”数据的应用 DDB中的更新-续 定义 VAR SNAPSHOT REFRESH EVERY 可以是:MONTH,WEEK,DAY,HOUR,n MINUTES,MONDAY,WEEKDAY,DDB中的更新-续 例子 Define Snapshot HP-Book as SELECT *FROM Book WHERE Price$100 REFRESH Every day 特点 快照不考虑数据的辅助副本,只关心主副本和主副本上定义的多个快照 快照与视图一样可以定义为一个或多个主副本的部分或全部 快照可以完成复杂的查询,但又不阻止更新作业:假设两个事务T 和 U 的 undo log 记录如下所示:,如果系统故障时,磁盘上记录的Log记录如下,请描述数据库恢复管理器的动作.a)b)c)d)
