--- title: SSTable 数量太多的问题排查-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于 SSTable 数量太多的问题排查相关的常见问题和使用技巧，帮助您快速解决 SSTable 数量太多的问题排查的难题。 --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # SSTable 数量太多的问题排查 更新时间：2025-09-02 03:31 适用版本： V2.1.x、V2.2.x、V3.1.x、V3.2.x、V4.0.x、V4.1.x、V4.2.x 内容类型：TechNote 由于 TableStore 是一个定长数组，当 table 数量超过高水位( 56 个)的时候，便不能添加新的 SSTable 到数组里，由此可能导致不能做 Mini Merge。 在 OceanBase 数据库 V3.2 版本后直接查询 `__all_virtual_compaction_diagnose_info` 诊断虚拟表，如果没有可用信息，再按下列排查手段进行。 Major SSTable 保存的个数由配置项 `max_kept_major_version_number` 决定，默认为2个；在没有设置 undo_retention/ 建索引保存多版本的情况下，只会默认保存 2 个 Major SSTable。 ```sql show parameters like "max_kept_major_version_number"; ``` 有以下几种情况可能会导致保存多版本的数据。 ## 一个未建好的索引表 TableStore 爆掉的 Partition 本身是一个未建好的索引。 ```sql select * from __all_virtual_table where table_id = xxx\G ``` 如果 `data_table_id != 0` 表示为一个索引表。 查看 `index_status != 2` 表示这是一个未建好的索引表，请联系技术支持人员排查索引未建好的原因。如果索引不重要，直接删除。 ## 建索引等需要保存多版本数据 因建索引、restore point 等操作而需要保存的多版本数据，当需要保存多版本数据时，SSTable 没有办法回收。 ```sql select * from __all_acquired_snapshot; ``` 当 `__all_acquired_snapshot` 表为空，也可以通过 `__all_virtual_table` 查看该表是否有在建索引的信息。 ```sql select * from __all_virtual_table where data_table_id = xxx; ``` 如果查询的结果中 `index_status != 2`，并且未构建完成的索引不那么重要，考虑把索引删除，并观察 `__all_acquired_snapshot` 虚拟表中对应的条目是否被清除，如果该行没有删除，需要手动清理。 ## flashback 查看系统应保留的多版本数据范围。 ```sql show variables like 'undo_retention'; ``` 当 undo_retention 的值不为 0 时，即保存的多版本数据量很多时，可能导致 SSTable 没有办法即使回收。 可从 `__all_virtual_table` 表内通过 table_id 查看对应的 tenant_id，来判断是哪个租户造成的原因。 ## major freeze 频率过高 major freeze 会触发一次转储，将 major_freeze_ts 的数据转储下来，所以每次触发一次 major freeze 都会至少生成一个 Mini SSTable。 查看 `__all_virtual_freeze_info` 表里的 `frozen_scn` 和 `gmt_create`，查看其最新版本的 freezeInfo 和已经完成的合并版本之间有多长时间间隔，如果数值差很大，说明 major 发的版本太多了。 #### 注意 此处 `frozen_scn` 和 `gmt_create` 为 OceanBase 数据库 V4.x 版本字段，在 OceanBase 数据库 V3.x、V2.x 版本中，查看 `frozen_version` 和 `frozen_timestamp` 字段。 因为每次 major merge 都会做一次强制冻结，生成一个 Mini SSTable，当还没有执行完的 Major 版本太多，对应的 Mini SSTable 数量也很多，是有可能会撑爆 table_store 的。 ```sql select * from __all_virtual_freeze_info; ``` 返回结果如下： ```sql +-----------+---------------------+----------------------------+----------------------------+-----------------+------------------+ | tenant_id | frozen_scn | gmt_create | gmt_modified | cluster_version | schema_version | +-----------+---------------------+----------------------------+----------------------------+-----------------+------------------+ | 1 | 1 | 2024-06-05 13:49:12.078870 | 2024-06-05 13:49:12.078870 | 17180066048 | 1 | | 1 | 1717610400132386000 | 2024-06-06 02:00:00.133651 | 2024-06-06 02:00:00.133651 | 17180066048 | 1717570114480704 | | 1 | 1717696801538882000 | 2024-06-07 02:00:01.538882 | 2024-06-07 02:00:01.538882 | 17180066048 | 1717570114480704 | | 1 | 1717783202985673000 | 2024-06-08 02:00:02.986728 | 2024-06-08 02:00:02.986728 | 17180066048 | 1717570114480704 | | 1 | 1717869604457733000 | 2024-06-09 02:00:04.458788 | 2024-06-09 02:00:04.458788 | 17180066048 | 1717570114480704 | | 1 | 1717956001010178000 | 2024-06-10 02:00:01.011232 | 2024-06-10 02:00:01.011232 | 17180066048 | 1717570114480704 | | 1 | 1718042402607201000 | 2024-06-11 02:00:02.608258 | 2024-06-11 02:00:02.608258 | 17180066048 | 1717570114480704 | | 1 | 1718128804275101000 | 2024-06-12 02:00:04.276157 | 2024-06-12 02:00:04.276157 | 17180066048 | 1717570114480704 | | 1 | 1718215200978189000 | 2024-06-13 02:00:00.979244 | 2024-06-13 02:00:00.979244 | 17180066048 | 1717570114480704 | | 1 | 1718301602732413000 | 2024-06-14 02:00:02.733470 | 2024-06-14 02:00:02.733470 | 17180066048 | 1717570114480704 | | 1 | 1718388004845622000 | 2024-06-15 02:00:04.846637 | 2024-06-15 02:00:04.846637 | 17180066048 | 1717570114480704 | | 1 | 1718474401930974000 | 2024-06-16 02:00:01.930974 | 2024-06-16 02:00:01.930974 | 17180066048 | 1717570114480704 | | 1 | 1718560803949110000 | 2024-06-17 02:00:03.950144 | 2024-06-17 02:00:03.950144 | 17180066048 | 1717570114480704 | | 1 | 1718647200948448000 | 2024-06-18 02:00:00.948448 | 2024-06-18 02:00:00.948448 | 17180066048 | 1717570114480704 | | 1 | 1718733602970362000 | 2024-06-19 02:00:02.971419 | 2024-06-19 02:00:02.971419 | 17180066048 | 1717570114480704 | | 1 | 1718820004969300000 | 2024-06-20 02:00:04.970360 | 2024-06-20 02:00:04.970360 | 17180066048 | 1717570114480704 | | 1 | 1718906401977443000 | 2024-06-21 02:00:01.978505 | 2024-06-21 02:00:01.978505 | 17180066048 | 1717570114480704 | | 1 | 1718992803955278000 | 2024-06-22 02:00:03.955278 | 2024-06-22 02:00:03.955278 | 17180066048 | 1717570114480704 | | 1 | 1719079200986585000 | 2024-06-23 02:00:00.986585 | 2024-06-23 02:00:00.986585 | 17180066048 | 1717570114480704 | | 1 | 1719165603033233000 | 2024-06-24 02:00:03.034370 | 2024-06-24 02:00:03.034370 | 17180066048 | 1717570114480704 | | 1 | 1719252004998675000 | 2024-06-25 02:00:04.999732 | 2024-06-25 02:00:04.999732 | 17180066048 | 1717570114480704 | | 1 | 1719338401992292000 | 2024-06-26 02:00:01.993350 | 2024-06-26 02:00:01.993350 | 17180066048 | 1717570114480704 | | 1 | 1719424803950264000 | 2024-06-27 02:00:03.951319 | 2024-06-27 02:00:03.951319 | 17180066048 | 1717570114480704 | | 1 | 1719511200969679000 | 2024-06-28 02:00:00.970735 | 2024-06-28 02:00:00.970735 | 17180066048 | 1719476731674488 | | 1 | 1719597603002268000 | 2024-06-29 02:00:03.003309 | 2024-06-29 02:00:03.003309 | 17180066048 | 1719576915851784 | | 1 | 1719684004982246000 | 2024-06-30 02:00:04.982246 | 2024-06-30 02:00:04.982246 | 17180066048 | 1719576915851784 | | 1 | 1719770401955247000 | 2024-07-01 02:00:01.956260 | 2024-07-01 02:00:01.956260 | 17180066048 | 1719576915851784 | | 1 | 1719856803929271000 | 2024-07-02 02:00:03.930665 | 2024-07-02 02:00:03.930665 | 17180066048 | 1719576915851784 | | 1 | 1719943200822561000 | 2024-07-03 02:00:00.823621 | 2024-07-03 02:00:00.823621 | 17180066048 | 1719576915851784 | | 1001 | 1 | 2024-06-05 13:50:11.475648 | 2024-06-05 13:50:11.475648 | 17180066048 | 1 | | 1001 | 1717610400967659000 | 2024-06-06 02:00:00.969323 | 2024-06-06 02:00:00.969323 | 17180066048 | 1717568369659616 | | 1001 | 1717696802376634000 | 2024-06-07 02:00:02.378392 | 2024-06-07 02:00:02.378392 | 17180066048 | 1717568369659616 | | 1001 | 1717783203837991000 | 2024-06-08 02:00:03.839678 | 2024-06-08 02:00:03.839678 | 17180066048 | 1717568369659616 | | 1001 | 1717869600304776000 | 2024-06-09 02:00:00.306473 | 2024-06-09 02:00:00.306473 | 17180066048 | 1717568369659616 | | 1001 | 1717956001825403000 | 2024-06-10 02:00:01.827144 | 2024-06-10 02:00:01.827144 | 17180066048 | 1717568369659616 | | 1001 | 1718042403399241000 | 2024-06-11 02:00:03.400487 | 2024-06-11 02:00:03.400487 | 17180066048 | 1717568369659616 | | 1001 | 1718128805006702000 | 2024-06-12 02:00:05.008130 | 2024-06-12 02:00:05.008130 | 17180066048 | 1717568369659616 | | 1001 | 1718215201649018000 | 2024-06-13 02:00:01.651287 | 2024-06-13 02:00:01.651287 | 17180066048 | 1717568369659616 | | 1001 | 1718301603366465000 | 2024-06-14 02:00:03.367795 | 2024-06-14 02:00:03.367795 | 17180066048 | 1717568369659616 | | 1001 | 1718388000345697000 | 2024-06-15 02:00:00.347422 | 2024-06-15 02:00:00.347422 | 17180066048 | 1717568369659616 | | 1001 | 1718474402312032000 | 2024-06-16 02:00:02.313743 | 2024-06-16 02:00:02.313743 | 17180066048 | 1717568369659616 | | 1001 | 1718560804309704000 | 2024-06-17 02:00:04.311139 | 2024-06-17 02:00:04.311139 | 17180066048 | 1717568369659616 | | 1001 | 1718647201288714000 | 2024-06-18 02:00:01.290185 | 2024-06-18 02:00:01.290185 | 17180066048 | 1717568369659616 | | 1001 | 1718733603290595000 | 2024-06-19 02:00:03.292376 | 2024-06-19 02:00:03.292376 | 17180066048 | 1717568369659616 | | 1001 | 1718820000305052000 | 2024-06-20 02:00:00.307122 | 2024-06-20 02:00:00.307122 | 17180066048 | 1717568369659616 | | 1001 | 1718906402307570000 | 2024-06-21 02:00:02.309157 | 2024-06-21 02:00:02.309157 | 17180066048 | 1717568369659616 | | 1001 | 1718992804308613000 | 2024-06-22 02:00:04.309865 | 2024-06-22 02:00:04.309865 | 17180066048 | 1717568369659616 | | 1001 | 1719079201313265000 | 2024-06-23 02:00:01.316871 | 2024-06-23 02:00:01.316871 | 17180066048 | 1717568369659616 | | 1001 | 1719165603278911000 | 2024-06-24 02:00:03.281938 | 2024-06-24 02:00:03.281938 | 17180066048 | 1717568369659616 | | 1001 | 1719252000283497000 | 2024-06-25 02:00:00.285390 | 2024-06-25 02:00:00.285390 | 17180066048 | 1717568369659616 | | 1001 | 1719338402303132000 | 2024-06-26 02:00:02.304487 | 2024-06-26 02:00:02.304487 | 17180066048 | 1717568369659616 | | 1001 | 1719424804327862000 | 2024-06-27 02:00:04.329945 | 2024-06-27 02:00:04.329945 | 17180066048 | 1717568369659616 | | 1001 | 1719511201334979000 | 2024-06-28 02:00:01.337173 | 2024-06-28 02:00:01.337173 | 17180066048 | 1717568369659616 | | 1001 | 1719597603298952000 | 2024-06-29 02:00:03.300574 | 2024-06-29 02:00:03.300574 | 17180066048 | 1717568369659616 | | 1001 | 1719684000275202000 | 2024-06-30 02:00:00.278990 | 2024-06-30 02:00:00.278990 | 17180066048 | 1717568369659616 | | 1001 | 1719770402261126000 | 2024-07-01 02:00:02.262909 | 2024-07-01 02:00:02.262909 | 17180066048 | 1717568369659616 | | 1001 | 1719856804276891000 | 2024-07-02 02:00:04.278152 | 2024-07-02 02:00:04.278152 | 17180066048 | 1717568369659616 | | 1001 | 1719943201179214000 | 2024-07-03 02:00:01.180437 | 2024-07-03 02:00:01.180437 | 17180066048 | 1717568369659616 | +-----------+---------------------+----------------------------+----------------------------+-----------------+------------------+ ``` ## 写入压力过大，导致转储频繁把数组撑爆 可以通过 `__all_virtual_table_mgr` 看 table_store 中 sstable 的类型，Mini SSTable 数据比较多，且 table_size 都不为 0。可通过 **查询是否有正在运行中的 MINOR MERGE** 查看。 通过两种方式可以确认是否存在 minor compaction 跟不上转储速度的情况： - 内部表看 MINOR 的 DAG 是否存在堆积的情况。 ```sql select * from __all_virtual_dag_scheduler where tenant_id = xxx; ``` 返回结果如下： ![1](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/storage/troubleshooting-issues-with-too-many-sstables.png) - 通过 observer.log 的关键字查找日志。 ```shell grep "dump_dag_status" /home/admin/oceanbase/log/observer.log ``` 如果 MINOR DAG 数量比较多，建议先将 MINOR 线程数调大，可以改善这个情况。 - OceanBase 数据库 V4.x 版本可通过设置配置项 `compaction_mid_thread_score` 调整，默认值为 0 ，对应后台线程 6 个。 - OceanBase 数据库 V2.x、V3.x 版本可通过设置配置项 `minor_merge_concurrency` 调整，默认值为 0 ，对应后台线程 10 个。 ## gc_snapshot_version 推不上去，导致 table 无法回收 在日志文件中搜索 "too old"、"update info commit" 。 gc_snapshot 如果没有推高，会导致 `multi_version_start` 无法正常推高，SSTable 回收不了。 ## minor_compact_trigger 设置太大，导致 mini minor 执行不了 `minor_compact_trigger` 是指当最新 freeze_info 区间内的 Mini SSTable 数量超过该值的时候，会自动触发一次 Mini MINOR MERGE，将多个 Mini SSTable 合成一个。当 `minor_compact_trigger` 设置得过大时，会导致 mini minor 的触发不及时。 减少 Mini SSTable 的方式： - Mini MINOR MERGE：将最新 freeze_info 区间的多个 Mini SSTable 合成一个；（OceanBase 数据库 V3.1 版本后支持 History Mini Minor 可以将历史 freeze_info 区间的多个 Mini SSTable 合成一个） - Major Merge 回收 Mini SSTable。 在 Major Merge 之前会触发一次 remove_old_table 的回收操作，将不再需要的多版本数据进行回收。 ## 查询是否有正在运行中的 MINOR MERGE 如果有对应 partition 在执行 MINOR MERGE 的 trace，看一下开始运行的时间，是否运行时间很长，去对应机器上根据 Trace 看一下执行的情况，是否卡住。 如果运行正常，只能等待。 MINOR MERGE 耗时长，可能是因为参与 MINOR MERGE 的 sstable 数量太多，看一下这个 Trace 里面的 "init iter" 个数，有多少条日志表示有多少个SSTable 参加。 多少个 mini 触发一次 MINOR MERGE，默认为 2，如果这个值设置得过大，会导致触发 MINOR MERGE 的时间过晚，导入数据又很猛，导致 SSTable 数量不能及时降下去。 ```sql show parameters like "minor_compact_trigger"; ``` 上一篇 [KVCache 排查手册](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000800913) 下一篇 [tsar 命令不显示 traffic 流量指标问题的原因及解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001885319) ![有帮助](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) 咨询热线