---
title: OceanBase 数据库 V3.2.3 版本中 ob_trx_idle_timeout 失效说明-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于OceanBase 数据库 V3.2.3 版本中 ob_trx_idle_timeout 失效说明相关的常见问题和使用技巧，帮助您快速解决OceanBase 数据库 V3.2.3 版本中 ob_trx_idle_timeout 失效说明的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# OceanBase 数据库 V3.2.3 版本中 ob_trx_idle_timeout 失效说明

更新时间：2026-06-12 03:56

内容类型：Troubleshoot  

## 问题现象

OceanBase 租户级别事务超时变量有 `ob_trx_idle_timeout` 和 `ob_trx_timeout`, 它们分别控制事务 SQL 空闲时间和整体事务的执行时间，在部分 OceanBase 数据库 V3.2.3 release 版本中存在 `ob_trx_idle_timeout` 空闲超时失效的情况，本文主要给出排查手段和原因。

## 问题原因

OceanBase 数据库系统参考两个时间点的取值来判断是否出现事务空闲超时。一个时间点是当前事务中上一条语句的结束时间，用 `curr_trans_last_stmt_end_time` 来表示，另一个时间点是上一条语句的执行开始时间，使用 `last_query_start_ts` 来表示。当 `last_query_start_ts < curr_trans_last_stmt_end_time` 的时候，系统进入事务空闲是否超时判断逻辑。

OceanBase 数据库为了性能考虑，代码内部实现缓存时钟（ObClockGenerator），以提高时钟获取效率。在出现变量 `ob_trx_idle_timeout` 失效的版本里，当缓存时钟尚未初始化的时候（clock_generator.inited），`curr_trans_last_stmt_end_time` 的值从系统时间直接获取；当内部时钟已经完成初始化之后，`curr_trans_last_stmt_end_time` 则直接通过原语 `ATOMIC_LOAD` 获取当前时间的缓存值（cur_ts）。如果缓存值与实际系统时间二者出现偏差，导致判断逻辑 `last_query_start_ts < curr_trans_last_stmt_end_time` 无法成立，用户则会观察到 `ob_trx_idle_timeout` 无法生效的问题现象。如下代码段：

![image001](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240619trxideltimeout001.png)

其中，当 `curr_trans_last_stmt_end_time < last_query_start_ts` 的时候导致失效，可以通过打印 debug 日志的方式，观测 `last_query_start_ts` 和`curr_trans_last_stmt_endtime` 实际值，帮助我们进行判断。这里需要注意，调整日志为 debug 级别也不保证这条 debug 日志一定会打印：

而 `curr_trans_last_stmt_end_time` 值取值来自如下：

```shell
session.set_curr_trans_last_stmt_end_time(ObClockGenerator::getClock());

```

为了性能考虑通过内部实现的缓存时钟来提供时钟获取接口，通过原语 load 来获取当前时间戳缓存值赋予给 `curr_trans_last_stmt_end_time`，

## 关键信息

当发现应用事务运行时间未达到空闲时间，而达到事务超时时间时候，可以从日志中去寻找如下信息，确认 `end_trans` 走到了事务超时逻辑，从而帮助我们区分和确认 是事务空闲超时或者事务超时造成的事务中断问题。

```shell
WARN [STORAGE.TRANS] end_trans (ob_trans_service.cpp:1047) [114707][0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=7] [dc=0] transaction timeout and already terminated(trans_desc={tenant_id:1010, trans_id:{hash:15617973398524307547, inc:70296278683, addr:"xxx.xxx.xxx.xxx:xxx", t:1713860598605354}

```

参考代码片段：

![image002](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/sql/20240619trxideltimeout002.png)

## 问题的风险及影响

应用事务空闲超时一般 120s，事务超时时间是 600s。如果遇到事务空闲超时失效的情况，可能会导致非预期的，甚至严重的阻塞问题。比如，用户希望设置事务空闲失效时间来避免过长的锁等待， 一旦遇到行锁冲突而且事务空闲超时失效，业务系统就需要等待事务超时（600s）而不是事务空闲超时（120s）才能释放锁资源。

## 影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

## 适用版本

OceanBase 数据库 V3.x 版本。

## 解决方法及规避方式

- 解决方法：

  如果应用依赖空闲超时时间，可以升级到 OceanBase 数据库 V3.2.3 BP10（oceanbase-3.2.3.3-110000092023091219）及之后版本。

  #### 注意

  `ob_trx_idle_timeout`空闲超时时间在 OceanBase 数据库 V4.x版本后已不再使用。
 - 规避方式：

  无 。

Previous

[事务管理器引用泄露引起系统死锁无法提供服务](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002397822)

Next

[kill session 卡住，会话状态为 SESSION_KILLED 的常见原因及解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003732131) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线