---
title: Minor/Mini SSTable 的 UPPER_TRANS_VERSION 长时间算不出来-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于Minor/Mini SSTable 的 UPPER_TRANS_VERSION 长时间算不出来相关的常见问题和使用技巧，帮助您快速解决Minor/Mini SSTable 的 UPPER_TRANS_VERSION 长时间算不出来的难题。
---
切换语言

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

划线反馈

# Minor/Mini SSTable 的 UPPER_TRANS_VERSION 长时间算不出来

更新时间：2026-06-12 08:51

适用版本： V4.2.x 内容类型：Troubleshoot  

## 问题现象

有多个 SSTable 的 `UPPER_TRANS_VERSION` 是最大值，但是右边界距离当前时间已经比较遥远，就可能有问题。

## 关键诊断信息

### 触发条件

1. 日志流做一次迁移。
 2. 对迁移后日志流。

      1. 开个事务。
      2. 在某个 Tablet 上产生少量写入。
      3. 做一次冻结转储，产生一个转储未提交的 SSTable。
      4. 事务提交。
 3. 后续不再写该 Tablet，其不会被 MinorMerge 碰到。
 4. 等待数小时，能观察到该 Tablet 存在一个有未提交行的 SSTable，且 `UPPER_TRANS_VERSION` 持续算不出来。

### 事前巡检

通过如下 SQL 可以找到一些 `UPPER_TRANS_VERSION` 没算出来，且 `end_log_scn` 很老的 SSTable。

```shell
select svr_ip, svr_port, table_type, tenant_id, ls_id, tablet_id, size, usec_to_time(END_LOG_SCN/1000), (CONVERT(UNIX_TIMESTAMP(NOW(6)) * 1000000, UNSIGNED) - (END_LOG_SCN/1000))/1000/1000 as end_scn_gap_seconds from gv$ob_sstables where TABLE_TYPE != 'MEMTABLE' and UPPER_TRANS_VERSION = 9223372036854775807 and (CONVERT(UNIX_TIMESTAMP(NOW(6)) * 1000000, UNSIGNED) - (END_LOG_SCN/1000))/1000/1000 > 3600 * 24 * 2 order by end_scn_gap_seconds desc;

```

如下图所示。有很多 SSTable。

![image](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/compaction-and-transfer/20250328upper-trans-version-minor-mini-sstable-cannot-calculated-long-time.png)

### 事后诊断

对存在长时间算不出来 SSTable 的租户做一次租户级冻结，等待一段时间（十分钟左右），观察 SSTable 是否有算出 `UPPER_TRANS_VERSION`。若仍然算不出来，大概率遇到了此问题。

## 问题原因

内核 BUG，`UPPER_TRANS_VERSION` 计算逻辑被错误关闭且没有打开。

## 问题的风险及影响

初期不会有明显影响，长时间跑下去可能导致磁盘 IO 压力过大，进而导致转储问题、性能抖动等。

## 影响租户

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

## 影响版本

OceanBase 数据库企业版 V4.2.5 GA（oceanbase-4.2.5.0-100000082024102022）及之后版本。

## 解决方法

- 解决方法一：

  升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.5 BP2 Hotfix3（oceanbase-4.2.5.2-102030052025032518）版本、V4.2.5 BP2 Hotfix4（oceanbase-4.2.5.2-102040012025050823）版本、V4.2.5 BP2 Hotfix5（oceanbase-4.2.5.2-102050032025060612）版本、V4.2.5 BP2 Hotfix6（oceanbase-4.2.5.2-102060012025101315）版本、V4.2.5 BP3（oceanbase-4.2.5.3-103000142025033110）及之后版本。
 - 解决方法二：

     1. 先尝试触发对应租户的租户级冻结。

       ```shell
       obclient> ALTER SYSTEM MINOR FREEZE TENANT mysql;

       ```
     2. 等待冻结结束后大概再过十分钟，继续观察，若仍存在 `UPPER_TRANS_VERSION` 为最大值，且右边界偏老的的 SSTable，说明没法通过转储恢复，必须要做以下的操作。

            1. 重启算不出来 `UPPER_TRANS_VERSION` 的机器（较重）。
            2. 假设 1001 日志流上有 SSTable 的 `UPPER_TRANS_VERSION` 算不出来，随便找个 1001 日志流上的数据量少的 Tablet，做一次手动 transfer，利用 transfer 本身的 disable 和 enable 能力，将 `UPPER_TRANS_VERSION` 计算重新打开（相对轻量）。
            3. 对算不出来 `UPPER_TRANS_VERSION` 的 tablet 做少量写入，确保写入事务已提交后触发冻结和全量 MinorMerge，此时 SSTable 的右边界会推大，所有行能回填版本号，`UPPER_TRANS_VERSION` 就算出来了（比较 trick，可以不走 transfer，但会受到存储写放大系数限制，不一定有用）。

## 规避方式

尽量少触发迁移和 Rebuild。

上一篇

[OceanBase 数据库 V4.2.1.x transfer 误判存在活跃事务，任务卡住无法完成的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001885318)

下一篇

[OceanBase 数据库 V4.x 转储合并信息查询手册及问题排查](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003272267) ![有帮助](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) 咨询热线