合并长时间未完成

[AntTech_JEGOO6]

【 使用环境 】生产环境
【 OB or 其他组件 】ob 4.3.5.0
【问题描述】
1、ocp上报错：转储卡合并

2、把集群重启后，合并一直无法完成

【其它信息】

[淇铭]

OceanBase 社区已接收您的帖子，正在跟进中。

[Giant]

–正在合并的tablet 表级别
select * from gV$OB_TABLET_COMPACTION_PROGRESS;
select * from GV$OB_TABLET_COMPACTION_HISTORY order by start_time desc;
select table_name,tablet_id from __all_table; --查看表名和tablet_id的关系，确定问题表
select table_name,tablet_id from DBA_OB_TABLE_LOCATIONS; --查看表名和tablet_id的关系，确定问题表
这些表您也看下 特别是 租户 1006的 创建时间是 1月16号的

[靖顺]

用敏捷诊断工具obdiag 分析一下卡合并的根因：https://www.oceanbase.com/docs/common-obdiag-cn-1000000002023114

[AntTech_JEGOO6]

[AntTech_PLSNIV]

用敏捷诊断工具obdiag 分析一下卡合并的根因：https://www.oceanbase.com/docs/common-obdiag-cn-1000000002023114

[靖顺]

从obdiag 根因分析的结果看起来是1006租户合并出了问题

把详细结果的文件发出来，./obdiag_rca/obdiag_major_hold_20250120135728/这个文件夹打包发出来。

[AntTech_JEGOO6]

obdiag_major_hold_20250120135728.zip (3.3 KB)

[AntTech_BPETNU]

对于比较重要的业务，合并时间触发后规定时间内完成不了，有没有什么好的方式呢，金融业务。虽然是产品特性，但是合并时间太久了，有什么方式能大大缩短或者到达合并设定时间就不在合并么？

[淇铭]

问题分析

1、select * from __all_virtual_sys_task_status limit 10查询任务

节点xx.xx.xx.xx:2882，租户1006正在执行列存合并任务

2、查询正在合并的tablet 2230623近期的ddl操作，有做过异步行转列的操作，alter table xx add column group (each column) delayed;

3、通过日志查看

查询tablet 2230623对应的合并日志，发现storage schema的有一列single cg的column group信息写错，single cg应该只有一列信息，但是写成了全列信息，怀疑异步行转列之后读取的table schema有问题

4、查询tablet 2230623对应table 4381715的column group系统表数据

select * from __all_virtual_column_group_history where table_id = 4381715 and tenant_id = 1006；
select * from __all_virtual_column_group_mapping_history where table_id = 4381715 and tenant_id = 1006；

mapping表里面column group id为1012的记录包含了新旧版本的column group数据，旧版本的是all column group数据，新版本的是single column group数据，异步行转列加的多版本读逻辑处理这种情况时会把旧版本数据也读上来

5、出现该问题的表table schema读错，合并已经按照错误的schema生成medium info做合并，只能创建新表重建数据。但是由于table schema有问题，读取/删表的时候会触发防御逻辑报4016

该问题产生的原因：

旧版本表做ddl之后变成带有all columns的行存表，此时系统表__all_column_group_history和__all_column_group_mappinghistory中存在旧all columns的数据，并且可能做过多轮ddl，旧all columns的column group id会比较高，影响升级后异步行转列读取系统表的正确性

后续该问题修复之前，如果数据表是带有all columns的行存表，先不要执行异步行转列操作，先用offline ddl修改column group

该问题解决办法：

确定长时间合并未完成的tablet，select * from __all_virtual_sys_task_status where tenant_id = 1006 and task_type = ‘SSTABLE_MAJOR_MERGE’ limit 10;，确认列表中每个tablet对应的表是否是问题表，如果是问题表，执行以下操作

1. 直连sys租户 alter system change tenant tenant_id = 1006; 修改租户为问题租户
2. select effective_tenant_id(); 确认是问题租户
3. select table_name from __all_table where tenant_id = 0 and table_id = 4381844; 确认是问题表
4. select * from __all_column_group_history where table_id = 4381844 and schema_version = 1733824795526464 and COLUMN_GROUP_NAME = ‘__co_all’;从系统表中找到旧版本all_cg对应的schema_version，确认查出1行数据, is_delete是0
5. select * from __all_column_group_mapping_history where table_id = 4381844 and schema_version = 1733824795526464 and COLUMN_GROUP_ID = 1026; 根据查出的旧版本all_cg对应的schema_version和column_group_id查询，确认查出的数据行数和表列数一致, is_delete是0
6. update __all_column_group_history set IS_DELETED = 1 where table_id = 4381844 and schema_version = 1733824795526464 and COLUMN_GROUP_NAME = ‘__co_all’;
7. update __all_column_group_mapping_history set IS_DELETED = 1 where table_id = 4381844 and schema_version = 1733824795526464 and COLUMN_GROUP_ID = 1026;
8. 直连rs sys租户 alter system flush kvcache cache=‘schema_cache’; 之后原表可以读取（该操作可能影响业务性能, 最好在业务低峰操作）
9. 创建新表，把原表数据导入新表
10. 删除原表

[bull020]

mark