【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.5.1
【问题描述】Mini SSTable 的 UPPER_TRANS_VERSION 长时间算不出来,这个影响大不大
【复现路径】问题出现前后相关操作
【附件及日志】
SELECT svr_ip,svr_port,table_type,tenant_id,ls_id,tablet_id,size,usec_to_time(END_LOG_SCN/1000) as usec_to_time,(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_seco
nds desc ;
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
2 个赞
论坛小助手
#3
您描述的问题与 OceanBase 数据库中 SSTable 的 UPPER_TRANS_VERSION 计算延迟有关。这种延迟可能会影响系统的性能，特别是对于读取操作，因为数据库需要等待此版本信息来确保数据的一致性。
推荐使用 obdiag 工具进行日志采集，并且将采集到的日志提供给我们以便确认问题所在。
日志采集场景: 合并问题
日志采集命令: obdiag gather scene run --scene=observer.compaction
这条命令会帮助收集与合并相关的日志，包括但不限于SSTable的创建、修改和删除等行为，有助于我们分析为何UPPER_TRANS_VERSION长时间未能计算出来的原因。
麻烦您提供一些信息以便我们更好地帮助您：
- 请问这个问题是在特定时间点开始出现的吗？例如在执行某些大型操作后？
- 您是否注意到最近有对系统配置或参数进行了调整？
- 能否分享一下当前集群的规模（如服务器数量）以及受影响的表的大致大小？
- 是否有其他异常现象伴随出现，比如更高的CPU使用率或磁盘I/O？
- 可以提供一下通过
show parameters like 'minor_freeze_times'和show parameters like 'major_freeze_duty_time'获取的输出结果吗？这将帮助了解当前的合并策略设置。
请您按照上述命令运行obdiag工具并反馈相关信息，我们将根据您的回复进一步指导如何解决这个问题。感谢您的配合！
附上敏捷诊断工具 obdiag 使用帮助链接
UPPER_TRANS_VERSION是什么参数呀，起什么使用呢
旭辉
#5
一般来说不会立即产生严重影响，但是长期算不出来可能会导致磁盘占用变高，minor执行变慢，查询变慢等
旭辉
#6
定义upper_trans_version为一个sstable上所有数据对应的事务的最大提交版本号
旭辉
#7
1 个赞
