崔明义
（ mycui369@126.com)
计算机应用技术 2007级研究生
1,分布式事务概述
2.分布式事务的执行和恢复
3.两阶段提交协议
4.分布式数据库中的数据更新
5.分布式事务增强数据库一致性
6.总结分布式数据库中的事务管理和恢复第 4章事务概念
事务是访问或更新各种数据项的最小逻辑工作单位。
它是一个操作序列
它可以使数据库从一个一致状态到另外一个一致状态
事务必须保证数据库的一致性
事务执行期间数据库可能不一致
1.1 分布式事务定义和特性
1 分布式事务概述
当事务提交（ commit）时数据库必须是一致的事务 T开始 事务 T结束事务 T的执行数据库一致数据库一致数据库可能临时不一致
1.1 分布式事务定义和特性
1 分布式事务概述事务概念分布式事务
集中式
– 事务和操作数据在一个站点上
– 不存在传输费用
分布式
– 操作数据分布在不同的站点上
– 事务也在多个站点上执行
– 分布式事务是集中式事务的扩充
– 站点和通信连路故障都可能导致错误发生
– 分布式事务的恢复要比集中式事务复杂的多
1.1 分布式事务定义和特性
1 分布式事务概述
事务分类,
– 全局事务
通常由一个主事务和在不同站点上执行的子事务组成
主事务：负责事务的开始、提交和异常终止
子事务：完成对相应站点上的数据库的访问操作
– 局部事务
仅访问或更新一个站点上的数据的事务
1.1 分布式事务定义和特性
1 分布式事务概述分布式数据库中的事务
ACID特性
– 原子性（ Atomicity）
事务的操作要么全部执行,要么全部不执行,保证数据库一致性状态
– 一致性（ Consistency）
事务的正确性，串行性，并发执行的多个事务,其操作的结果应与以某种顺序串行执行这几个事务所得的结果相同,
– 持久性（ Durability）
当事务提交后,其操作的结果将永久化,而与提交后发生的故障无关
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性
– 隔离性（ Isolation）
虽然可以有多个事务同时执行，但是单个事务的执行不应该感知其他事务的存在，因此事务执行的中间结果应该对其他并发事务隐藏
– 此外，分布式数据库系统中还要考虑 数据传送、
通信原语和控制报文 等。
全局事务的主事务和子事务全部成功提交，
才能改变数据库状态，有一个失败，其他子事务操作都要撤销。
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性
从账号 A向账号 B转账 $50:
1,read(A)
2,A,= A – 50
3,write(A)
4,read(B)
5,B,= B + 50
6,write(B)
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性举例
一致性要求,事务执行后 A 和 B账号的总金额不变
原子性要求,如果事物在第 3步和第 6步之间故障,系统应该保证事务对数据库的修改没有产生,否则将导致不一致性
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性举例
持久性要求,一旦用户通知说事务已经完成（即 $50 转账成功），那么由该事务对数据库的修改就必须保证是永久的，即使是发生故障也如此
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性举例
独立性要求 如果在第 3步和第 6步之间,允许其他事务访问被修改的数据库的中间结果,那么它将见到一个不一致的数据库
(也就是说,A + B 的和少于它的正确值）
当然事务的串行执行将不会出现这种情况，
但是数据库中事务并行执行的优点就损失了
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性举例
Begin Transaction原语：开始一个事务
T1[]
T2[]
,子事务或操作序列
:
Tn[]
Commit原语：事务成功完成的结束
Rollback或 Abort原语：事务失败的结束
1.2 分布式事务结构和事务状态
1 分布式事务概述分布式事务的一般结构
活动 从事务开始执行的初始状态始,事务执行中保持该状态
部分提交 事务的最后一个语句执行后进入该状态,
失败 一旦发现事务不能正常执行时进入该状态
夭折 当事务被回滚后，数据库恢复到事务开始执行前的状态。 事务夭折后有两种选择
– 重启动 仅当没有内部逻辑错误时
– 杀死
提交 当事务成功执行后,
1.2 分布式事务结构和事务状态
1 分布式事务概述分布式事务的状态
1.2 分布式事务结构和事务状态
1 分布式事务概述分布式事务的状态
进程：系统中可以并行执行的一段操作序列，分布式事务中的子事务序列是进程方式完成的
– 进程说明：定义进程的行为模式，数据和数据上的操作，功能等
– 进行执行：按模式来启动这个进程，执行其中的操作
过程：不可并行执行的操作序列
事务代理（ Agent）：应用在各个 Site上执行的若干进程，
称作应用在该 Site上的代理。代理可以执行应用程序员写的程序，也可以执行系统的原语函数，不同代理间通过报文实现通讯
根代理（ Root Agent） 应用启动 Site上的代理。根代理所在的 Site称作原发 Site,一般，根代理负责发系统原语，只有根代理可以请求创建新代理。
1.2 分布式事务结构和事务状态
1 分布式事务概述进程相关定义
为了协调执行分布式应用的全局操作，分驻于不同站点的诸事务代理必须进行协调，有如下规定：
– 每一应用都有一个负责启动整个事务的总代理（或称根代理）
– 只有总代理才能发出全局有效的事务开始、提交和撤消原语
– 只有总代理才能请求建立新的事务代理
– 各站点上的子事务都执行成功，总代理才能决定提交该事务，否则总代理将决定撤销该事务
1.2 分布式事务结构和事务状态
1 分布式事务概述进程协作转账应用事务在两个账户之间执行“基金汇兑”操作。
如果汇兑的金额小于转出帐号现有金额，就撤销如果大于等于就提交全局关系
Account (Account-number,Amount)
假设账户分布在网络的不同站点上。
1.2 分布式事务结构和事务状态
1 分布式事务概述全局级转帐事务
FUND_TRANSFER:
read (terminal,$AMOUNT,$FROM_ACC,$TO_ACC);
begin_transaction;
select AMOUNT into $FROM_AMOUNT from ACCOUNT
where ACCOUNT_NUMBER=$FROM_ACC;
if $FROM_AMOUNT-$AMOUNT<0 then abort
else begin
update ACCOUNT
set AMOUNT = AMOUNT-$AMOUNT
where ACCOUNT_NUMBER = $FROM_ACC;
update ACCOUNT
set AMOUNT = AMOUNT-$AMOUNT
where ACCOUNT_NUMBER = $TO_ACC;
commit
end
输入：汇出金额和转入 /转出帐号事务开始：检查转出帐号中是否有足够的转出资金？
更新转出帐号存款余额创建 AGENT1
向代理 1送消息：转入帐号，金额等待来自 AGENT1的消息成功？
提交事务：成功结束 撤消事务：失败结束
ROOT_AGENT AGENT
接收来自根代理的信息更新转入帐号存款余额发送执行消息给根代理
(成功或失败 )
是 否否转账应用处理流程
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-$AMOUNT<0 then abort
else begin
update ACCOUNT
set AMOUNT = AMOUNT-$AMOUNT
where ACCOUNT_NUMBER = $FROM_ACC;
create AGENT;
send to AGENT($AMOUNT,$TO_ACC);
commit/*这里省略了等待消息和判别 */
end
AGENT;
receive from ROOT_AGENT($AMOUNT,$TO_ACC);
update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where
ACCOUNT=$TO_ACC;
send to ROOT_AGENT(?SUCCESS?/?FALL?)
转账事务的两个代理分布式事务管理问题
处理数据项的多个副本
– 分布式事务处理负责保持同一数据的多个副本之间的一致性。当某个副本所在站点发生故障时，负责生成与该数据其他副本一致的拷贝，以便于及时恢复。
单个站点的故障
– 一个站点或多个站点故障时,DDBMS继续与其他正常运行的站点一起继续工作
– 当故障站点恢复时,DDBMS协同故障站点的 DBMS，必须使得该站点与系统连接时，局部数据库与其他站点同步
通信网络的故障
– 必须能够处理两个或者多个站点间的通信网络故障
分布式提交
– 如果提交分布式事务过程中有一个站点发生故障，提交就会产生问题
– 两阶段提交协议用于解决这一问题
1.3 分布式事务管理的问题和目标
1 分布式事务概述分布式事务管理目标
目的：事务能有效、可靠、并发的执行
除了策略之外，效率的几个重要方面
– CPU和主存的使用
– 控制报文
– 响应时间
– 可用性
目标
– 维护事务的 ACID性质
– 获得最小的主存和 CPU开销，降低报文数目，加快响应时间
– 获得最大限度的可靠性和可用性
1.3 分布式事务管理的问题和目标
1 分布式事务概述抽象模型
LTM,Local Transaction Manager
DTM,Distributed Transaction Manager
2.1 分布式事务管理的抽象模型
2 分布式事务的执行与恢复本地事务管理器
LTM1
本地事务管理器
LTM2
本地事务管理器
LTMn
分布式事务管理器
DTM1
分布式事务管理器
DTM2
分布式事务管理器
DTMn
站点
n
站点
2
站点
1
事务管理
DTM功能
– 保证分布式事务 ACID特性，
特别是原子性，使每一站点的子事务都成功执行，或者都不执行。
通过向各站点发 begin-transaction,commit或者 abort,create原语来实现的
– 负责协调由该站点发出的所有分布式事务的执行
启动分布式事务的执行
将分布式事务分解为子事务，并将其分派到恰当的站点上执行
决定分布式事务的终止（子事务都提交或者都撤销）
– 支持分布式事务执行位置透明性
实现了对网络上各站点的各子事务的监督和管理
完成对整个分布式事务执行过程的调度和管理
保证分布式数据库系统的高效率
Log原语,
Local Begin-Trans,
Local-Commit,
Local-Abort
2.1 分布式事务管理的抽象模型
2 分布式事务的执行与恢复事务管理
LTM功能
– 保证本地事务的 ACID特性
– 维护一个用于恢复的日志，代替 DTM把分布事务的执行与恢复信息记入日志
– 参与适当的并发控制模式，以协调在该站点上执行的事务的并发执行。接收并遵从本 Site上 DTM发来的
Log原语，记入 Log并执行之
Log原语,
Local Begin-Trans,
Local-Commit,
Local-Abort
2.1 分布式事务管理的抽象模型
2 分布式事务的执行与恢复分布式事务执行的控制模型
是指协调分布式事务中各成员 DBMS执行其子事务的通用方法，有三种,
– 主从模型：主、从控制器,LTM之间无通信
– 三角模型,LTM之间可以传递数据，避免了主从之间不必要的传输
– 层次控制模型,LTM还可再创建 Agent，控制其它 LTM执行，比前两种复杂
2.2 分布式事务执行的控制模型
2 分布式事务的执行与恢复分布式事务管理器局部事务管理器局部事务管理器局部事务管理器数据库 数据库 数据库命令命令命令回答 回答回答主从控制模型分布式事务管理器局部事务管理器局部事务管理器数据库 数据库命令命令回答 回答临时数据三角控制模型分布式事务管理器局部事务管理器数据库命令 命令回答 回答局部事务管理器局部事务管理器局部事务管理器局部事务管理器局部事务管理器命令 命令 命令 命令回答 回答 回答 回答数据库 数据库 数据库数据库 数据库……
… …
层次控制模型
故障类型
– 事务故障
由非预期的、不正常的程序结束所造成的故障，即事务没有执行到 Commit或显示 Rollback语句的故障，如：
计算溢出、完整性破坏、操作员干预、输入输出错误、
死循环等）
处理方法：内存、磁盘上信息没有损失，使用 Log做
Rollback
– 系统故障
造成系统停止运行的任何事件，要求系统重启动，如
CPU出错、缓冲区满、系统崩溃等
处理方法：内存,I/O Buffer内容皆丢失,DB没有破坏，恢复时，搜索 Log,确定 Rollback的事务。
2.3 分布式数据库系统中的故障
2 分布式事务的执行与恢复
– 介质故障：
辅助存储器介质遭破坏
处理方法：如数据丢失,日志无损失，从某个 Dump
状态开始执行已提交事务；数据与日志都丢失 不可能完全恢复以上三种可以统称为站点故障,
2.3 分布式数据库系统中的故障
2 分布式事务的执行与恢复通讯故障
报文故障
– 报文错
– 报文失序
– 报文丢失
– 报文延迟
网络分割故障（网络断连）
通讯发生,既有某个报文 Message从 Site x 发往 Site y,正常情况,
(a) 在某时间段 Dmax 之后,x 站点收到 y发回的应答信息 (Ack)
(b) y收到的 Message是一个合适的次序
(c ) Message本身的信息是正确的但是当某个 Dmax之后,x还没收到 y的 Ack,则可能发生,
(a) Message 或 Ack 信息丢失
(b) 网络分割,即网络不通
2.3 分布式数据库系统中的故障
2 分布式事务的执行与恢复问题可以进一步分为,
a) 是否是所在 Site故障,还是系统响应过慢，还是网络流量过大
b) 若是故障,是通讯故障,还是 y 站点故障?
c) 如果是报文故障，是报文丢失还是应答丢失对上述故障,其恢复程序可以有不同级别,
一级,仅处理 Site故障二级,Site故障及 Message故障三级,Site故障及 Message故障,还包括网络分割
2.3 分布式数据库系统中的故障
2 分布式事务的执行与恢复
事务恢复
– 当发生故障时，保证事务原子性的措施称为事务故障恢复，简称事务恢复
– 主要依靠日志来实现
事务状态转移跟踪（操作）
– Begin_transaction：标记事务开始执行
– Read & write：表示事务对某个数据项进行读写
– End_transaction：表示读写操作已完成，标记事务执行结束
– Commit_transaction：表示事务已经成功结束，任何改变已不可更改
– Rollback (abort)：表示事务没有成功结束，撤销事务对数据库所作的任何改变
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
ACTVE PARTIALLYCOMMITTED COMMITED
FAILED TERMINATED
BEGIN
TRANSACTION
READ/
WRITE
END
TRANSACTION COMMIT
ABORTABORT
事务的提交点
– 当事务 T所有的站点数据库存取操作都已成功执行；
– 所有操作对数据库的影响都已记录在日志中。 到达提交点
– 提交点后事务就成为已提交的事务，并假定其结果以永久记录在数据库中
– 事务在日志中写入提交记录 [commit,T]
– 在系统发生故障时，需要扫描日志，检查日志中写入
[start_transaction,T],但没有写入 [commit,T]的所有事务 T
– 恢复时必须回滚这些事务以取消他们对数据库的影响
– 此外，还必须对日志中记录的已提交子事务的所有写操作进行恢复。
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
事务的提交点相关操作
– 日志文件保存到磁盘上
– 一般先将文件的相关块，从磁盘拷贝到主存的缓冲区，然后更新，再写回磁盘
– 缓冲区中会经常存在一个或多个日志文件块，写满后一次性写回磁盘
– 系统崩溃时，主存中的信息会丢失，这些信息无法利用
– 因此，事务到达提交点之前，未写到磁盘的日志必须写入，
称为事务提交前强制写日志。
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
日志
– Log：记录所有对 DB的操作
– 事务标识：每个事务给定一个具有惟一性的标识符
– Log记录项,
[start_transaction,T],
[write_item,T,x,旧值,新值 ]
[read_item,T,x]
[commit,T]
[abort,T]
– 写动作：写 Log比写数据优先
– Log存储：一般存在盘上,还会定期备份到磁带上
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
Log举例
Log Write Output
<start,T0>
<write,T0,A,1000,950>
<write,T0,B,2000,2050>
A = 950
B = 2050
<commit,T0 >
<start,T1 >
<write,T1,C,700,600>
C = 600
BB,BA
<commit,T1 >
BC
注,BX 表示含有 X的存储块,
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复数据访问
x
Y A
B
x1
y1
缓冲区缓冲块 A
缓冲块 B
input(A)
output(B)
read(X)
write(Y)
磁盘
T1工作区 T2 工作区主存
x2
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
档案库
– 一天要产生大量的 Log
– Log划分为两部分
一部分是当前活动的联机部分，存储在磁盘上
另一部分是档案存储部分，存储在磁带上
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复日志缓冲区
……
数据库缓冲区
(易变数据库 )
局部恢复管理器数据库缓冲区管理器主存取出读 /写读 /写日志档案库
DB
档案库稳定日志稳定
DB
读 /写读 /写
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复数据库、日志和档案库的存储模式
检查点（ Checkpoint）
– 设置一个周期性（时间 /容量）操作点
a) Log Buffer内容写入 Log数据集
b) 写检查点 Log信息：当前活动事务表,每个事务最近一次 Log记录在 Log文件中的位置
c) DB Buffer内容写入 DB
d) 将本次检查点 Log项在 Log文件中的地址记入
“重启动文件”
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
事务本身也会发生故障，也是主要通过日志来实现恢复
恢复原则
– 孤立和逐步退出事务的原则
undo 事务已对 DB的修改 ( 不影响其他事务的可排除性局部故障，如事务操作的删除、超时、违反完整性原则、资源、限制和死锁等 )
– 成功结束事务原则
Redo 已成功事务的操作
– 夭折事务原则撤销全部事务,恢复到初态，两种做法：利用数据备份和 Undo
2.5 事务故障的恢复
2 分布式事务的执行与恢复
本地事务恢复 (与集中式恢复相同 )
– 从“重启动文件” 读出最近 Checkpoint的地址,并定出 Checkpoint在 Log文件中的位置
– 创建 Redo表（初态为空）,Undo表 (即 Checkpoint相应内容中的活动事务表 )
– 检查得出 Undo事务（向前检索，遇到 begin
transaction的 log记录，其对应的事务）与 Redo事务
（向前检索，遇到 commit的 log记录，其对应事务）
– 反向检索 Log,将 Undo表中事务,直到遇到对应的
Begin Trans
– 正向检索 Redo事务的 Log记录,并执行之,直到对应的 Commit记录
2.5 事务故障的恢复
2 分布式事务的执行与恢复重启动文件 UNDO REDO
活动事务表故障发生地址
c0 c1
(1)
(3)
(5) (2)
(4)
日志数据集利用日志进行事务恢复的过程
2.5 事务故障的恢复
2 分布式事务的执行与恢复
Checkpoints 举例
T1 可以忽略 (因为有检查点，更新已经被写入磁盘 )
T2 和 T3 redo.
T4 undo
Tc Tf
T1
T2
T3
T4
checkpoint system failure
2.5 事务故障的恢复
2 分布式事务的执行与恢复分布式事务恢复参考模型
Root
Agent Agent Agent
DTM-
Agent
站点 1的
LTM
DTM-
Agent
DTM-
Agent
站点 2的
LTM
站点 n的
LTM
全局事务分布式事务管理器
(DTM)
局部事务管理器
(LTM)
2.5 事务故障的恢复
2 分布式事务的执行与恢复
分布式事务模型
– 底层：本地事务管理层,LTM之间不需要进行联系，
执行上层 DTM代理发来的原语，实现接口 1
Local begin,local commit,local abort,local create
– 中间层：分布式事务管理层，一组互相交换报文的本地 DTM组成，实现接口 2
Begin transaction,commit,abort,create
– 顶层：全局事务层，由总代理和其他代理组成，只有它与中间层联系
2.5 事务故障的恢复
2 分布式事务的执行与恢复
.
.
Begin Transaction
.
.
Create Agent1
Send to Agent1
.
Local-begin
.
Send Create Req
Write
Begin -transaction
in Local
Log
Root Agent
DTM-Agent
LTM
Receive...
Local Create
Local-begin
………….
Write
Begin -transaction
in Local
Log
LTM
DTM-Agent
Agent1
13
2
4
5
6
7
8
分布式事务执行和恢复举例
基本思想
– 将本地原子性提交行为的效果扩展到分布式事务,保证了分布式事务提交的原子性,并在不损坏 Log的情况下,
实现快速故障恢复,提高 DDB系统的可靠性,
– 第一阶段：表决阶段
– 第二阶段：执行阶段
两类代理
– 协调者 (Coordinator)：提交和撤销事务的决定权，一般是总代理
– 参与者 (Participants)：负责在本地数据库中执行写操作，
并且向协调者提出提交和撤销子事务的意向
3.1 基本思想和内容
3 两阶段提交协议
3.1 基本思想和内容
3 两阶段提交协议协调者参与者日志 日志 日志日志命令应答
...,..参与者 参与者
2PC中协调者和参与者的关系
表决阶段
– 目的是形成一个共同的决定
– 首先，协调者给所有参与者发送“准备”消息，进入等待状态
– 其次，参与者收到“准备”消息后，检查是否能够提交本地事务
如能，给协调者发送“建议提交”消息,进入就绪状态
如不能，给协调者发送“建议撤销”消息，可以单方面撤销
– 第三，协调者收到所有参与者的消息后，他就做出是否提交事务的决定，
只要有一个参与者投了反对票，就决定撤销整个事务，发送“全局撤销”消息给所有参与者，进入撤销状态
否则，就决定提交整个事务，发送“全局提交”消息给所有参与者，
进入提交状态
执行阶段
– 实现表决阶段的决定，提交或者撤销
3.1 基本思想和内容
3 两阶段提交协议初始写 begin_commit到日志等待有要求撤消的？
写 commit到日志提交写 end_of_transt到日志初始准备提交？
写 ready到日志就绪消息类型？
写 abort到日志 写 commit到日志提交撤消撤消写 abort到日志写 abort到日志协调者 参与者
no
no
abort commit
准备撤消提交全局撤消全局提交
ACK
ACK
两阶段提交协议的活动
2PC协议的重要特点
– 允许参与者单方面撤销事务
– 一旦参与者确定了提交或撤销协议，它就不能再更改它的提议
– 当参与者处于就绪状态时，根据协调者发出的消息种类，它可以转换为提交状态或者撤销状态
– 协调者根据全局提交规则做出全局终止决定
– 协调者和参与者可能进入互相等待对方消息的状态，
使用定时器，保证退出消息等待状态
3.1 基本思想和内容
3 两阶段提交协议
集中式
– 通讯只发生在协调者和参与者之间，参与者之间不交换信息
分层式
– 协调者是在树根的 DTM代理者，协调者与参与者之间的通讯不用直接广播的方法进行，而是使报文在树中上下传播。
每个 DTM代理是通信树的一个内部节点，它从下层节点处收集报文或向它们广播报文。
线性
– 参与者之间可以互相通信。系统中的站点间要排序，消息串行传递。支持没有广播功能的网络
分布式
– 允许所有参与者在第一阶段相互通信，从而可以独立做出事务终止决定。
3.2 通信结构
3 两阶段提交协议
2
3
4
5
1
2
3
4
5
11
协调者 参与者 协调者 协调者参与者第一阶段 第二阶段准备 建议撤消 /提交 全局撤消 /提交 提交 /撤消集中式
3
4
2
5
1
5
11
协调者 参 与 者 协调者 协调者参 与 者第一阶段 第二阶段准备 建议撤消 /提交 全局撤消 /提交 提交 /撤消
2
3
4
2 2
分层式
1 2 3 4 n
第一阶段第二阶段准备 建议提交 /撤消 建议提交 /撤消 建议提交 /撤消全局提交 /撤消 全局提交 /撤消 全局提交 /撤消 全局提交 /撤消线性式
1
n
4
3
2
4
3
2
1
n
… …
协调者 协调者 协调者 +参与者第一阶段准备 建议撤消 /提交全局撤消 /提交可独立做决定分布式
1,站点故障
a> 参与者在将,Ready”记录入 Log之前故障
此时协调者 (C)达到超时,Abort发生。站点（ P）恢复时，重启动程序将执行 Abort，不必从其他站点获取信息。
b> 当将,Ready”写入 Log后，站点故障
此时所有运行的站点都将正常结束事务（ Commit/Abort)。 P恢复时，
因为 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后故障
无任何动作发生
3.2 两阶段提交协议 和故障恢复
3 两阶段提交协议
2,报文丢失
a> 从 P发出的,Ready”/“Abort”报文丢失
C达到超时，整个事务执行,G-abort”。该故障仅能被 C识别，
此时 C认为 P故障，但 P并无故障，不需执行重启动程序。
b>,Prepare”报文丢失
P等待,C得不到回答，结果同 2.a>
c>,G-commit”/”G-abort”报文丢失
P处于不确定状态。回答,Abort”的可以确定其工作，回答
,Ready”的不行。此时可以修改加入计时器，超时则申请重发命令。
d>,Ack”报文丢失
C超时，可重发,G-commit”/”G-abort”命令,P无论是否有活动，
都重发,Ack”报文
3.2 两阶段提交协议 和故障恢复
3 两阶段提交协议
3,网络分割站点假设分成两组：协调者组和参与者组。
一组是协调者，一组是参与者。于是从协调者看是参与者组故障，结果同 1.a>,1.b>。 从参与者组看是协调者站点故障，动作如 1.c>,1.d>。
3.2 两阶段提交协议 和故障恢复
3 两阶段提交协议初始写 begin_commit到日志等待有要求撤消的？
写 commit到日志提交写 Complete到日志初始准备提交？
写 ready到日志就绪消息类型？
写 abort到日志 写 commit到日志提交撤消撤消写 abort到日志写 abort到日志协调者 参与者
no
no
abort commit
2,b> 准备
2.a>撤消
2.a> 提交
2.c>全局撤消全局提交
ACK
ACK
1.c>
1.d>
1.e>
1.a>
1.b>
2.d>
多站点数据更新
– 方法,站点 A上有事务 T对 X更新,X在
B1,…Bn 和 C1,…Cm 上有副本,则也要对这些副本更新
– 问题
多个站点同时更新不现实 (每一个站点某一时刻与站点 A连通的概率小于 1）
对未连通站点上的副本更新增多时出错,更新的顺序也不一定是连通顺序
4.1 多站点数据更新
4 分布式数据库中的数据更新
4.1 多站点数据更新
4 分布式数据库中的数据更新站点 A
要更新 X
站点 B1
站点 B2
站点 Bn
站点 C1
站点 C2
站点 Cm
说明：
(1) X在 B1,B2,…,Bn
和 C1,C2,…,Cm 上都有副本；
(2)但只有站点
B1,B2,…,Bn
与站点 A连通而站点
C1,C2,…,Cm 与站点 A暂时未连通。
主文本更新
– 思想：指定主副本,修改只对主副本进行,修改辅助副本时,也按在主副本上执行的更新顺序执行
– 问题
修改传播必须在短时间内完成,否则将获得“过时”数据
主副本不可用,引得其他副本也不可用
4.2 主文本更新
4 分布式数据库中的数据更新
4.2 主文本更新
4 分布式数据库中的数据更新网络站点 A X主文本站点 B2X辅文本站点 B1X辅文本站点 B3X辅文本站点 B5 X辅文本站点 B4 X辅文本
T1
T2
未连通
T1在 T2之前
移动主文本法
– 若初次更新在辅文本上进行，然后再把更新引向该数据的主站点
– 如果主站点此时尚未连通，则另选一个辅站点中的辅文本为该数据新的主文本进行更新
– 待原主文本站点连通后，系统将自动把它改为辅文本，并按记录要求执行更新
– 如果初次更新在主文本上进行，但主文本站点与网络未接通，则此次更新操作失败，事务被撤销，因为无法传播更新
移动文本法的问 题
网络分割成很多部分时，更新处理会不一致
网络分割成 W1,W2,W1中 X更新为 R,W2中 X更新为 S,网络连通时，使用 R还是 S来恢复 X呢？
4.2 主文本更新
4 分布式数据库中的数据更新
快照 (Snapshot)
– 与视图相似,是导出的关系
– 快照的数据是实际存放在数据库中的，视图不是
– 周期地更新
– 用于某些需要“冻结”数据的应用
4.3 快照方法
4 分布式数据库中的数据更新
例子
Define Snapshot HP-Book as
SELECT * FROM Book WHERE Price>$100
REFRESH Every day
特点
– 快照不考虑数据的辅助副本,只关心主文本和这个主本上定义的多个快照
– 快照与视图一样可以定义为一个或多个主副本的部分或全部
– 快照可以完成复杂的查询,但又不阻止更新
– 查询操作可使用快照，也可使用主文本，对更新操作还是在主文本上进行
4.3 快照方法
4 分布式数据库中的数据更新
业务规则约束
– 有效性约束,域约束，数据项的取值范围
– 数据依赖约束,实体完整性和引用完整性
例子
– 取现金时
一个账户的存款余额必须大于零
– 转账时
一个账户的存款余额必须大于零,
事务结束时,两账户中存款总和,必须与事务开始时两账户存款之和相同
– 定期利息计算
事务执行后,所有账户存款之和比事务开始前各账户存款总和大于 10%（假定利息是总额的 10%）
5.1 业务规则的一致性
5 分布式事务增强数据库一致性
业务规则要强制执行
– 用户编写的事务中
– 由 DBMS事务优化器产生的事务中
在产生的分布式执行方案中，要编入业务规则的强制条件
或者从数据字典中获取相关的业务规则，并在生产分布式事务的时候使用它
多数商用分布式 DBMS的事务优化器，只加入少数几类业务规则，为了补救这种不足，需要
– 程序员必须编写加进业务规则的分布式事务
– 必须定期对数据库进行扫描，监测不一致的数据，并予以清除
– 找出那些没有实施的，不能由事务优化器加上的强行业务规则
5.1 业务规则的一致性
5 分布式事务增强数据库一致性
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性
分布式数据库冗余设计的理由
– 提高系统的可用性和可靠性
如果用户由于某种原因无法访问某个成员数据库，
它可以访问另外一个成员数据库上的相同片断
– 提高“读”事务的本地性
降低通信成本
例如，一个片断存放在该事务的原发站点中，那么就免除了传输请求和返回结果的花费
但是，如果事务包含对片断的更新，则其所有副本也必须做同样的更新，这时反而增加而不是降低通信成本
例子
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)
数据库管理员要使得包含冗余的站点以相同的顺序执行事务，来保证数据的一致性
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性
异步复制器
– 冗余数据绝对保持一致是不可能的,一般允许对冗余数据的修改有暂时的不一致,
– 复制数据库的应用
向分站点发送只读数据
在一个周期结束时从分站点对中心站点复制这个周期内改变过的数据
复制数据并建立决策支持系统
建立关键数据的备份副本
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性
不同复制器的差别
– 何时在主副本上获取数据
数据驱动,当事务修改主副本时,获取有关数据修改信息,
并将其写到一个获取文件或队列中。
计时器驱动,由系统在用户定义的时间间隔自动获取相关数据修改信息。 Oracle Simple Snapshot属于这一类方法。
应用程序驱动,由应用中的事件引发系统从主副本把数据复制到获取文件或队列中。 Prism Warehouse Manager采用这种方法。
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性
不同复制器的差别
– 何时把主副本上的数据用到辅助副本上
数据驱动,在主副本上由更新 Trans所做的更新,立即复制,
传输和应用于辅助副本。 HP的 Allbase/Replicate,Open
Ingres Replicator和 Sybase Replication Server采用这种方法
计时驱动,更新事务在主副本上的更新,在用户定义的区间应用于辅助副本,IBM的 Data Propagator/Replicational,
Oracle Simple Snapshot属于这一类方法
应用程序驱动,由应用中的事件引发系统获取文件或队列对辅助副本进行修改。 Prism Warehouse Manager采用这种方法
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性总 结
分布式事务概述（定义、特性和结构等）
分布式事务的执行与恢复
事务管理抽象模型
事务恢复
2PC协议
分布式数据库中的数据更新
分布式事务增强数据库一致性
（ mycui369@126.com)
计算机应用技术 2007级研究生
1,分布式事务概述
2.分布式事务的执行和恢复
3.两阶段提交协议
4.分布式数据库中的数据更新
5.分布式事务增强数据库一致性
6.总结分布式数据库中的事务管理和恢复第 4章事务概念
事务是访问或更新各种数据项的最小逻辑工作单位。
它是一个操作序列
它可以使数据库从一个一致状态到另外一个一致状态
事务必须保证数据库的一致性
事务执行期间数据库可能不一致
1.1 分布式事务定义和特性
1 分布式事务概述
当事务提交（ commit）时数据库必须是一致的事务 T开始 事务 T结束事务 T的执行数据库一致数据库一致数据库可能临时不一致
1.1 分布式事务定义和特性
1 分布式事务概述事务概念分布式事务
集中式
– 事务和操作数据在一个站点上
– 不存在传输费用
分布式
– 操作数据分布在不同的站点上
– 事务也在多个站点上执行
– 分布式事务是集中式事务的扩充
– 站点和通信连路故障都可能导致错误发生
– 分布式事务的恢复要比集中式事务复杂的多
1.1 分布式事务定义和特性
1 分布式事务概述
事务分类,
– 全局事务
通常由一个主事务和在不同站点上执行的子事务组成
主事务：负责事务的开始、提交和异常终止
子事务：完成对相应站点上的数据库的访问操作
– 局部事务
仅访问或更新一个站点上的数据的事务
1.1 分布式事务定义和特性
1 分布式事务概述分布式数据库中的事务
ACID特性
– 原子性（ Atomicity）
事务的操作要么全部执行,要么全部不执行,保证数据库一致性状态
– 一致性（ Consistency）
事务的正确性，串行性，并发执行的多个事务,其操作的结果应与以某种顺序串行执行这几个事务所得的结果相同,
– 持久性（ Durability）
当事务提交后,其操作的结果将永久化,而与提交后发生的故障无关
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性
– 隔离性（ Isolation）
虽然可以有多个事务同时执行，但是单个事务的执行不应该感知其他事务的存在，因此事务执行的中间结果应该对其他并发事务隐藏
– 此外，分布式数据库系统中还要考虑 数据传送、
通信原语和控制报文 等。
全局事务的主事务和子事务全部成功提交，
才能改变数据库状态，有一个失败，其他子事务操作都要撤销。
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性
从账号 A向账号 B转账 $50:
1,read(A)
2,A,= A – 50
3,write(A)
4,read(B)
5,B,= B + 50
6,write(B)
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性举例
一致性要求,事务执行后 A 和 B账号的总金额不变
原子性要求,如果事物在第 3步和第 6步之间故障,系统应该保证事务对数据库的修改没有产生,否则将导致不一致性
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性举例
持久性要求,一旦用户通知说事务已经完成（即 $50 转账成功），那么由该事务对数据库的修改就必须保证是永久的，即使是发生故障也如此
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性举例
独立性要求 如果在第 3步和第 6步之间,允许其他事务访问被修改的数据库的中间结果,那么它将见到一个不一致的数据库
(也就是说,A + B 的和少于它的正确值）
当然事务的串行执行将不会出现这种情况，
但是数据库中事务并行执行的优点就损失了
1.1 分布式事务定义和特性
1 分布式事务概述分布式事务特性举例
Begin Transaction原语：开始一个事务
T1[]
T2[]
,子事务或操作序列
:
Tn[]
Commit原语：事务成功完成的结束
Rollback或 Abort原语：事务失败的结束
1.2 分布式事务结构和事务状态
1 分布式事务概述分布式事务的一般结构
活动 从事务开始执行的初始状态始,事务执行中保持该状态
部分提交 事务的最后一个语句执行后进入该状态,
失败 一旦发现事务不能正常执行时进入该状态
夭折 当事务被回滚后，数据库恢复到事务开始执行前的状态。 事务夭折后有两种选择
– 重启动 仅当没有内部逻辑错误时
– 杀死
提交 当事务成功执行后,
1.2 分布式事务结构和事务状态
1 分布式事务概述分布式事务的状态
1.2 分布式事务结构和事务状态
1 分布式事务概述分布式事务的状态
进程：系统中可以并行执行的一段操作序列，分布式事务中的子事务序列是进程方式完成的
– 进程说明：定义进程的行为模式，数据和数据上的操作，功能等
– 进行执行：按模式来启动这个进程，执行其中的操作
过程：不可并行执行的操作序列
事务代理（ Agent）：应用在各个 Site上执行的若干进程，
称作应用在该 Site上的代理。代理可以执行应用程序员写的程序，也可以执行系统的原语函数，不同代理间通过报文实现通讯
根代理（ Root Agent） 应用启动 Site上的代理。根代理所在的 Site称作原发 Site,一般，根代理负责发系统原语，只有根代理可以请求创建新代理。
1.2 分布式事务结构和事务状态
1 分布式事务概述进程相关定义
为了协调执行分布式应用的全局操作，分驻于不同站点的诸事务代理必须进行协调，有如下规定：
– 每一应用都有一个负责启动整个事务的总代理（或称根代理）
– 只有总代理才能发出全局有效的事务开始、提交和撤消原语
– 只有总代理才能请求建立新的事务代理
– 各站点上的子事务都执行成功，总代理才能决定提交该事务，否则总代理将决定撤销该事务
1.2 分布式事务结构和事务状态
1 分布式事务概述进程协作转账应用事务在两个账户之间执行“基金汇兑”操作。
如果汇兑的金额小于转出帐号现有金额，就撤销如果大于等于就提交全局关系
Account (Account-number,Amount)
假设账户分布在网络的不同站点上。
1.2 分布式事务结构和事务状态
1 分布式事务概述全局级转帐事务
FUND_TRANSFER:
read (terminal,$AMOUNT,$FROM_ACC,$TO_ACC);
begin_transaction;
select AMOUNT into $FROM_AMOUNT from ACCOUNT
where ACCOUNT_NUMBER=$FROM_ACC;
if $FROM_AMOUNT-$AMOUNT<0 then abort
else begin
update ACCOUNT
set AMOUNT = AMOUNT-$AMOUNT
where ACCOUNT_NUMBER = $FROM_ACC;
update ACCOUNT
set AMOUNT = AMOUNT-$AMOUNT
where ACCOUNT_NUMBER = $TO_ACC;
commit
end
输入：汇出金额和转入 /转出帐号事务开始：检查转出帐号中是否有足够的转出资金？
更新转出帐号存款余额创建 AGENT1
向代理 1送消息：转入帐号，金额等待来自 AGENT1的消息成功？
提交事务：成功结束 撤消事务：失败结束
ROOT_AGENT AGENT
接收来自根代理的信息更新转入帐号存款余额发送执行消息给根代理
(成功或失败 )
是 否否转账应用处理流程
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-$AMOUNT<0 then abort
else begin
update ACCOUNT
set AMOUNT = AMOUNT-$AMOUNT
where ACCOUNT_NUMBER = $FROM_ACC;
create AGENT;
send to AGENT($AMOUNT,$TO_ACC);
commit/*这里省略了等待消息和判别 */
end
AGENT;
receive from ROOT_AGENT($AMOUNT,$TO_ACC);
update ACCOUNT set AMOUNT=AMOUNT+$AMOUNT where
ACCOUNT=$TO_ACC;
send to ROOT_AGENT(?SUCCESS?/?FALL?)
转账事务的两个代理分布式事务管理问题
处理数据项的多个副本
– 分布式事务处理负责保持同一数据的多个副本之间的一致性。当某个副本所在站点发生故障时，负责生成与该数据其他副本一致的拷贝，以便于及时恢复。
单个站点的故障
– 一个站点或多个站点故障时,DDBMS继续与其他正常运行的站点一起继续工作
– 当故障站点恢复时,DDBMS协同故障站点的 DBMS，必须使得该站点与系统连接时，局部数据库与其他站点同步
通信网络的故障
– 必须能够处理两个或者多个站点间的通信网络故障
分布式提交
– 如果提交分布式事务过程中有一个站点发生故障，提交就会产生问题
– 两阶段提交协议用于解决这一问题
1.3 分布式事务管理的问题和目标
1 分布式事务概述分布式事务管理目标
目的：事务能有效、可靠、并发的执行
除了策略之外，效率的几个重要方面
– CPU和主存的使用
– 控制报文
– 响应时间
– 可用性
目标
– 维护事务的 ACID性质
– 获得最小的主存和 CPU开销，降低报文数目，加快响应时间
– 获得最大限度的可靠性和可用性
1.3 分布式事务管理的问题和目标
1 分布式事务概述抽象模型
LTM,Local Transaction Manager
DTM,Distributed Transaction Manager
2.1 分布式事务管理的抽象模型
2 分布式事务的执行与恢复本地事务管理器
LTM1
本地事务管理器
LTM2
本地事务管理器
LTMn
分布式事务管理器
DTM1
分布式事务管理器
DTM2
分布式事务管理器
DTMn
站点
n
站点
2
站点
1
事务管理
DTM功能
– 保证分布式事务 ACID特性，
特别是原子性，使每一站点的子事务都成功执行，或者都不执行。
通过向各站点发 begin-transaction,commit或者 abort,create原语来实现的
– 负责协调由该站点发出的所有分布式事务的执行
启动分布式事务的执行
将分布式事务分解为子事务，并将其分派到恰当的站点上执行
决定分布式事务的终止（子事务都提交或者都撤销）
– 支持分布式事务执行位置透明性
实现了对网络上各站点的各子事务的监督和管理
完成对整个分布式事务执行过程的调度和管理
保证分布式数据库系统的高效率
Log原语,
Local Begin-Trans,
Local-Commit,
Local-Abort
2.1 分布式事务管理的抽象模型
2 分布式事务的执行与恢复事务管理
LTM功能
– 保证本地事务的 ACID特性
– 维护一个用于恢复的日志，代替 DTM把分布事务的执行与恢复信息记入日志
– 参与适当的并发控制模式，以协调在该站点上执行的事务的并发执行。接收并遵从本 Site上 DTM发来的
Log原语，记入 Log并执行之
Log原语,
Local Begin-Trans,
Local-Commit,
Local-Abort
2.1 分布式事务管理的抽象模型
2 分布式事务的执行与恢复分布式事务执行的控制模型
是指协调分布式事务中各成员 DBMS执行其子事务的通用方法，有三种,
– 主从模型：主、从控制器,LTM之间无通信
– 三角模型,LTM之间可以传递数据，避免了主从之间不必要的传输
– 层次控制模型,LTM还可再创建 Agent，控制其它 LTM执行，比前两种复杂
2.2 分布式事务执行的控制模型
2 分布式事务的执行与恢复分布式事务管理器局部事务管理器局部事务管理器局部事务管理器数据库 数据库 数据库命令命令命令回答 回答回答主从控制模型分布式事务管理器局部事务管理器局部事务管理器数据库 数据库命令命令回答 回答临时数据三角控制模型分布式事务管理器局部事务管理器数据库命令 命令回答 回答局部事务管理器局部事务管理器局部事务管理器局部事务管理器局部事务管理器命令 命令 命令 命令回答 回答 回答 回答数据库 数据库 数据库数据库 数据库……
… …
层次控制模型
故障类型
– 事务故障
由非预期的、不正常的程序结束所造成的故障，即事务没有执行到 Commit或显示 Rollback语句的故障，如：
计算溢出、完整性破坏、操作员干预、输入输出错误、
死循环等）
处理方法：内存、磁盘上信息没有损失，使用 Log做
Rollback
– 系统故障
造成系统停止运行的任何事件，要求系统重启动，如
CPU出错、缓冲区满、系统崩溃等
处理方法：内存,I/O Buffer内容皆丢失,DB没有破坏，恢复时，搜索 Log,确定 Rollback的事务。
2.3 分布式数据库系统中的故障
2 分布式事务的执行与恢复
– 介质故障：
辅助存储器介质遭破坏
处理方法：如数据丢失,日志无损失，从某个 Dump
状态开始执行已提交事务；数据与日志都丢失 不可能完全恢复以上三种可以统称为站点故障,
2.3 分布式数据库系统中的故障
2 分布式事务的执行与恢复通讯故障
报文故障
– 报文错
– 报文失序
– 报文丢失
– 报文延迟
网络分割故障（网络断连）
通讯发生,既有某个报文 Message从 Site x 发往 Site y,正常情况,
(a) 在某时间段 Dmax 之后,x 站点收到 y发回的应答信息 (Ack)
(b) y收到的 Message是一个合适的次序
(c ) Message本身的信息是正确的但是当某个 Dmax之后,x还没收到 y的 Ack,则可能发生,
(a) Message 或 Ack 信息丢失
(b) 网络分割,即网络不通
2.3 分布式数据库系统中的故障
2 分布式事务的执行与恢复问题可以进一步分为,
a) 是否是所在 Site故障,还是系统响应过慢，还是网络流量过大
b) 若是故障,是通讯故障,还是 y 站点故障?
c) 如果是报文故障，是报文丢失还是应答丢失对上述故障,其恢复程序可以有不同级别,
一级,仅处理 Site故障二级,Site故障及 Message故障三级,Site故障及 Message故障,还包括网络分割
2.3 分布式数据库系统中的故障
2 分布式事务的执行与恢复
事务恢复
– 当发生故障时，保证事务原子性的措施称为事务故障恢复，简称事务恢复
– 主要依靠日志来实现
事务状态转移跟踪（操作）
– Begin_transaction：标记事务开始执行
– Read & write：表示事务对某个数据项进行读写
– End_transaction：表示读写操作已完成，标记事务执行结束
– Commit_transaction：表示事务已经成功结束，任何改变已不可更改
– Rollback (abort)：表示事务没有成功结束，撤销事务对数据库所作的任何改变
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
ACTVE PARTIALLYCOMMITTED COMMITED
FAILED TERMINATED
BEGIN
TRANSACTION
READ/
WRITE
END
TRANSACTION COMMIT
ABORTABORT
事务的提交点
– 当事务 T所有的站点数据库存取操作都已成功执行；
– 所有操作对数据库的影响都已记录在日志中。 到达提交点
– 提交点后事务就成为已提交的事务，并假定其结果以永久记录在数据库中
– 事务在日志中写入提交记录 [commit,T]
– 在系统发生故障时，需要扫描日志，检查日志中写入
[start_transaction,T],但没有写入 [commit,T]的所有事务 T
– 恢复时必须回滚这些事务以取消他们对数据库的影响
– 此外，还必须对日志中记录的已提交子事务的所有写操作进行恢复。
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
事务的提交点相关操作
– 日志文件保存到磁盘上
– 一般先将文件的相关块，从磁盘拷贝到主存的缓冲区，然后更新，再写回磁盘
– 缓冲区中会经常存在一个或多个日志文件块，写满后一次性写回磁盘
– 系统崩溃时，主存中的信息会丢失，这些信息无法利用
– 因此，事务到达提交点之前，未写到磁盘的日志必须写入，
称为事务提交前强制写日志。
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
日志
– Log：记录所有对 DB的操作
– 事务标识：每个事务给定一个具有惟一性的标识符
– Log记录项,
[start_transaction,T],
[write_item,T,x,旧值,新值 ]
[read_item,T,x]
[commit,T]
[abort,T]
– 写动作：写 Log比写数据优先
– Log存储：一般存在盘上,还会定期备份到磁带上
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
Log举例
Log Write Output
<start,T0>
<write,T0,A,1000,950>
<write,T0,B,2000,2050>
A = 950
B = 2050
<commit,T0 >
<start,T1 >
<write,T1,C,700,600>
C = 600
BB,BA
<commit,T1 >
BC
注,BX 表示含有 X的存储块,
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复数据访问
x
Y A
B
x1
y1
缓冲区缓冲块 A
缓冲块 B
input(A)
output(B)
read(X)
write(Y)
磁盘
T1工作区 T2 工作区主存
x2
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
档案库
– 一天要产生大量的 Log
– Log划分为两部分
一部分是当前活动的联机部分，存储在磁盘上
另一部分是档案存储部分，存储在磁带上
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复日志缓冲区
……
数据库缓冲区
(易变数据库 )
局部恢复管理器数据库缓冲区管理器主存取出读 /写读 /写日志档案库
DB
档案库稳定日志稳定
DB
读 /写读 /写
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复数据库、日志和档案库的存储模式
检查点（ Checkpoint）
– 设置一个周期性（时间 /容量）操作点
a) Log Buffer内容写入 Log数据集
b) 写检查点 Log信息：当前活动事务表,每个事务最近一次 Log记录在 Log文件中的位置
c) DB Buffer内容写入 DB
d) 将本次检查点 Log项在 Log文件中的地址记入
“重启动文件”
2.4 事务故障恢复的基本概念
2 分布式事务的执行与恢复
事务本身也会发生故障，也是主要通过日志来实现恢复
恢复原则
– 孤立和逐步退出事务的原则
undo 事务已对 DB的修改 ( 不影响其他事务的可排除性局部故障，如事务操作的删除、超时、违反完整性原则、资源、限制和死锁等 )
– 成功结束事务原则
Redo 已成功事务的操作
– 夭折事务原则撤销全部事务,恢复到初态，两种做法：利用数据备份和 Undo
2.5 事务故障的恢复
2 分布式事务的执行与恢复
本地事务恢复 (与集中式恢复相同 )
– 从“重启动文件” 读出最近 Checkpoint的地址,并定出 Checkpoint在 Log文件中的位置
– 创建 Redo表（初态为空）,Undo表 (即 Checkpoint相应内容中的活动事务表 )
– 检查得出 Undo事务（向前检索，遇到 begin
transaction的 log记录，其对应的事务）与 Redo事务
（向前检索，遇到 commit的 log记录，其对应事务）
– 反向检索 Log,将 Undo表中事务,直到遇到对应的
Begin Trans
– 正向检索 Redo事务的 Log记录,并执行之,直到对应的 Commit记录
2.5 事务故障的恢复
2 分布式事务的执行与恢复重启动文件 UNDO REDO
活动事务表故障发生地址
c0 c1
(1)
(3)
(5) (2)
(4)
日志数据集利用日志进行事务恢复的过程
2.5 事务故障的恢复
2 分布式事务的执行与恢复
Checkpoints 举例
T1 可以忽略 (因为有检查点，更新已经被写入磁盘 )
T2 和 T3 redo.
T4 undo
Tc Tf
T1
T2
T3
T4
checkpoint system failure
2.5 事务故障的恢复
2 分布式事务的执行与恢复分布式事务恢复参考模型
Root
Agent Agent Agent
DTM-
Agent
站点 1的
LTM
DTM-
Agent
DTM-
Agent
站点 2的
LTM
站点 n的
LTM
全局事务分布式事务管理器
(DTM)
局部事务管理器
(LTM)
2.5 事务故障的恢复
2 分布式事务的执行与恢复
分布式事务模型
– 底层：本地事务管理层,LTM之间不需要进行联系，
执行上层 DTM代理发来的原语，实现接口 1
Local begin,local commit,local abort,local create
– 中间层：分布式事务管理层，一组互相交换报文的本地 DTM组成，实现接口 2
Begin transaction,commit,abort,create
– 顶层：全局事务层，由总代理和其他代理组成，只有它与中间层联系
2.5 事务故障的恢复
2 分布式事务的执行与恢复
.
.
Begin Transaction
.
.
Create Agent1
Send to Agent1
.
Local-begin
.
Send Create Req
Write
Begin -transaction
in Local
Log
Root Agent
DTM-Agent
LTM
Receive...
Local Create
Local-begin
………….
Write
Begin -transaction
in Local
Log
LTM
DTM-Agent
Agent1
13
2
4
5
6
7
8
分布式事务执行和恢复举例
基本思想
– 将本地原子性提交行为的效果扩展到分布式事务,保证了分布式事务提交的原子性,并在不损坏 Log的情况下,
实现快速故障恢复,提高 DDB系统的可靠性,
– 第一阶段：表决阶段
– 第二阶段：执行阶段
两类代理
– 协调者 (Coordinator)：提交和撤销事务的决定权，一般是总代理
– 参与者 (Participants)：负责在本地数据库中执行写操作，
并且向协调者提出提交和撤销子事务的意向
3.1 基本思想和内容
3 两阶段提交协议
3.1 基本思想和内容
3 两阶段提交协议协调者参与者日志 日志 日志日志命令应答
...,..参与者 参与者
2PC中协调者和参与者的关系
表决阶段
– 目的是形成一个共同的决定
– 首先，协调者给所有参与者发送“准备”消息，进入等待状态
– 其次，参与者收到“准备”消息后，检查是否能够提交本地事务
如能，给协调者发送“建议提交”消息,进入就绪状态
如不能，给协调者发送“建议撤销”消息，可以单方面撤销
– 第三，协调者收到所有参与者的消息后，他就做出是否提交事务的决定，
只要有一个参与者投了反对票，就决定撤销整个事务，发送“全局撤销”消息给所有参与者，进入撤销状态
否则，就决定提交整个事务，发送“全局提交”消息给所有参与者，
进入提交状态
执行阶段
– 实现表决阶段的决定，提交或者撤销
3.1 基本思想和内容
3 两阶段提交协议初始写 begin_commit到日志等待有要求撤消的？
写 commit到日志提交写 end_of_transt到日志初始准备提交？
写 ready到日志就绪消息类型？
写 abort到日志 写 commit到日志提交撤消撤消写 abort到日志写 abort到日志协调者 参与者
no
no
abort commit
准备撤消提交全局撤消全局提交
ACK
ACK
两阶段提交协议的活动
2PC协议的重要特点
– 允许参与者单方面撤销事务
– 一旦参与者确定了提交或撤销协议，它就不能再更改它的提议
– 当参与者处于就绪状态时，根据协调者发出的消息种类，它可以转换为提交状态或者撤销状态
– 协调者根据全局提交规则做出全局终止决定
– 协调者和参与者可能进入互相等待对方消息的状态，
使用定时器，保证退出消息等待状态
3.1 基本思想和内容
3 两阶段提交协议
集中式
– 通讯只发生在协调者和参与者之间，参与者之间不交换信息
分层式
– 协调者是在树根的 DTM代理者，协调者与参与者之间的通讯不用直接广播的方法进行，而是使报文在树中上下传播。
每个 DTM代理是通信树的一个内部节点，它从下层节点处收集报文或向它们广播报文。
线性
– 参与者之间可以互相通信。系统中的站点间要排序，消息串行传递。支持没有广播功能的网络
分布式
– 允许所有参与者在第一阶段相互通信，从而可以独立做出事务终止决定。
3.2 通信结构
3 两阶段提交协议
2
3
4
5
1
2
3
4
5
11
协调者 参与者 协调者 协调者参与者第一阶段 第二阶段准备 建议撤消 /提交 全局撤消 /提交 提交 /撤消集中式
3
4
2
5
1
5
11
协调者 参 与 者 协调者 协调者参 与 者第一阶段 第二阶段准备 建议撤消 /提交 全局撤消 /提交 提交 /撤消
2
3
4
2 2
分层式
1 2 3 4 n
第一阶段第二阶段准备 建议提交 /撤消 建议提交 /撤消 建议提交 /撤消全局提交 /撤消 全局提交 /撤消 全局提交 /撤消 全局提交 /撤消线性式
1
n
4
3
2
4
3
2
1
n
… …
协调者 协调者 协调者 +参与者第一阶段准备 建议撤消 /提交全局撤消 /提交可独立做决定分布式
1,站点故障
a> 参与者在将,Ready”记录入 Log之前故障
此时协调者 (C)达到超时,Abort发生。站点（ P）恢复时，重启动程序将执行 Abort，不必从其他站点获取信息。
b> 当将,Ready”写入 Log后，站点故障
此时所有运行的站点都将正常结束事务（ Commit/Abort)。 P恢复时，
因为 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后故障
无任何动作发生
3.2 两阶段提交协议 和故障恢复
3 两阶段提交协议
2,报文丢失
a> 从 P发出的,Ready”/“Abort”报文丢失
C达到超时，整个事务执行,G-abort”。该故障仅能被 C识别，
此时 C认为 P故障，但 P并无故障，不需执行重启动程序。
b>,Prepare”报文丢失
P等待,C得不到回答，结果同 2.a>
c>,G-commit”/”G-abort”报文丢失
P处于不确定状态。回答,Abort”的可以确定其工作，回答
,Ready”的不行。此时可以修改加入计时器，超时则申请重发命令。
d>,Ack”报文丢失
C超时，可重发,G-commit”/”G-abort”命令,P无论是否有活动，
都重发,Ack”报文
3.2 两阶段提交协议 和故障恢复
3 两阶段提交协议
3,网络分割站点假设分成两组：协调者组和参与者组。
一组是协调者，一组是参与者。于是从协调者看是参与者组故障，结果同 1.a>,1.b>。 从参与者组看是协调者站点故障，动作如 1.c>,1.d>。
3.2 两阶段提交协议 和故障恢复
3 两阶段提交协议初始写 begin_commit到日志等待有要求撤消的？
写 commit到日志提交写 Complete到日志初始准备提交？
写 ready到日志就绪消息类型？
写 abort到日志 写 commit到日志提交撤消撤消写 abort到日志写 abort到日志协调者 参与者
no
no
abort commit
2,b> 准备
2.a>撤消
2.a> 提交
2.c>全局撤消全局提交
ACK
ACK
1.c>
1.d>
1.e>
1.a>
1.b>
2.d>
多站点数据更新
– 方法,站点 A上有事务 T对 X更新,X在
B1,…Bn 和 C1,…Cm 上有副本,则也要对这些副本更新
– 问题
多个站点同时更新不现实 (每一个站点某一时刻与站点 A连通的概率小于 1）
对未连通站点上的副本更新增多时出错,更新的顺序也不一定是连通顺序
4.1 多站点数据更新
4 分布式数据库中的数据更新
4.1 多站点数据更新
4 分布式数据库中的数据更新站点 A
要更新 X
站点 B1
站点 B2
站点 Bn
站点 C1
站点 C2
站点 Cm
说明：
(1) X在 B1,B2,…,Bn
和 C1,C2,…,Cm 上都有副本；
(2)但只有站点
B1,B2,…,Bn
与站点 A连通而站点
C1,C2,…,Cm 与站点 A暂时未连通。
主文本更新
– 思想：指定主副本,修改只对主副本进行,修改辅助副本时,也按在主副本上执行的更新顺序执行
– 问题
修改传播必须在短时间内完成,否则将获得“过时”数据
主副本不可用,引得其他副本也不可用
4.2 主文本更新
4 分布式数据库中的数据更新
4.2 主文本更新
4 分布式数据库中的数据更新网络站点 A X主文本站点 B2X辅文本站点 B1X辅文本站点 B3X辅文本站点 B5 X辅文本站点 B4 X辅文本
T1
T2
未连通
T1在 T2之前
移动主文本法
– 若初次更新在辅文本上进行，然后再把更新引向该数据的主站点
– 如果主站点此时尚未连通，则另选一个辅站点中的辅文本为该数据新的主文本进行更新
– 待原主文本站点连通后，系统将自动把它改为辅文本，并按记录要求执行更新
– 如果初次更新在主文本上进行，但主文本站点与网络未接通，则此次更新操作失败，事务被撤销，因为无法传播更新
移动文本法的问 题
网络分割成很多部分时，更新处理会不一致
网络分割成 W1,W2,W1中 X更新为 R,W2中 X更新为 S,网络连通时，使用 R还是 S来恢复 X呢？
4.2 主文本更新
4 分布式数据库中的数据更新
快照 (Snapshot)
– 与视图相似,是导出的关系
– 快照的数据是实际存放在数据库中的，视图不是
– 周期地更新
– 用于某些需要“冻结”数据的应用
4.3 快照方法
4 分布式数据库中的数据更新
例子
Define Snapshot HP-Book as
SELECT * FROM Book WHERE Price>$100
REFRESH Every day
特点
– 快照不考虑数据的辅助副本,只关心主文本和这个主本上定义的多个快照
– 快照与视图一样可以定义为一个或多个主副本的部分或全部
– 快照可以完成复杂的查询,但又不阻止更新
– 查询操作可使用快照，也可使用主文本，对更新操作还是在主文本上进行
4.3 快照方法
4 分布式数据库中的数据更新
业务规则约束
– 有效性约束,域约束，数据项的取值范围
– 数据依赖约束,实体完整性和引用完整性
例子
– 取现金时
一个账户的存款余额必须大于零
– 转账时
一个账户的存款余额必须大于零,
事务结束时,两账户中存款总和,必须与事务开始时两账户存款之和相同
– 定期利息计算
事务执行后,所有账户存款之和比事务开始前各账户存款总和大于 10%（假定利息是总额的 10%）
5.1 业务规则的一致性
5 分布式事务增强数据库一致性
业务规则要强制执行
– 用户编写的事务中
– 由 DBMS事务优化器产生的事务中
在产生的分布式执行方案中，要编入业务规则的强制条件
或者从数据字典中获取相关的业务规则，并在生产分布式事务的时候使用它
多数商用分布式 DBMS的事务优化器，只加入少数几类业务规则，为了补救这种不足，需要
– 程序员必须编写加进业务规则的分布式事务
– 必须定期对数据库进行扫描，监测不一致的数据，并予以清除
– 找出那些没有实施的，不能由事务优化器加上的强行业务规则
5.1 业务规则的一致性
5 分布式事务增强数据库一致性
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性
分布式数据库冗余设计的理由
– 提高系统的可用性和可靠性
如果用户由于某种原因无法访问某个成员数据库，
它可以访问另外一个成员数据库上的相同片断
– 提高“读”事务的本地性
降低通信成本
例如，一个片断存放在该事务的原发站点中，那么就免除了传输请求和返回结果的花费
但是，如果事务包含对片断的更新，则其所有副本也必须做同样的更新，这时反而增加而不是降低通信成本
例子
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)
数据库管理员要使得包含冗余的站点以相同的顺序执行事务，来保证数据的一致性
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性
异步复制器
– 冗余数据绝对保持一致是不可能的,一般允许对冗余数据的修改有暂时的不一致,
– 复制数据库的应用
向分站点发送只读数据
在一个周期结束时从分站点对中心站点复制这个周期内改变过的数据
复制数据并建立决策支持系统
建立关键数据的备份副本
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性
不同复制器的差别
– 何时在主副本上获取数据
数据驱动,当事务修改主副本时,获取有关数据修改信息,
并将其写到一个获取文件或队列中。
计时器驱动,由系统在用户定义的时间间隔自动获取相关数据修改信息。 Oracle Simple Snapshot属于这一类方法。
应用程序驱动,由应用中的事件引发系统从主副本把数据复制到获取文件或队列中。 Prism Warehouse Manager采用这种方法。
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性
不同复制器的差别
– 何时把主副本上的数据用到辅助副本上
数据驱动,在主副本上由更新 Trans所做的更新,立即复制,
传输和应用于辅助副本。 HP的 Allbase/Replicate,Open
Ingres Replicator和 Sybase Replication Server采用这种方法
计时驱动,更新事务在主副本上的更新,在用户定义的区间应用于辅助副本,IBM的 Data Propagator/Replicational,
Oracle Simple Snapshot属于这一类方法
应用程序驱动,由应用中的事件引发系统获取文件或队列对辅助副本进行修改。 Prism Warehouse Manager采用这种方法
5.2 冗余数据的一致性
5 分布式事务增强数据库一致性总 结
分布式事务概述（定义、特性和结构等）
分布式事务的执行与恢复
事务管理抽象模型
事务恢复
2PC协议
分布式数据库中的数据更新
分布式事务增强数据库一致性
