宏块利用率低

问题现象

系统写入的数据不多，但是合并后使用宏块数量多。

关键诊断信息

事前巡检

检查 __all_virtual_meta_table 中 data_size 和 required_size 的比值，如果比值很低（比如低于 40%），说明宏块利用率低。

select
    d.tenant_name, c.database_name, b.table_name,
    sum(a.data_size)/1024/1024/1024 data_size_GB,
    sum(a.required_size)/1024/1024/1024 required_size_GB,
    sum(a.data_size)/sum(a.required_size) rate,
    sum(a.row_count) as rows,
    b.progressive_merge_num
from __all_virtual_meta_table a
join __all_virtual_table b on a.table_id = b.table_id
join __all_virtual_database c on b.database_id = c.database_id
join __all_tenant d on c.tenant_id = d.tenant_id
where role=1
group by c.database_name,  b.table_name, b.progressive_merge_num
order by required_size_GB desc limit 10;

事后诊断

对于宏块利用率比较低的表，修改其 progressive_merge_num 为 1，可以为该表所有分区发起一轮全量合并，全量合并完成后，再用上述 SQL 观察，利用率提升明显，则可以判定为本文档所述问题。全量合并的影响及风险参考本文档中 解决方法 这一节。

问题原因

在合并时，分区中老版本的 Major SSTable 的所有宏块，会和所有增量 mini/minor sstable 中的行进行合并。

• 若老版本 Major SSTable 中的宏块和增量的行有交集，则老版本 Major SSTable 中的宏块需要打开，按照微块或者行进行迭代。

• 若老版本 Major SSTable 中的宏块和增量的行没有交集，则宏块可以直接重用，省去 encoding 等步骤的耗时，以此缩短合并时间。

触发条件

若表的写入模式一直为递增写入，或者增量数据和老版本数据无交集，那么旧宏块会一直被重用，在新宏块利用率也不高的场景下，分区或者表的宏块利用率会越来越低。

问题的风险及影响

存储空间利用率低。

影响租户

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

影响版本

OceanBase 数据库企业版 V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.2 GA（oceanbase-3.2.2-20211130225726）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本。

解决方法

• 升级至问题已修复版本。OceanBase 数据库企业版 V3.2.4 BP5 Hotfix1（oceanbase-3.2.4.5-105010012023090116）、V3.2.4 BP5 Hotfix2（oceanbase-3.2.4.5-105020052023092709）、V3.2.4 BP5 Hotfix3（oceanbase-3.2.4.5-105030012023103122）、V3.2.4 BP5 Hotfix4（oceanbase-3.2.4.5-105040022023111323）、V3.2.4 BP5 Hotfix5（oceanbase-3.2.4.5-105050022023120510）、V3.2.4 BP5 Hotfix6（oceanbase-3.2.4.5-105060012023121115）、V3.2.4 BP5 Hotfix7（oceanbase-3.2.4.5-105070012024010214）、V3.2.4 BP5 Hotfix8（oceanbase-3.2.4.5-105080012024052018）、V3.2.4 BP5 Hotfix9（oceanbase-3.2.4.5-105090022024061012）、V3.2.4 BP5 Hotfix10（oceanbase-3.2.4.5-105100032024072515）、V3.2.4 BP5 Hotfix11（oceanbase-3.2.4.5-105110022024103122）、V3.2.4 BP5 Hotfix12（oceanbase-3.2.4.5-105120022025030712）、V3.2.4 BP5 Hotfix13（oceanbase-3.2.4.5-105130022025032811）、V3.2.4 BP5 Hotfix14（oceanbase-3.2.4.5-105140012025062619）、V3.2.4 BP5 Hotfix15（oceanbase-3.2.4.5-105150012025081820）、V3.2.4 BP5 Hotfix16（oceanbase-3.2.4.5-105160032025091816）、V3.2.4 BP5 Hotfix17（oceanbase-3.2.4.5-105170082025100222）、V3.2.4 BP5 Hotfix18（oceanbase-3.2.4.5-105180012025111714）、V3.2.4 BP5 Hotfix19（oceanbase-3.2.4.5-105190012025120220）。

• 修改其 schema 中 progressve_merge_num 字段为 1，可以为该表所有分区发起一轮全量合并。

  • 对表发起全量合并存在以下可能的影响和风险（旧版本 Major SSTable 的所有宏块都会打开重写）。

    注意

    1. 合并期间需要更多的存储空间。
    2. 会消耗更多的 CPU 资源，合并耗时会变长。
    3. 当全量合并结束后，记得将 progressve_merge_num 修改回原值。