--- title: compaction_diagnose 视图使用指南-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于compaction_diagnose 视图使用指南相关的常见问题和使用技巧，帮助您快速解决compaction_diagnose 视图使用指南的难题。 --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 划线反馈 # compaction_diagnose 视图使用指南 更新时间：2026-06-15 09:16 适用版本： V3.2.x、V4.0.x、V4.1.x、V4.2.x 内容类型：TechNote 本文主要介绍 compaction 合并中诊断视图的使用。 ## 适用版本 OceanBase 数据库 V3.2 及以后的版本。 ## 合并诊断视图 在 Compaction 出现异常的情况下，OBServer 会收集相关信息用于原因诊断。 用法： V3.x 版本 V4.x 版本 ``` ``` select * from __all_virtual_compaction_diagnose_info; ``` ``` ``` ``` select * from GV$OB_COMPACTION_DIAGNOSE_INFO; ``` ``` 通过 `STATUS` 来过滤信息的严重程度，从低到高： - `SPECIAL`：用来输出一些相同问题的 tablet 数量。 - `RS_UNCOMPACTED`：不一定存在异常。说明还存在 tablet 版本尚未推高至当前合并版本号，可以先通过 `GV$OB_COMPACTION_PROGRESS` 判断是否处于正常合并进行的状态。如果还有 `RUNNING` 的合并，则大概率是合并任务的问题。 - `NOT_SCHEDULE`：表示 compaction 长时间未被调度。比较常见的是出现在 follower 上，由于 medium info 的同步落后导致的合并未调度；以及由于 DAG 数量超限导致的 MINI 未调度。 - `FAILED`： 表示出现一些明显的异常。 主要通过 `DIAGNOSE_INFO` 字段的信息来定位问题，该字段可能包含以下信息。 - major or medium may be suspended - 原因： `could_major_merge = false`，暂停了 major; `could_schedule_medium = false`，暂停了 medium。 - 解决方式：首先看下 `CDB_OB_MAJOR_COMPACTION`，确认是否有 `IS_SUSPENDED` 状态的记录，如果有，那么说明执行过暂停合并的操作`ALTER SYSTEM SUSPEND MERGE;`，需要手动恢复合并 `ALTER SYSTEM RESUME MERGE;`。如果没有，联系技术支持人员协助排查（存储模块）。 - schedule medium failed - 原因：具体原因看信息中的 error_code。 - 解决方式：查看 observer 日志，过滤 `decide_medium_snapshot` 或信息中的 error_code 关键字，找到报错的上下文。 - error_no=xxx ... error_trace=xxx ... - 原因：存在 DAG 任务失败。 - 解决方式：查看信息是否可以定位根因，如果不能则在日志中查找 error_trace，找到报错的上下文。 - refresh ls locality cache failed - 原因：ls locality cache 刷新失败，信息中会包含错误码。 - 问题：可能导致合并的一些校验失败。 - 排查手段：在 observer 日志里搜 `refresh ls locality` 关键字找到 trace，再搜索 trace_id 查看上下文。如果 WARN 日志不是近段时间的，大概率已经恢复正常。（由于该信息在合并结束后清理，因此会滞留一段时间） - weak read ts is not ready - 原因：备机读时间戳未推过 major 合并位点。 - 可能导致的结果：合并超时。 - 解决方式：联系技术支持人员协助排查（事务模块）。 - memtable can not minor merge - 原因：MEMTable 未达到转储条件。 - 可能导致的结果：Mini Compaction 慢、clog 回收慢、内存爆。 - 解决方式：联系技术支持人员协助排查（事务模块）。 - memtable rec_scn/rec_log_ts not stable - 原因：日志流冻结过程中连续最大回调(放)点长时间没有推过对应 tablet 的 MEMTable 的 rec_log_ts。 - 更深层次的原因是回调(放)慢。 - 解决方式：联系技术支持人员协助排查（事务模块）。 - memtable not ready for flush - 原因：日志流冻结过程中有 MEMTable 长时间没有达到转储条件。 - 可能导致的结果：转储超时/内存爆。 - 解决方式：联系技术支持人员协助排查（事务模块）。 - memtable can not create dag successfully - 原因：MEMTable 达到转储条件后，长时间没有成功发起转储任务。 - 解决方式：联系技术支持人员协助排查（事务模块）。 - traverse_trans_to_submit_redo_log failed - 原因：提交 redo log 失败解决方式：联系技术支持人员协助排查（事务模块）。 - sstable count is not safe - 原因：SSTable 数量过多，导致无法做 Mini compaction。 - 可能导致的结果：无法做 Mini Compaction、clog 回收慢、内存爆。 `diagnose_info` 还会展示导致 SSTable 数量过多的原因： ``` * SNAPSHOT_FOR_MAJOR：Major compaction * SNAPSHOT_FOR_DDL：表的 DDL 例如建索引 * SNAPSHOT_FOR_MULTI_VERSION：多版本数据过多，undo_retention 过大 * SNAPSHOT_FOR_RESTORE_POINT：restore_point * SNAPSHOT_FOR_BACKUP_POINT：备份相关 ``` - dag may hang - dag 一段时间未更新，可能卡住，如果超过 10min 一直保持这个状态，联系技术支持。 - freeze_info is invalid - 原因：获取 freeze_info 失败。 - 可能导致的结果：合并超时。 - 解决方式：联系技术支持人员协助排查（存储模块）。 - can't schedule minor merge - 原因：mini sstable 数量过多但依然没有成功调度 minor merge。 - 根因有多种，需要进一步定位。 - 解决方式：联系技术支持人员协助排查（存储模块）。 - need major merge but can't merge now - 原因：tablet 的 snapshot 小于合并版本，需要等新的转储。 - merge has been paused - 原因：合并被暂停了。 - 解决方式：`ALTER SYSTEM RESUME MERGE;` 恢复合并。 - medium wait for freeze，xxx（major wait for freeze，xxx） - 原因：该机器的 medium/major 超过 interval 时间还在等待冻结/转储。其中 `compaction_scn` 为此次合并的 scn，`tablet_snapshot` 为 tablet 的 snapshot_version。通常这种情况下`compaction_scn`>`tablet_snapshot`，即该分区还没有做一次转储来使得 `tablet_snapshot` 推过 `compaction_scn`（这是合并调度的前置条件）。一般有三种情况： - 转储任务存在，在等待调度执行。 - 转储一直发起失败。 - 转储一直执行失败。 - 解决方法：对于情况 1，查询 `__all_virtual_dag` 查看是否有对应的转储 DAG 存在，对于情况 2/3，通常诊断表里会有信息。等待转储没有很好的方法论，难以排查的话请转交存储同学排查。 - major not schedule for long time，xxx - 原因：该机器的 major 超过 interval 时间还没有调度。其中 `max_receive_medium_snapshot` 表示该分区在该机器收到的最大的 compaction_scn，`compaction_scn` 表示此次合并的 scn。通常这种情况下`max_receive_medium_snapshot`<`compaction_scn`，即该分区还没有被调度，一般有两种情况： - `max_receive_medium_snapshot` 版本的合并仍然有副本未完成。 - `max_receive_medium_snapshot` 合并已完成，但新的调度暂未发起。 - 解决方法：对应情况 1，查询 `__all_virtual_dag` 查看是否有对应的合并 DAG 存在，如果是合并任务执行失败通常诊断表里会有相关信息；对于情况 2，在日志里查找 `MediumLoo` 关键字，找到合并调度的线程，然后查找调度线程的线程号（如"[xxxxx]")，看是否有 WDIAG 的异常。合并未调度没有很好的方法论，难以排查的话请转交存储同学排查。 - maybe bad case: locality change and leader change - 原因：遇上 locality 变更且切主的 bad case。比如增加 locality，而日志流 Leader 被切到新增 Zone 上。 - 解决方式：中断 locality 变更。 - 如何确认该场景： - 首先查询 `select * from __all_tenant where tenant_id = xxx;`，查看 `previous_locality` 字段是否为空，如果不为空，那么说明正在进行 `previous_locality`->`locality` 变更的过程。 - 然后查询 `select * from CDB_OB_LS_LOCATIONS where tenant_id = xx and ls_id = xx`，查看 leader 是否是 locality 变更中新增的 zone。如果是，则遇到 locality 变更，且日志流 leader 被切到新增 zone 的 bad case。 - compaction has finished in storage - 原因：存储层合并结束但 RS 后续处理未完成后续操作。 - `GV$OB_COMPACTION_PROGRESS` 确定合并是否已经是 FINISH 状态。 - there is too many tablets. tablet count xxx - 原因：非异常。诊断时需要遍历的分区过多，跳过了该 ls 的诊断。 - 其他 - 如果 `status` 字段为 `RS_UNCOMPACTED`，说明还存在 tablet 版本尚未推高至当前合并版本号，需要联系技术支持进一步排查是否卡合并。 上一篇 [常见的 OceanBase 数据库 compaction 参数](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000209915) 下一篇 [如何修改 OceanBase 数据库的合并方式](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000001021) ![有帮助](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) 咨询热线