两阶段落实协议在执行事务期间发生系统或介质故障的情况下提供自动恢复机制。两阶段
落实协议确保所有参与的数据库服务器接收并执行同一操作（落实或回滚事务），而不论
是否有本地或网络故障。
如果有任何数据库服务器无法落实它这一部分的事务，那么一定会阻止参与该事务的所有
数据库服务器落实各自的工作。
何时使用两阶段落实协议
数据库服务器对任何在多个数据库服务器上修改数据的事务自动使用两阶段落实协议。
例如，假设连接了三台名为 australia、italy 和 france 的数据库服务器，如下图所示。
图: 已连接的数据库服务器
如果运行以下示例中显示的命令，那么结果是在三台不同的数据库服务器上执行一次更新
和两次插入。
CONNECT TO stores_demo@italy
BEGIN WORK
GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 489 -
UPDATE stores_demo:manufact SET manu_code = 'SHM' WHERE
manu_name = 'Shimara'
INSERT INTO stores_demo@france:manufact VALUES ('SHM', 'Shimara', '30')
INSERT INTO stores_demo@australia:manufact VALUES ('SHM', 'Shimara',
'30')
COMMIT WORK
两阶段落实概念
每个全局事务均有一个协调者和一个或多个参与者，定义如下：
•
协调者可指导全局事务的解决方案。它决定全局事务是必须落实还是必须停止。
两阶段落实协议始终将协调者的角色分配至当前数据库服务器。在单个事务期
间，协调者的角色无法更改。 在何时使用两阶段落实协议 中的样本事务中，协
调者是 italy。如果您将该示例中的第一行更改为以下语句，那么两阶段落实协议
将协调者的角色分配至 france：
CONNECT TO stores_demo@france
使用 onstat -x 选项显示分布式事务的协调者。有关更多信息，请参阅监视全局事
务。
•
每个参与者指示一个事务分支的执行，事务分支是涉及单个本地数据库的那部分
全局事务。全局事务在以下情况中包含几个事务分支：
ₒ
应用程序使用多个进程为全局事务工作
ₒ
多个远程应用程序为同一全局事务工作
在何时使用两阶段落实协议 中，参与者是 france 和 australia。协调者数据库服务
器 italy 也起着参与者的作用，因为它也在进行更新。
两阶段落实协议依赖两种通信，消息和逻辑日志记录：
•
消息在协调者和每个参与者之间传递。 来自协调者的消息包括事务标识号和指示
信息（如 prepare to commit、commit 或 roll back）。来自每个参与者的消息包括事
务状态和所采取操作的报告（如 can commit 或 cannot commit、committed 或 rolled
back）。
•
事务的逻辑日志记录保留在磁盘或磁带上以确保即使在参与的数据库服务器（参
与者或协调者）上发生故障时的数据完整性和一致性。
有关更多的详细信息，请参阅两阶段落实和逻辑日志记录。
两阶段落实协议的阶段
GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 490 -
在两阶段落实事务中，协调者将所有数据修改指示信息（例如，插入）发送至所有参与
者。然后，协调者启动两阶段落实协议。两阶段落实协议分两部分，预落实阶段和后决策
阶段。
预落实阶段
在预落实阶段期间，协调者和参与者执行以下对话：
协调者
协调者指导每个参与者数据库服务器准备落实事务。
参与者
每个参与者通知协调者它是否可落实其事务分支。
协调者
协调者根据每个参与者的响应来决定落实还是回滚事务。它仅当所有参与者指示
它们可以落实各自的事务分支时才决定落实。如果有任何参与者指示它尚未准备
好落实其事务分支（或如果它未响应），那么协调者将决定结束全局事务。
后决策阶段
在后决策阶段期间，协调者和参与者执行以下对话：
协调者
协调者将落实记录或回滚记录写入协调者的逻辑日志，然后指示每个参与者数据
库服务器落实或回滚事务。
参与者
如果协调者发出落实消息，那么参与者通过将落实记录写入逻辑日志并将消息发
送至协调者（确认事务已落实）来落实事务。 如果协调者发出回滚消息，那么参
与者回滚事务，但不向协调者发送确认。
协调者
如果协调者发出消息以落实事务，它将在结束全局事务前一直等待以接收来自各
参与者的确认。如果协调者发出消息以回滚事务，它将不等待参与者的确认。
两阶段落实协议如何处理故障
两阶段落实协议设计为用可保留所有参与的数据库服务器上的数据完整性的方式来处理系
统和介质故障。如果发生故障，两阶段落实协议执行自动恢复。
自动恢复处理的故障类型
以下事件可能导致协调线程或参与者线程终止或挂起，因此需要自动恢复：
•
协调者的系统故障
•
参与者的系统故障
GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 491 -
•
网络故障
•
管理员终止协调线程
•
管理员终止参与者线程
管理员在自动恢复中的角色
自动恢复中管理员的唯一角色是在系统或网络故障后将协调者和/或参与者恢复联机。
重要： 慢速网络无法触发自动恢复。除非协调者系统发生故障、网络发生故障或管理员
终止协调线程，否则此处描述的恢复机制均不会生效。
协调者故障的自动恢复机制
如果协调线程发生故障，各参与者数据库服务器必须决定在其落实或回滚事务之前还是在
其回滚事务之后启动自动恢复。此职责是假定结束的优化的一部分。 （请参阅假定结束
的优化。）
参与者故障的自动恢复机制
无论何时参与者线程预落实了在两阶段落实协议可完成之前就终止的一项工作，就会发生
参与者恢复。参与者恢复的目标是根据协调者作出的决定来完成两阶段落实协议。
根据协调者是决定落实还是回滚全局事务，参与者恢复可由协调者或者参与者驱动。
重要： 要在跨服务器事务打开的同时支持下级服务器关闭或重新启动之后的自动恢复，
sqlhosts 文件必须为可能启动分布式操作的每个数据库服务器包含一个条目。在自动恢复
期间，协调者的名称从逻辑日志恢复，且下级服务器与协调者重新连接以完成该事务。由
于协调者总是使用自己的 onconfig 文件的 DBSERVERNAME 配置参数中的名称来向各
参与者标识它自己，因此协调者的 DBSERVERNAME 设置必须是参与者都已知的因特网
协议连接名称，但是也可使用正确的连接协议，为协调者和下级服务器之间的连接至少定
义一个 DBSERVERALIASES 设置。下级服务器必须能够使用协调者的
DBSERVERNAME 设置或 DBSERVERALIASES 设置连接到该协调者。
假定结束的优化
假定结束的优化是描述两阶段落实协议如何处理事务回滚的术语。
回滚是按以下方式处理的。当协调者确定事务必须回滚时，它发送消息给所有的参与者以
回滚它们的工作片段。 协调者不会等待该消息的确认，而是继续进行以关闭事务并将其
从共享内存中除去。如果参与者尝试确定该事务的状态，即查明事务已落实还是已回滚
（例如：在参与者恢复期间）－ 它将在共享内存中找不到任何事务状态。参与者必定将
此解释为表示事务已回滚。