SinoDB数据库出现长事务的具体现象：
  长事务会引发逻辑日志耗尽，导致数据库进入叫做“长事务阻塞Blocked:LONGTX”的状态中，数据库服务响应停止。这时候，数据库状态通过onstat – 命令通常有如下提示：

Sinoregal SinoDB Dynamic Server Version 16.8.FC8U0X3 – On-Line (LONGTX) – Up 3 days 23:33:53 – 164468 Kbytes

  当遇到长事务的情况，通常在online.log会发现有不同的长事务的告警信息，需要区分不同的长事务类型，从而采取不同的方法去处理。相应的，在online.log会有两种不同的关于“long transaction”的信息提示：
  第一种（不处理）：
  在online.log中有如下信息提示：“Continuing Long Transaction (for COMMIT): tx:0xc0000000b28f5338 username: xxsp uid: xxx” 在这种情况下，事务使用逻辑日志的量已经超过了长事务高水位值（LTXHWM），但此时的事务本身已进入了“commit”或“roll back”阶段，此时数据库引擎将允许事务继续使用逻辑日志，而不会强行回滚该事物，所以上述类型的长事务不会阻塞数据库，并且系统会自动等待事务自行处理完毕。

  第二种：
  在online.log中有如下信息提示：“Aborting Long Transaction: tx:0xc0000000b8d20c18 username: xxsp uid: xxx” 这种情况的长事务已经超过了长事务高水位值（LTXHWM）并且没有自动进入到“commit”或“roll back”阶段，此时数据库会开始主动进行该长事务回滚。

  处理方案：
  1、收集逻辑日志信息：onstat –lr
  若逻辑日志使用率used%长久没有变化，则可能发生了长事务（也可能回滚写日志），再通过步骤2确定

  2、收集长事务地址address：$ onstat –x
  得到长事务带有R标识（回滚）的address信息

  3、将步骤2出现的address物理地址转换为用户线程会话信息，可以有很多方法，例如：
  onstat -u|grep 1cd55c618
  得到：
  1cd55c618 --RPX-- 1880841 xxsp - 0 0 642073 256446 323049

  4、根据步骤3找出长事务的SQL：onstat -g ses 1880841

  5、确认系统是否配置为逻辑日志自动增加 确认onconfig配置的参数DYNAMIC_LOGS=2
  onstat -g cfg | grep DYNAMIC_LOGS

  6、临时增加逻辑日志以利于继续回滚，可多次运行 onparams -a -d llogdbs -s 50000 –i
  （具体dbspace名称和大小以实际情况为准）

  7、长事务回滚是否结束 onstat -
  观察是否回到online状态

  8、回滚完成后的SQL优化：确认SQL是否为业务需要及合理与否，如有可能，拆分大事务为多笔小事务

  9、如有必要，回收步骤6增加的逻辑日志：onparams -d -l -y

更多信息内容请移步星瑞格官方社区，期待大家加入
Sinoregal Tech ForumAsk questions, share solutions, and get to know the Sinoregal community.https://forum.sinoregal.cn/