长事务故障状态处理

OceanBase 技术问题
, , ,
#1

【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】4.2.1.7
【问题描述】长事务故障状态处理
【复现路径】通过连开发者平台查询
SELECT *
FROM GV$OB_TRANSACTION_PARTICIPANTS
WHERE CTX_CREATE_TIME < date_sub(now(), INTERVAL 600 SECOND)
AND ROLE = ‘LEADER’
AND ACTION = ‘START’;
SESSION_ID 使用连接工具连接到OBsever节点 kill SESSION_ID 后该 SESSION_ID没有了 会出现新的长事务新的 SESSION_ID

社区
社区1864×773 48.2 KB

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

#3

推荐使用 obdiag 工具进行日志采集，并且将采集到的日志提供给我们以便确认问题所在。

日志采集场景: 长事务
日志采集命令: obdiag gather scene run --scene=observer.long_transaction

请您按照上述命令进行日志采集，并将采集到的日志压缩包提供给我们。这将有助于我们进一步分析问题。

另外，为了确定具体的问题，在此需要您提供一些信息：

  1. 您是否对 OceanBase 进行过任何配置变更或系统升级？
  2. 长事务的具体 SQL 语句是什么？能否提供这些 SQL 语句的详细信息？
  3. 在出现长事务故障时，系统的负载情况如何？是否有其他异常告警信息？
  4. 是否有定期维护计划（如数据归档、索引重建等），这些操作的时间点与长事务出现的时间点是否重合？

感谢您的配合，我们会尽快为您解决问题。

附上敏捷诊断工具 obdiag 使用帮助链接

#4

SHOW VARIABLES like ‘version_comment’; 具体查一下版本号信息
如果长事务 要看一下 你们的这个事务为什么要执行这么久 是不是事务过大的导致 或者事事务有的语句执行很慢 导致的事务不合理