以下主题概述了确定数据库一致性并更正相关情况（如果需要）的过程中的步骤。
以下主题中描述了其中每个步骤。
确定事务是否不一致地实现
首要任务是确定事务是否由于独立操作而不一致地实现。
GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 521 -
全局事务过早结束
如果运行了 onmode -z 命令来结束协调者上的全局事务，
那么事务可能会不一致地实现。
（有
关该情况会如何发生的说明，请参阅导致错误条件的独立操作。）您可以通过首先检查数
据库服务器消息日志来检查协调者是否有不一致的事务。查找以下错误消息：
-716 Possible inconsistent transaction.
Unknown servers are server-name-list.
该消息列出所有充当参与者的数据库服务器。 检查每个参与者的逻辑日志。如果至少一个
参与者执行了落实且一个参与者执行了回滚，那么事务不一致地实现。
启发式结束事务
如果运行了 onmode -Z address 命令来结束某个参与者执行的工作片段，
并且协调者决定落
实事务，那么事务将不一致地实现。（有关该应用场合的描述，请参阅启发式结束事务场
景。）检查每个参与者的逻辑日志。如果至少一个参与者执行了落实且一个参与者执行了
回滚，那么事务不一致地实现。
启发式回滚
您可以用以下方法来确定启发式决策所影响的特定数据库服务器参与者，从而回滚事务：
检查应用程序中 COMMIT WORK 语句的返回码。
以下消息指示有一个参与者执行了启发式回滚：
-698 Inconsistent transaction. Number and names of servers rolled back.
检查数据库服务器消息日志文件的消息。
如果由于参与数据库服务器上的启发式决策导致有可能出现数据库不一致，那么协调
者的数据库服务器消息日志文件中会出现以下消息：
Mixed transaction result. (pid=nn user=user_id)
无论何时返回错误 -698，均会写入该消息。与该消息相关联的是事务回滚所涉及的参
与者数据库服务器的列表。这是完整的列表。 如果大量参与者回滚了该事务，那么与
-698 错误消息一起创建的列表可能会被截断。
检查每个参与者的逻辑日志。
如果至少一个参与者回滚了其工作片段并且一个参与者落实了其工作片段，那么事务
将不正确地实现。
确定分布式数据库是否包含不一致的数据
如果您确定事务是不一致地实现，您必须确定这种情况对您的分布式数据库系统意味着什
么。您尤其必须确定数据完整性是否受到影响。
无论何时当一个参与者回滚的工作片段与另一参与者更新的工作片段相关时，不一致实现
的事务就造成了问题。不能使用 SQL 定义这些依赖性，因为分布式事务不支持引用多个
GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 522 -
数据库服务器上数据的约束。仅当数据已在两个独立事务中更新时，该工作片段才是独立
的（不存在相关性）。否则，就认为该工作片段是有相关性的。
在您继续之前，请考虑导致该错误的事务。更新的数据段和回滚的数据段是否互相相关？
单个事务可能会由于其他原因（而不是维护数据完整性）而包含多次更新。 例如，以下是
三种可能的原因：
减少的事务开销
简化的编码
程序员喜好
并验证每个假设已落实事务的数据库服务器实际修改了数据。只读数据库服务器可能会作
为已落实事务的参与者而列出。
如果不一致的事务没有导致数据完整性的违例，此时您就可以退出该过程。
获取逻辑日志记录中的信息
要确定数据完整性是否受到不一致实现的全局事务的影响，必须重建全局事务，并确定事
务的哪些部分已落实，哪些已回滚。使用 onlog 实用程序获取必要信息。过程如下：
1.
在包含 HEURTX 记录的参与者上重建事务。
a. 参与者数据库服务器逻辑日志是您进行信息搜索的开始点。日志中的每条记录均
有本地事务标识号 (xid)。获取 HEURTX 记录的 xid。
b. 使用本地 xid 定位所有相关联的日志记录，
这些记录作为该工作片段的一部分而
回滚。
2.
确定哪一数据库服务器是充当全局事务的协调者。
a. 查找参与者上包含相同本地 xid 的 PREPARE 记录。
PREPARE 记录为该参与
者标记了两阶段落实协议的起点。
b. 使用 onlog -l 选项获取 PREPARE 记录的详细输出。
该记录包含全局事务标识 (GTRID) 和协调数据库服务器的名称。有关 GTRID
的信息，请参阅获取全局事务标识。
3.
从协调者日志获取其他参与者的列表。
a. 检查协调者数据库服务器上的日志记录。 找到 BEGPREP 记录。
b. 检查 BEGPREP 记录的详细输出。
如果该记录中 GTRID 的前 32 字节与参与者的 GTRID 相匹配，那么
BEGPREP 记录是同一全局事务的一部分。请注意，BEGPREP 详细输出的
ASCII 部分中显示的参与者。
4.
重建每个参与者上的事务。
GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 523 -
a. 在每个参与者数据库服务器上，读取逻辑日志以找到包含与该事务关联的
GTRID 的 PREPARE 记录，并获取该参与者执行的工作片段的本地 xid。
b. 在每个参与者数据库服务器上，使用本地 xid 定位所有与该事务（已落实或已
回滚）相关联的逻辑日志记录。
在您遵循该过程之后，您将知道事务的所有参与者是哪些、分配给每个参与者哪些工作片
段以及每个工作片段是已回滚还是已落实。根据该信息，您可以确定独立操作是否影响了
数据完整性。
获取全局事务标识
当全局事务开始时，
它会接收到称为全局事务标识 (GTRID) 的唯一标识号。
GTRID 包含
协调者的名称。GTRID 已写入协调者的 BEGPREP 逻辑日志记录以及每个参与者的
PREPARE 逻辑日志记录。
要查看 GTRID，
请使用 onlog -l 选项。
GTRID 在记录的数据部分中偏移了 20 字节，
长为
144 字节。以下示例显示 BEGPREP 记录的 onlog -l 输出。协调者为 chrisw。
4a064 188 BEGPREP 4 0 4a038 0 1
000000bc 00000043 00000004 0004a038 .......C .......8
00087ef0 00000002 63687269 73770000 ..~..... chrisw..
00000000 00000000 00000000 00087eeb ........ ......~.
00006b16 00000000 00000000 00000000 ..k..... ........
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000001 6a756469 74685f73 ........ judith_s
6f630000 736f6374 63700000 oc..soct cp..
协调者上的 BEGPREP 记录与参与者（这些参与者是同一全局事务的一部分）上的
PREPARE 记录的 GTRID 的前 32 字节相同。例如，将以下示例中 PREPARE 记录的
GTRID 与上一个示例中 BEGPREP 记录的 GTRID 相比较。
c7064 184 PREPARE 4 0 c7038 chrisw
000000b8 00000044 00000004 000c7038 .......D ......p8
00005cd6 00000002 63687269 73770000 ...... chrisw..
00000000 00000000 00000069 00087eeb ........ ...i..~.
00006b16 00000000 00000010 00ba5a10 ..k..... ......Z.
00000002 00ba3a0c 00000006 00000000 ......:. ........
00ba5a10 00ba5a1c 00000000 00000000 ..Z...Z. ........
GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 524 -
00ba3a0e 00254554 00ba2090 00000001 ..:..%ET .. .....
00000000 00ab8148 0005fd70 00ab8148 .......H ...p...H
0005fe34 0000003c 00000000 00000000 ...4...< ........
00000000 00ab80cc 00000000 00ab80c4 ........ ........
00ba002f 63687269 73770000 00120018 .../chrisw......
00120018 00ba0000 ........
确定是否需要执行操作来更正情况
如果不一致的事务创建了不一致的数据库，那么您可以有以下三个选项：
让联网数据库保持处于不一致状态。
除去落实事务之处受到的事务影响，从而回滚整个事务。
在回滚事务之处重新应用事务的影响，从而落实事务。
如果事务未严重影响数据库数据，那么您可以让数据库保持处于不一致状态。如果正在执
行事务的应用程序可以继续按原状执行，并且您得出的决定是通过除去影响或重新应用事
务来将数据库返回至一致状态的成本（时间与工作量方面的成本）过高，您就可能会遇到
这种情况。
无需立即作出此决定。您可以使用以下段落中描述的方法来确定事务在更新哪些数据以及
哪些记录受到影响。
当您作决定时，请考虑到没有自动过程或实用程序可以执行已落实事务的回滚或可以落实
已回滚事务的一部分。以下段落描述如何浏览数据库服务器消息日志和逻辑日志以找到受
影响的记录。如果不具备详细的应用程序知识，那么仅凭消息不足以确定所发生的事件。
根据您的应用程序和系统的知识，您必须确定是回滚还是落实事务。您还必须对执行回滚
或落实的补偿事务进行编程。