--- title: OceanBase 数据库事务管理中的 upper_trans_version-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于OceanBase 数据库事务管理中的 upper_trans_version相关的常见问题和使用技巧，帮助您快速解决OceanBase 数据库事务管理中的 upper_trans_version的难题。 image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # OceanBase 数据库事务管理中的 upper_trans_version 更新时间：2026-06-10 09:51 适用版本： V4.0.x、V4.1.x、V4.2.x 内容类型：TechNote OceanBase 数据库事务管理中的 `upper_trans_version` 是决定了 Minor SSTable 中可回收位点的关键逻辑，本文将详细展开相关概念以及已知问题。 `upper_trans_version` 是事务管理和存储管理逻辑中的一个关键逻辑，OceanBase 数据库内核团队会追踪相关的问题并在发现问题后尽快修复，具体的问题请参考本文**详细说明**章节。对用户来说，应当尽快推高到包含修复的版本。滞留在有问题的版本是有风险的。 ## 详细说明 OceanBase 数据库 V3.x 版本开始有了转储未提交事务能力，未提交的事务也会被持久化到 Minor SSTable 上，后续已提交事务持久化到 major sstable（也叫做基线 sstable）后，数据会同时存在在 minor 和 major 中。 如果长时间不回收这部分已经“**没有用**”的 Minor SSTable，既会导致读链路的增长影响相关查询的 RT，也有可能造成不必要的磁盘空间浪费。如果系统中有大量并发的事务，这些事务在不同时间开始，不同时间结束，系统的转储合并动作也同时在后台发生，就需要有一个明确的算法决定哪些 Minor SSTable 是需要回收的。OceanBase 数据库 V3.x 的事务状态都存储在内存中，事务状态也有一个标识来标记事务是否需要被保留。`upper_trans_version` 的计算逻辑是根据内存态的信息计算，计算的逻辑也相对简单。 OceanBase 数据库 V4.x 为了更好的管理事务状态数据，引入了事务上下文表和事务数据表，这些运行态的信息也同样可以通过转储合并持久化下来，但这同时导致 `upper_trans_version` 这个用于决定 minor 可回收位点的逻辑发生了变化也变地更加复杂：当 major sstable 的事务快照右边界超过 Minor SSTable 的 `upper trans version` 才可以回收 Minor SSTable。 OceanBase 数据库内核计算出“**正确**”的 `upper_trans_version` 是非常重要的，如果 `upper_trans_version` 计算的偏小，会导致本来应该保留的 minor 被回收，本来应该被读到的事务没有了，会导致数据正确性问题。精准地计算出 `upper_trans_version` 在大事务和复杂系统上是有代价的，如果 `upper_trans_version` 只是略微偏大，是没有问题的，只会有少量的（甚至是不可见）的性能代价，但比精准计算出 `upper_trans_version` 就会划算很多。 在计算 `upper_trans_version` 时，每个 SSTable 的 `upper_trans_version` 被初始化为 `INT64_MAX`，也就是 9，223，372，036，854，775，807。如果 `upper_trans_version` 长久地计算不出来（维持在默认值 `INT64_MAX`），这会导致判断 minor 回收位点无法进行。minor 如果一直被持续生成且来不及及时被回收合并，一方面存储占位会有增长，另一方面积压持续可能导致 SSTable 总数超过 `MAX_SSTABLE_CNT_IN_STORAGE（64）` 个（相关任务会收到报错 -4037）。如果有持续的事务和写入，有可能会导致 OceanBase 数据库的限速机制生效，最终导致用户的请求响应受到影响。 `upper_trans_version` 计算不出来的影响和相关概念需要展开详细解释三点： `upper_trans_version` 如果计算不出来，大概率并不会第一时间就产生用户可感知的影响。`upper_trans_version` 直接影响的是 OceanBase 数据库中 Minor SSTable 生产与消费的过程。系统不断有写入，转储的过程会生成 Minor SSTable；系统 minor 回收、合并的过程会消费 Minor SSTable（转储合并中有 mini，minor 更复杂地逻辑本文暂时不展开，不影响主逻辑）。如果生产 minor 的速度没有消费的速度快，最终造成了 `Minor SSTable` 的堆积（e.g. 最终 SSTable 超过 64 个），此时还有很高的 TPS 可能就会产生可感知的影响。 但终归需要时间累积和负载累积才会外显出可见的影响。不过任何 OceanBase 数据库的集群，特别是生产集群想要保持集群稳定无风险都要避免 `upper_trans_version` 长时间计算不出来（比如天数以上），因为一旦发生影响面是大的，且止损方式是有代价的。 第二点需要解释一下为什么系统中可能存在 `upper_trans_version` 没有立即计算出来的情况：这是因为当前的算法逻辑还依赖事务的状态。 如果系统中还存在正在运行中的事务，特别是长事务，那在长事务完结前 `upper_trans_version` 就是无法被计算出来的。所以在 [Minor/Mini SSTable 的 UPPER_TRANS_VERSION 长时间算不出来](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002762604?back=kb)中提供的巡检逻辑是：长时间的计算不出来的 `upper_trans_version` 是需要被监控的风险。后续也会增强在 OceanBase 数据库的运行日志告警逻辑中。OceanBase 数据库内核团队还在持续优化 `upper_trans_version` 的算法，未来预期会有优化。 当系统长时间计算不出来 `upper_trans_version`，且系统持续有大量的 TPS 涌入，用户可能感受到存储空间占用放大；TPS 下跌，RT 变慢的现象。如果不幸因为 `upper_trans_version` 计算有问题导致这些系统行为，通过现象进行根因诊断是艰难的。这也是因为 OceanBase 数据库的容错机制在能力越来越强的同时也越来越复杂：如果直接导致了 MemStore 限速，大概率计算不出来 `upper_trans_version` 的节点是一定会受到写入影响，取决于集群架构（如是 3F、2F1A，Leader是否打散）的具体情况，可能影响部分节点或者系统全局的请求响应；如果 MemTable 无法刷盘导致 clog checkpoint 位点无法推进，影响 clog 的回收机制，当 clog 不可回收日志（`cur_unrecyclable_log_disk_size`）达到 60%（OceanBase 数据库 V4.x 版本 clog 限速启动的默认配置，`log_disk_throttling_percentage`），最终会导致触发 clog 提交限速。导致系统中相关的请求受到影响。但 clog 限速达到的影响面会更加复杂一些， 这是因为 clog 组件在 OceanBase 数据库 V4.x 版本也做了更多优化，例如感知 Leader IO 能力下的 clog 聚合算法提升，这对部分故障场景会有消减影响的作用，最终导致只有部分请求受到影响。对用户是件好事情，但也同时提高了诊断的难度。对系统来说，是遇到 MemStore 限速还是 clog 限速，就看系统在 MemStore 内存资源和 clog 存储资源哪个相对“**更富裕**”，哪个是系统这个木桶的“**短板**”。 对 OceanBase 数据库集群而言，理解 `upper_trans_version` 是复杂和需要深入地，要诊断 `upper_trans_version` 相关的问题是有代价且有难度的。OceanBase 数据库内核团队会追踪相关的问题并在发现问题后尽快修复。对用户来说，应当尽快推高到包含修复的版本。滞留在有问题的版本是有风险的。 目前 OceanBase 数据库 V4.x 版本有两个已知的问题会导致 `upper_trans_version` 计算不出来： - OceanBase 数据库 V4.2.5 版本，在增强 transfer 不杀事务能力时，工程实现中引入了一个 `upper_trans_version` 计算不出来的问题。 在 OceanBase 数据库 V4.2.5 BP2 Hotfix3（oceanbase-4.2.5.2-102030052025032518）及 V4.2.5 BP3（oceanbase-4.2.5.3-103000142025033110）上进行了修复。详细参见：[Minor/Mini SSTable 的 UPPER_TRANS_VERSION 长时间算不出来](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002762604?back=kb)。 - OceanBase 数据库 V4.2.1 版本，有一个 HA 场景下 `upper_trans_version` 计算不出来的。 在高版本也进行了修复。 ## 影响版本 影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。 ## 适用版本 OceanBase 数据库 V4.x版本。 上一篇 [OceanBase 数据库 MySQL 模式下的事务隔离级别指南](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002394943) 下一篇 [后台巡检导致 RS 上任失败](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006783776) ![有帮助](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) 咨询热线