OBServer V4.1.0 BP1 之前版本升级到 V4.2.2 版本，执行 DDL 卡住

关键诊断信息

事前巡检

经停 OceanBase 数据库 V4.1.0 (oceanbase-4.1.0.0-100000982023031415) 版本或者 OceanBase 数据库 V4.1.0 (oceanbase-4.1.0.0-100001122023040322) 版本, 最终升级到 OceanBase 数据库 V4.2.2 GA (oceanbase-4.2.2.0-100000082024011317) 版本或者 OceanBase 数据库 V4.3.0 RC1 版本。

事后诊断

执行DDL 卡住， RS 报错。

ERROR refresh_schema (ob_ddl_service.cpp:27207) [918][DDLQueueTh0][T0][xxxxx-xxxxx-xxxxx-xxxxx] [lt=16][errcode=-5410] Refresh schema failed continuously, ddl may be hung(msg="refresh schema failed", ret=-5008, ret="OB_ERR_COLUMN_DUPLICATE", refresh_count=2529844)

查看具体的报错日志，出问题的 table_id 为 21354，对应的内部表为 V$OB_TRANSACTION_SCHEDULERS 。

这里报错是因为 V$OB_TRANSACTION_SCHEDULERS 的 __all_column_history 列信息不一致导致刷新 schema 失败，引起后续 DDL 执行卡住。

问题现象

系统视图升级过程(重建)

OBServer 集群从低版本升级到高版本后，系统视图定义可能发生变化，包括：增删列，修改列类型，增加列最大长度等等。其中增删列是用户视图所不允许的。 升级过程中，升级脚本检测到系统视图定义发生变化后，会做一个修正的动作，比如从 V4.1 first 版本升级到 V4.2.1 版本，系统视图 GV$OB_TRANSACTION_SCHEDULERS 删除了 XA_TX_ID 列，这个时候升级脚本检测到这个视图定义发生变化，就会将原有的低版本的 GV$OB_TRANSACTION_SCHEDULERS drop 掉，并根据新版本定义重建一张 GV$OB_TRANSACTION_SCHEDULERS，维持原有的 table_id 不变。

视图的重编译

除了上述明确修改了定义的视图会在升级中发生重建之外，还有一些隐式修改了的系统视图定义也发生了变化，如上面描述的 GV$OB_TRANSACTION_SCHEDULERS，和其相关联的视图还有 V$OB_TRANSACTION_SCHEDULERS，它的具体定义为：

SELECT *
 FROM OCEANBASE.GV$OB_TRANSACTION_SCHEDULERS
 WHERE SVR_IP = HOST_IP() AND SVR_PORT = RPC_PORT()

可以看到，它的所有信息均来自于 GV$OB_TRANSACTION_SCHEDULERS，所以事实上它也删除了 XA_TX_ID，但由于它的视图定义未发生变化，所以升级脚本无法检测到这个视图需要重建。这种情况下，OceanBase 数据库依赖于视图重编译流程进行元信息的纠正。重编译发生在升级结束后，当我们第一次访问此视图时（访问包括查询此视图，desc 此视图以及查询 information_schema.columns 视图并浏览到此视图），系统检测到此视图发生了变化，会对其按照新的定义进行重编译，以此纠正它的元信息。

问题背景

本问题发生的需要以下几个条件：

1. 系统升级前的版本相较于升级的最终版本，有系统视图发生了删列操作（目前明确的删列版本是 OceanBase 数据库 V4.1.0 BP1（oceanbase-4.1.0.0-100000982023031415）版本，即部署于 V4.1 BP1（oceanbase-4.1.0.0-100000982023031415）之前的版本）。

2. 系统升级到的版本为 OceanBase 数据库 V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）版本或者 V4.3.0（oceanbase-4.3.0.0-100000072024020200）版本（升级到 V4.2.1 所有 BP 版本不会遇到此问题）。

3. 升级过程已经结束（此时重编译会随着内部或者用户访问 information_schema.columns/内部或者用户访问 V$OB_TRANSACTION_SCHEDULERS 视图发起）。

当满足上述条件，V$OB_TRANSACTION_SCHEDULERS 重编译会失败，导致 schema 状态不一致，DDL hung 住。

问题原因

1. 视图删列是系统视图在升级过程中特有的行为，重编译设计上并不支持删列操作。

2. 系统视图没有依赖关系，导致一系列使用 select * from GV$ 定义的 V$ 视图无法感知到 GV$ 发生了定义的变化，无法通过升级脚本重建视图来纠正定义。

3. OceanBase 数据库 V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）版本可以容忍 V$ 视图和 GV$ 视图定义不一致，不会有实际影响，但 V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）版本为保证视图列 comment 在重编译前后一致，所以对 V$ 进行了纠正。

4. 使用 select * 定义系统视图不严谨，Oracle 所有 V$ 视图都明确了 select item 的名称，不会使用 select * 来定义视图。

问题的风险及影响

影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户。另外对用户操作的影响是 DDL 会卡。

影响的版本

OceanBase 数据库 V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）版本。

解决方法及规避方式

• 解决方法:

  需要手动修正内部表才能恢复。

  警告

  禁止自行手动对内部表的任何修正操作，请联系 OceanBase 技术支持人员。

• 规避方式：

  避免从 OceanBase 数据库 V4.1.0（oceanbase-4.1.0.0-100000982023031415）版本或者 OceanBase 数据库 V4.1.0（oceanbase-4.1.0.0-100001122023040322）版本升级到 OceanBase 数据库 V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）版本。