合并慢怎么确定是否合理？

适用版本

OceanBase 数据库所有版本

合并还未结束

按照合并超时的排查思路进行排查。

合并已经结束

V3.2 之前的版本

1. 通过 SQL 查询指定 Major 版本的合并信息统计，找到合并耗时最多的几个 Partition 来具体分析。

   SELECT /*+ query_timeout(10000000)*/* FROM __all_virtual_partition_sstable_merge_info where merge_type = "major merge" and version = "version-0-0" order by merge_cost_time desc limit 5;
   

   其中，version 有三个字段，第一个非 0 字段是 merge_version，查询时需要替换成本次合并的 merge_version，后两个字段保持为 0 即可。

   通过 __all_zone 表可以查到本次合并的 merge_version。

2. 查看宏块重用情况。

   通过虚拟表 __all_virtual_partition_sstable_merge_info 中 occupy_size/macro_block_count/use_old_macro_block_count/rewrite_macro_old_micro_block_count/rewrite_macro_total_micro_block_count 等字段，分别表示该 Partition 的数据量/宏块数/重用宏块数/重用宏块中重写的微块数 如果重用宏块数量/总宏块数的比率非常低 -> 新导入表的第一次合并或随机写严重，导致发生了全量合并，合并会变慢。

3. 查看合并开始时间是否合理。

   select * from __all_virtual_partition_sstable_merge_info where table_id = xxx and partition_id = xxx and svr_ip = "xxx" order by merge_finish_time desc limit 10; 
   

   找到合并开始最晚的几个 partition，在该时间段的 observer.log 中搜索其 compaction 记录。

   grep "sstable merge finish.* table_id.* partition_id" observer.log.20211117* | vi -
   

   如果有报错:

   • V3.x 之前的版本，报错 -4288(constexpr int OB_MEMTABLE_CANNOT_MINOR_MERGE = -4288;)，表示 MEMTable 上有未决事务导致转储失败，可以继续排查未决事务问题。
   • 其他报错可以继续排查存储问题。

V3.2 及之后的版本

V3.2 版本后支持自动排查，可以查询虚拟表 __all_virtual_compaction_suggestion。

为什么全量合并会较慢？

合并会将有修改的数据宏块打开重写（速度慢），没有修改的数据宏块则直接重用（将老的数据宏块直接刷盘，速度快） 全量合并，即所有的宏块都打开重写，所以速度会较慢。