OceanBase 数据库 V4.3.5 BP0 版本在物理恢复时失败报错 -4002 的排查与解决（超宽表场景）

问题现象

在 OceanBase 数据库 V4.3.5 BP0 版本上执行物理恢复操作，恢复过程中报错 -4002，有一个分区物理恢复失败，对应日志如下.

/data/local_nfs/yanfeng/ob2.z1.obs0/log/observer.log.20250707153142867:
[2025-07-07 15:31:21.677311] WDIAG [STORAGE] process (ob_storage_ha_macro_block_writer.cpp:207) ...
[errcode=-4002] failed to append macro row(ret=-4002, read_data.macro_meta_={val:{version:2,...}})

经排查，报错表为一张超宽表。表面错误信息为恢复过程中尝试拷贝一个非数据宏块（中间层索引宏块），而该宏块的 version=0，不满足 OBServer 写入数据宏块时 version=1 的前置条件，最终触发 -4002 错误。

关键诊断信息

• OBServer 报错堆栈：failed to append macro row，错误码 -4002。

• 报错表为一张 schema 较为复杂的超宽表。

• 日志中宏块信息显示 macro_meta_.version = 0。

• 仅该表恢复失败，其它表恢复正常。

• 恢复版本为 OceanBase 数据库 V4.3.5 BP0 版本。

问题原因

该问题是 OceanBase 数据库 V4.3.5 BP0 版本中的一个已知缺陷，属于实现层面的问题： 中间层二级 Meta 迭代器 错误地暴露了中间层索引宏块，导致这些非数据宏块被错误地纳入恢复写入流程。而中间层索引宏块的 version = 0，在写入流程中无法满足 version = 1 的校验逻辑，最终导致恢复失败并报错 -4002。

该问题已在 4.3.5 BP1 中修复。

问题的风险及影响

• 风险级别：中高。

• 恢复过程可能失败，影响数据完整性。

• 对业务影响取决于该表在业务系统中的重要性。

• 仅在存在超宽表的场景中触发，具备一定触发条件限制。

影响租户

影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。

影响版本

OceanBase 数据库企业版 V4.3.5 GA（oceanbase-4.3.5.0-100000122024123020）及之后版本。

解决方法

对于已经在 OceanBase 数据库 V4.3.5 BP0 版本上遇到该问题的用户，可采用以下应急处理方案：

1. 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.3.5 BP1（oceanbase-4.3.5.1-101000292025030623）或更高版本。

2. 在升级后重新执行物理恢复操作。

3. 若无法升级，请联系 OceanBase 技术支持团队，提供相关表 schema 和报错日志。

规避方式

为避免再次触发该问题，建议用户采取以下规避策略：

• 尽量避免在 OceanBase 数据库 V4.3.5 BP0 版本上进行涉及超宽表的物理备份恢复操作。

• 在恢复前评估目标表是否为复杂超宽表，如是，建议升级至 V4.3.5 BP1 版本或更高版本。

• 运维层面可纳入超宽表识别及版本评估的恢复检查流程中。