gbase数据、南大通用产品文档：GBase8s配置 GBase 8s Primary Storage Manager

缺省情况下，GBase 8s 主存储管理器 是使用存储管理器中指定的信息和一些 ON-Bar 配
置参数自动配置的。当您使用 onpsm 实用程序时，也会自动对其进行配置。您可以更改
配置。
GBase 8s Primary Storage Manager 仅使用文件设备（磁盘），而不使用磁带。不能将存储
管理器配置为使用磁带。
要手动配置 GBase 8s Primary Storage Manager：
1.
更新 BAR_BSALIB_PATH 配置参数以指向存储管理器库。
例如，在 Linux™ 或 Solaris 上，指定：
BAR_BSALIB_PATH
$GBS_HOME/lib/libbsapsm.so
2.
通过使用 onpsm 实用程序，指定备份与恢复操作的目标和源设备。
3.
根据需要更改您环境的存储管理器的缺省配置：
a. 要覆盖存储管理器日志文件和目录的位置、调试活动和池名称的缺省值，请在
GBase 8s Primary Storage Manager 配置参数中指定新值。
b. 要使用 ON-Bar 和 GBase 8s Primary Storage Manager 指定更大的传输缓冲区，
请增大 BAR_XFER_BUF_SIZE 配置参数中的大小。
c. 要更改 ON-Bar 活动日志中进度消息的频率，请更新 BAR_PROGRESS_FREQ
配置参数中指定的值。
d. 要更改 ON-Bar 并行运行的进程数，请更新 BAR_MAX_BACKUP 配置参数中
指定的值。

两阶段落实环境中的独立操作是一种独立于两阶段落实协议而发生的操作。独立操作可能
与两阶段落实协议指定的操作相对立，也可能不对立。如果操作是与两阶段落实协议相对

GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 492 -
立，那么操作会导致错误或启发式决策。启发式决策可能导致不一致的数据库，并且需要
手动的两阶段落实恢复。手动恢复是非常复杂的管理过程，必须尽量避免。（有关手动恢
复过程的说明，请参阅从失败的两阶段落实手动恢复。）
启动独立操作的情境
两阶段落实协议期间的独立操作很少见，但它可能会发生在以下情况中：
•
参与者的工作片段发展成长事务错误并回滚。
•
管理员在协议的后决策阶段使用 onmode -z 停止参与者线程。
•
管理员在协议的后决策阶段使用 onmode -Z 结束参与者事务（工作片段）。
•
在协调者发出落实决策并知道参与者故障之后，管理员使用 onmode -z 或
onmode -Z 结束了协调者数据库服务器上的全局事务。该操作始终会导致错误，
尤其是错误 -716。
独立操作的可能结果
如前所述，不是所有的独立操作与两阶段落实协议相对立。独立操作可能会产生以下三种
可能的结果：
•
成功完成两阶段落实协议
•
错误状况
•
启发式决策
如果操作不是与两阶段落实协议相对立，那么事务将正常落实或回滚。如果操作过早结束
全局事务，会导致错误状况。在协调者上结束全局事务不会被视为启发式决策。如果操作
与两阶段落实协议相对立，那么会导致启发式决策。 所有这些情况均在随后各节中进行
说明。
允许事务成功完成的独立操作
独立操作不一定需要与两阶段落实协议相对立。例如，如果参与者数据库服务器上的工作
片段因为发展成长事务而回滚，并且协调者发出回滚全局事务的决策，那么数据库将保持
一致。
导致错误条件的独立操作
如果您（作为协调者数据库服务器管理员）在协调者发出其最终的落实决策后运行
onmode -z（停止协调者线程）或 onmode -Z（停止全局事务），那么将从协调者数据库服
务器上的共享内存中除去所有事务的信息。
该操作不会被视为启发式决策，因为它不干扰两阶段协议；它可能是可接受的，或可能干
扰了参与者恢复并导致错误。
在所有参与者可以毫无困难地落实事务的任何时候，该操作均是可接受的。在这种情况
下，强制结束事务的操作是多余的。仅当协调者准备终止事务时，才会收到您运行了
onmode -Z 的指示。

GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 493 -
但实际上，仅当您要尝试加快结束保持打开时间异常长的全局事务时，才可能会考虑在协
调者数据库服务器上运行 onmode -z 或 onmode -Z。在这种情况中，问题的来源可能是某
些参与者数据库服务器上发生的故障。协调者尚未接收到参与者落实其工作片段的确认，
而协调者正在尝试建立与参与者的通信以进行调查。
如果您在协调者正主动尝试重新建立通信的同时运行 onmode -z 或 onmode -Z，那么协调
线程会遵循您的指令而终止，但终止之前它会将错误 -716 写入数据库服务器消息日志。
该操作被视为错误，这是因为两阶段落实协议被强制中断，使协调者不能确定数据库是否
一致。
在协调者数据库服务器上停止全局事务不会被视为启发式决策，但它可能导致不一致的数
据库。例如，如果参与者最终恢复联机但在协调者共享内存中找不到全局事务，它将回滚
其工作片段，从而导致数据库不一致。
导致启发式决策的独立操作
当以下两个条件都成立时，有些独立操作会发展成启发式决策：
•
参与者数据库服务器已经将 can commit 消息发送到协调者并随后回滚。
•
协调者的决定是落实事务。
当两个条件都成立时，最终结果就是未一致实现的全局事务（由一个或多个数据库服务器
落实但由另一数据库服务器回滚）。数据库变得不一致。
以下是两个可能的启发式决策：
•
启发式回滚（在启发式回滚场景中有描述）
•
启发式结束事务（在启发式结束事务场景中有描述）
在发生启发式回滚或结束事务之后，可能必须执行手动恢复，这是一个复杂耗时的过程。
必须完全了解启发式决策，以便避免这些问题。在两阶段落实的上下文中运行 onmode -z
或 onmode -Z 务必谨慎。
启发式回滚场景
在启发式回滚中，数据库服务器或管理员回滚已经发送了 can commit 消息的工作片段。
导致启发式回滚的条件
以下两个条件可能导致启发式回滚：
•
逻辑日志填充至 LTXEHWM 配置参数定义的点。（请参阅《GBase 8s 管理员参
考》 中有关配置参数的主题。）长事务状况的来源是正代表全局事务执行的工作
片段。
•
管理员执行 onmode -z session_id 以停止数据库服务器线程，该线程正在执行代表
全局事务而执行的工作片段。
在任一情况中，如果该工作片段已经向其协调者发送了 can commit 消息，那么该操作被
视为启发式决策。

GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 494 -
条件 1：逻辑日志填充至高水位标志
在两阶段落实中，将阻拦正在等待协调者指令的参与者数据库服务器完成其事务。因为事
务保持打开，所以包含与该事务相关联的记录的逻辑日志文件无法释放。结果是逻辑日志
由于并发用户的活动而继续填充。
如果当参与者正在等待时，逻辑日志填充至长事务高水位标志的值 (LTXHWM)，那么数
据库服务器将指导所有拥有长事务的数据库服务器线程开始回滚这些长事务。如果预落实
的工作片段就是该违规的长事务，那么数据库服务器启动启发式回滚。也就是说，该数据
库服务器在没有协调者的指令或协调者不知道的情况下正在回滚预落实的工作片段。
在两阶段落实中，包含与该工作片段相关联的记录的逻辑日志文件视为打开，直到写入
ENDTRANS 逻辑日志记录。该类型的事务与涉及单个数据库服务器的事务（其中回滚实
际关闭事务）不同。
逻辑日志可能继续填充直至达到互斥高水位标志 (LTXEHWM)。如果发生这种情况，所有
用户线程暂挂，但当前回滚或当前落实的那些线程除外。在两阶段落实应用场合中，打开
的事务使您不能备份逻辑日志文件以及释放逻辑日志中的空间。在这些特殊情况下，逻辑
日志可以完全填充。如果发生这种情况，那么参与者数据库服务器关闭，且您必须执行数
据复原。
条件 2：系统管理员执行 onmode -z
您（作为管理员）可以决定通过运行 onmode -z 来启动预落实工作片段的启发式回滚。
您可能因为希望释放该工作片段拥有的资源而作出该决策。（如果通过运行 onmode -z 停
止参与者线程，那么即便您没有结束事务，也会释放参与者线程拥有的所有锁定和共享内
存资源。）
启发式回滚的结果
这些主题描述了在发生启发式回滚时协调者和参与者上所发生的事件，以及此过程如何会
导致不一致的数据库：
在发生回滚的参与者数据库服务器上，记录放置在数据库服务器逻辑日志（HEURTX 类
型）中。事务拥有的锁和资源得以释放。参与者线程将以下消息写入数据库服务器消息日
志，指示发生了长事务状况和回滚：
Transaction Completed Abnormally (rollback):
tx=address flags=0xnn
协调者发出后决策阶段指令以落实事务。
发生启发式回滚的数据库服务器上的参与者线程将错误消息 -699 返回至协调者，如下所
示：
-699 Transaction heuristically rolled back.
此时该错误消息不返回至应用程序；它对协调者来说是条内部通知。协调者等待至所有参
与者响应该落实指令。 直至所有参与者报告后协调者才能确定数据库一致性。

GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 495 -
接下去的步骤取决于发生在其他参与者上的操作。可能有两种情境。
情境 1：协调者发出落实并且所有参与者都报告启发式回滚
协调者收集所有来自参与者的响应。如果每个参与者报告启发式回滚，那么后果是会发生
以下事件：
1.
协调者将以下消息写入其自己的数据库服务器消息日志：
Transaction heuristically rolled back.
2.
协调者向所有的参与者发送消息以结束事务。
3.
每个参与者都将 ENDTRANS 记录写入其逻辑日志缓冲区中。 （从事务表中除去该
事务条目。）
4.
协调者将错误 -699 返回至应用程序，如下所示：
-699 Transaction heuristically rolled back.
5.
在这种情况下，所有数据库保持一致。
情境 2：协调者已发出落实；有一个参与者落实并有一个参与者报告启发式回滚
协调者收集所有来自参与者的响应。如果至少一个参与者报告启发式回滚并且至少一个参
与者报告确认落实，那么该结果称为混合事务结果。后果是发生以下事件：
1.
协调者将以下消息写入其本身的数据库服务器消息日志：
Mixed transaction result. (pid=nn user=userid)
pid 值是协调者过程的用户过程标识号。 user 值是与协调者进程相关联的用户标识。与该
消息相关联的是附加消息，这些附加消息列出每个报告了启发式回滚的参与者数据库服务
器。附加消息采用以下形式：
Participant database server dbservername heuristically rolled back.
2.
协调者向每个启发式回滚其工作片段的参与者发送消息，指导各参与者结束事务。
3.
每个参与者都将 ENDTRANS 消息写入其逻辑日志缓冲区中。 （从事务表中除去该
事务条目。）
4.
协调者将 ENDTRANS 消息写入其逻辑日志缓冲区中。 （从共享内存事务表中除去
该事务条目。）
5.
协调者将错误 -698 返回至应用程序，如下所示：
-698 Inconsistent transaction. Number and names of servers rolled back.
6.
与该错误消息相关联的是报告了启发式回滚的参与者数据库服务器的列表。如果大量
数据库服务器回滚该事务，此列表可能会被截断。完整的列表始终包含在协调者数据
库服务器的消息日志中。

GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 496 -
在这种情况中，检查每个参与者数据库服务器站点上的逻辑日志并确定您的数据库系统是
否一致。（请参阅确定事务是否不一致地实现。）
启发式结束事务场景
启发式结束事务是管理员采取的独立操作，以便回滚工作片段并从事务表中除去所有有关
事务的信息。当管理员执行 onmode -Z address 命令时会启动启发式结束事务进程。
每当通过运行 onmode -Z 来启动启发式结束事务，都会除去数据库服务器支持两阶段落
实协议及其自动恢复功能所需的关键信息。如果运行 onmode -Z，那么您应负责确定您的
联网数据库系统是否一致。
何时执行启发式结束事务
仅在一种很少见的情况下，才必须运行 onmode -Z 选项来启动启发式结束事务。 当已启
发式回滚的工作片段保持打开时会发生这种情况，它会使您的逻辑日志文件不能成为可用
的文件。结果，逻辑日志将十分接近填满，这很危险。
通常，协调者会在合理时间段内发出其落实或回滚决策。 但是，如果协调者发生故障，
不返回联机状态以结束在参与者数据库服务器上启发式回滚的事务，您可能会面临严重的
问题。
问题应用场合以如下方式开始：
1.
代表全局事务执行工作片段的参与者线程已向协调者发送 can commit 响应。
2.
工作片段等待来自协调者的指令。
3.
当工作片段正在等待时，逻辑日志填充超过长事务高水位标志。
4. 正在等待指令的工作片段是长事务的来源。参与者数据库服务器指导执行线程回
滚该工作片段。该操作就是启发式回滚。
5.
参与者继续等待协调者指导其结束事务。事务保持打开。逻辑日志继续填充。
如果协调者联系参与者并指导其在合理的时间段内结束事务，那么不会产生任何问题。
如果在参与者数据库服务器上发生启发式回滚并且随后协调者发生故障，致使协调者不能
指导参与者结束事务，那么会发生严重问题。
结果，事务保持打开。打开的事务使您不能备份逻辑日志文件以及释放逻辑日志中的空
间。当逻辑日志继续填充时，它可能会达到互斥存取长事务高水位标志 (LTXEHWM) 指
定的点。如果到达该点，正常的处理将暂挂。在到达高水位标志后的某个时刻，您必须判
定打开的事务是否在危及您的逻辑日志。危险就是如果逻辑日志完全填满，那么数据库服
务器关闭，并且您必须执行数据复原。
您必须决定是结束事务并保护您的系统不会有填满逻辑日志的可能性（而不考虑所有与运
行 onmode -Z 相关联的问题），还是等着查看是否能及时重新建立与协调者的通信，以
便在逻辑日志填满前结束事务。
如何使用 onmode -Z

GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 497 -
只有在协调者和参与者之间的通信中断时，才会考虑使用 onmode -Z address 命令。为了
确保该通信真正中断，在正执行工作片段的线程由于超过 TXTIMEOUT 指定的时间量而
终止之前，onmode -Z 命令不会运行。 有关此选项的更多信息，请参阅《GBase 8s 管理
员参考》。
address 参数可从 onstat -x 输出中获取。有关 onstat -x 选项的更多信息，请参阅《GBase
8s 管理员参考》。
启发式结束事务时执行的操作
运行 onmode -Z 时，您指示 onmode 实用程序从事务表中除去了位于指定地址的参与者事
务条目。
逻辑日志中写入了两条记录以记载该操作。 记录类型为 ROLLBACK 和 ENDTRANS，
或如果事务已经启发式回滚，那么仅有类型 ENDTRANS。以下消息写入参与者数据库服
务器消息日志：
(time_stamp) Transaction Completed Abnormally (endtx): tx=address flags:0xnn
user username tty ttyid
协调者接收来自发生了 onmode -Z 的参与者的错误消息以作为其对 COMMIT 指令的响
应。协调者查询参与者数据库服务器，该服务器不再有有关事务的消息。参与者数据库服
务器上缺少事务表条目就表明事务已落实。 协调者假设参与者已发送确认消息，但由于
某种原因未接收到该消息。因为协调者不知道此参与者的工作片段未落实，所以未生成指
示全局事务不一致实现的消息。只有运行 onmode -Z 命令的管理员才会知道实现不一致。
监视全局事务
使用 onstat -x 命令跟踪开放事务并确定它们是否已经启发式回滚。
例如，在输出中，flags 字段中的 H 标志标识启发式回滚，G 标志标识全局事务，L 标志
指示松耦合方式，而 T 标志指示紧耦合方式。
curlog 和 logposit 字段提供逻辑日志记录的准确位置。 如果事务未在回滚，那
么 curlog 和 logposit 描述最近写入的日志记录。当事务在回滚时，这些字段描述最近“撤
销”的日志记录。在事务回滚时，curlog 和 logposit 值会减少。在长事务中，
logposit 和 beginlg 的值汇聚的速率可帮助您估计回滚将需要的更多时间量。
有关 onstat -x 输出的更多信息及其示例，请参阅《GBase 8s 管理员参考》。
还可以使用 onstat -u 和 onstat -k 命令跟踪事务以及它们保存的锁。有关 onstat -x 显示的字
段的描述，请参阅《GBase 8s 管理员参考》。
在辅助服务器上，当启用了故障转移后完成事务（通过设置 FAILOVER_TX_TIMEOUT
配置参数）时，两个全局事务可能有相同的全局事务标识：一个是本地临时全局事务，另
一个是属于恢复线程的全局事务。快速区分真正的全局事务与临时事务的方法是，如果真
正的事务执行了任何操作，将有一个 B 标志。也可通过使用 onstat -g ath 命令来检查事务
的所有者。调用了 xa_end() 函数之后，将删除辅助服务器上的临时全局事务。

GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 498 -
以下 onstat 实用程序的示例输出说明了高可用性集群环境中主服务器和辅助服务器上对
XA 事务的支持。onstat -x、onstat -G 和 onstat -ath 命令会单独记录，但是组合的 onstat -
xG 命令的输出专门针对全局事务。示例显示了重定向事务的每种状态。
在示例中，所显示的在辅助服务器上运行的全局事务是临时事务。临时事务用于支持在辅
助服务器上执行的 SQL 语句（而非重定向到主服务器的事务）。仅当用户线程主动与全
局事务分支关联时，才会显示临时事务。
以下示例显示运行 xa_start() 函数之后在辅助服务器上运行的 onstat -xG 命令生成的输
出：
Transactions

est.
address flags userthread locks begin_logpos current logpos
isol rb_time retrys coord
7000000104d4190 AT--G 7000000104a7b68 0 - -
LC - 0
7000000104d8bd0 ALB-G 7000000104a5aa8 1 180:0x0
180:0x4eb018 DIRTY 0:00 0

Global Transaction Identifiers
address flags isol timeout fID gtl bql data
7000000104d4190 AT--G COMMIT 0 5067085 15 4
000102030405060708090A0B0C0D0E0F000000
7000000104d8bd0 ALB-G DIRTY 0 5067085 15 4
000102030405060708090A0B0C0D0E0F000000
在辅助服务器上运行的 onstat -g ath 生成的输出：
Threads:
tid tcb rstcb prty status vp-class name
317 7000001500902c8 7000000104a7b68 1 cond wait netnorm
1cpu sqlexec
84 7000001403a7dc0 7000000104a5aa8 3 sleeping secs: 1
5cpu xchg_2.0
在主服务器上运行的 onstat -xG 生成的输出：
Transactions

est.

GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 499 -
address flags userthread locks begin_logpos current logpos
isol rb_time retrys coord
7000000104d9e60 ATB-M 7000000104a8bc8 2 180:0x4ea018
180:0x4eb018 COMMIT 0:00 0

Global Transaction Identifiers
address flags isol timeout fID gtl bql data
7000000104d9e60 AT--M COMMIT 0 5067085 15 4
000102030405060708090A0B0C0D0E0F000000
以上示例中的 M 标志指示全局事务是从辅助服务器启动的。在主服务器上启动的全局事
务会显示 G 标志。M 标志仅在主服务器上显示。
onstat -g ath|grep 7000000104a8bc8 命令生成的输出：
196 70000013012d3a8 7000000104a8bc8 1 sleeping secs: 1
4cpu proxyTh
以下示例显示运行 xa_end() 函数之后在辅助服务器上运行 onstat -xG 命令生成的输出：
Transactions

est.
address flags userthread locks begin_logpos current logpos
isol rb_time retrys coord
7000000104d8bd0 ALB-G 7000000104a5aa8 1 180:0x0
180:0x4ee018 DIRTY 0:00 0

Global Transaction Identifiers
address flags isol timeout fID gtl bql data
7000000104d8bd0 ALB-G DIRTY 0 5067085 15 4
000102030405060708090A0B0C0D0E0F000000
在主服务器上运行 onstat -xG 命令生成的输出：
Transactions

est.
address flags userthread locks begin_logpos current logpos
isol rb_time retrys coord
7000000104d9e60 -TB-M 0 2 180:0x4ea018
180:0x4ee018 COMMIT 0:00 0


GBase 8s 管理员指南
南大通用数据技术股份有限公司
- 500 -

Global Transaction Identifiers
address flags isol timeout fID gtl bql data
7000000104d9e60 -T--M COMMIT -1 5067085 15 4
000102030405060708090A0B0C0D0E0F000000
运行 xa_prepare() 函数之后在辅助服务器上运行 onstat -xG 命令生成的输出：
Transactions

est.
address flags userthread locks begin_logpos current logpos
isol rb_time retrys coord
7000000104d8bd0 ALX-G 7000000104a5aa8 1 180:0x0
180:0x4ef018 DIRTY 0:00 0

Global Transaction Identifiers
address flags isol timeout fID gtl bql data
7000000104d8bd0 ALX-G DIRTY 0 5067085 15 4
000102030405060708090A0B0C0D0E0F000000
在主服务器上运行 onstat -xG 命令生成的输出：
Transactions

est.
address flags userthread locks begin_logpos current logpos
isol rb_time retrys coord
7000000104d9e60 -TX-M 0 2 180:0x4ea018
180:0x4ef018 COMMIT 0:00 0

Global Transaction Identifiers
address flags isol timeout fID gtl bql data
7000000104d9e60 -TX-M COMMIT -1 5067085 15 4 0

使用GBase C API 连接集群
GBASE* gbase=NULL;
CHAR* host=”192.168.5.64;192.168.5.67;”; // 集群各节点的IP 地址
/*初始化GBASE 结构体*/
if(!(gbase = gbase_init(0)))
{
fprintf(stderr, "不能初始化GBASE 结构体！\n");
exit(1);
}



GBase 8a 程序员手册C API 篇
南大通用数据技术股份有限公司

- 71 -
/*数据库连接*/
if(!gbase_real_connect(gbase, host, user, passwd, db, port, NULL,
0))
{
fprintf(stderr, "\n%s\n", gbase_error(gbase));
exit(1);
}
/*释放数据库连接句柄*/
gbase_close(gbase);