OMS 4.3.2 Oracle 迁移至 OB MySQL 模式时 unique 索引异常转换

问题现象

在使用 OMS 4.3.2 进行 Oracle 数据库到 OceanBase MySQL 模式租户的数据迁移时，于结构迁移阶段发现索引定义转换异常。

触发场景

2026 年 3 月 5 日，客户在测试环境验证结构迁移结果时发现问题。具体操作步骤如下：

1. 在 OMS 4.3.2 控制台创建 Oracle 到 OceanBase MySQL 模式的迁移链路。
2. 配置源端为 Oracle 19c，目标端为 OceanBase MySQL 模式租户。
3. 启动结构迁移，等待 OMS 完成表结构同步。
4. 在目标端 OceanBase MySQL 租户中执行 SHOW CREATE TABLE 语句，检查迁移后的索引定义。
5. 发现带有 DESC 的索引（包括普通索引和唯一索引）字段格式异常，而不带 DESC 的普通索引正常。

问题原因

该问题的根因在于 OMS 4.3.2 在将 Oracle 源端索引迁移至 OceanBase MySQL 模式租户时，对带有 DESC 的索引及唯一索引的语法转换存在缺陷：

1. Oracle 列名的双引号未能正确映射为 MySQL 的反引号，导致目标端索引字段被错误解析为嵌套括号格式 ((COLUMN) ASC)。
2. OMS 在结构迁移过程中会强制将 DESC 改为 ASC，即使 OceanBase MySQL 模式在语法层面支持 DESC 索引创建。
3. 唯一索引还存在独立的双引号转换异常问题，即使去掉 DESC 后仍可能出现括号包裹的异常格式。

这些因素叠加导致目标端索引定义不标准，存在兼容性风险。需在 OMS 4.3.2 bp1 修复前通过手动删除并重建索引进行规避。

关键信息

源端 Oracle 的测试表结构如下：

CREATE TABLE "TEST"."OB_TEST_TEMP20260305" (
   "TXNSERIALNO" VARCHAR2(16) NOT NULL,
   "DATAID"      VARCHAR2(50) NOT NULL,
   "SENDDATE"    TIMESTAMP(6),
   "TRANDENO"    VARCHAR2(10),
   "STATE"       VARCHAR2(1),
   "MEMO"        VARCHAR2(1000),
   "RECONTENT"   VARCHAR2(50),
   "CONTENT"     BLOB,
   "ORGNO"       VARCHAR2(10),
   "SEQNO"       VARCHAR2(20),
   "CORPNO"      VARCHAR2(10),
   CONSTRAINT "TP_RECCREDITEBANKDATA_PK_TMP" PRIMARY KEY ("DATAID")
);

-- 普通索引，无 DESC（目标端正常）
CREATE INDEX "TEST"."TP_RECCREDITEBANKDATA_INDEX1_TMP2"
   ON "TEST"."OB_TEST_TEMP20260305" ("STATE");

-- 普通索引，带 DESC（目标端异常）
CREATE INDEX "TEST"."TP_RECCREDITEBANKDATA_INDEX1_TMP3"
   ON "TEST"."OB_TEST_TEMP20260305" ("RECONTENT" DESC);

-- unique 索引，带 DESC（目标端异常）
CREATE UNIQUE INDEX "TEST"."TP_RECCREDITEBANKDATA_INDEX1_TMP"
   ON "TEST"."OB_TEST_TEMP20260305" ("TXNSERIALNO" DESC);

1. 带 DESC 的索引（普通索引和唯一索引）字段双引号均被错误转换为双层圆括号

源端 Oracle 带 DESC 的普通索引定义：

CREATE INDEX "TEST"."TP_RECCREDITEBANKDATA_INDEX1_TMP3"
   ON "TEST"."OB_TEST_TEMP20260305" ("RECONTENT" DESC);

源端 Oracle 带 DESC 的唯一索引定义：

CREATE UNIQUE INDEX "TEST"."TP_RECCREDITEBANKDATA_INDEX1_TMP"
   ON "TEST"."OB_TEST_TEMP20260305" ("TXNSERIALNO" DESC);

结构迁移完成后，在目标端 OceanBase MySQL 租户中执行 SHOW CREATE TABLE OB_TEST_TEMP20260305，上述两个带 DESC 的索引字段部分均被转换为异常格式：

-- 普通索引（带 DESC）迁移后异常
INDEX `TP_RECCREDITEBANKDATA_INDEX1_TMP3` ((`RECONTENT`) ASC)

-- unique 索引（带 DESC）迁移后异常
UNIQUE INDEX `TP_RECCREDITEBANKDATA_INDEX1_TMP` ((`TXNSERIALNO`) ASC)

即 Oracle 的双引号 "RECONTENT"、"TXNSERIALNO" 没有被正常映射为 MySQL 的反引号 `RECONTENT`、`TXNSERIALNO`，而是变成了 ((RECONTENT) ASC) 和 ((TXNSERIALNO) ASC) 这种嵌套括号包裹的异常格式。该异常格式虽能成功创建索引，但属于不标准的索引定义，存在潜在兼容性风险。

2. 不带 DESC 的普通索引迁移正常

源端不带 DESC 的普通索引：

CREATE INDEX "TEST"."TP_RECCREDITEBANKDATA_INDEX1_TMP2"
   ON "TEST"."OB_TEST_TEMP20260305" ("STATE" ASC);

目标端迁移后正常：

INDEX `TP_RECCREDITEBANKDATA_INDEX1_TMP2` (`STATE` ASC)

说明不带 DESC 的普通索引双引号可正常转换为反引号，格式正确。

3. DESC 降序排序被强制省略并改为 ASC

源端带 DESC 的索引明确声明为降序：

CREATE INDEX ... ON ... ("RECONTENT" DESC);
CREATE UNIQUE INDEX ... ON ... ("TXNSERIALNO" DESC);

迁移到目标端后，DESC 被强制改为 ASC：

((`RECONTENT`) ASC)
((`TXNSERIALNO`) ASC)

客户特别指出：OceanBase MySQL 模式租户（尤其是 OceanBase 4.2.5.7）在语法层面支持 DESC 索引创建，但 OMS 迁移时仍将 DESC 去掉了。

注意：OceanBase 4.2.5 版本仅是可以创建 DESC 索引语法，但是实际不生效，本质上还是 ASC 索引。

4. 唯一索引即使去掉 DESC，仍可能存在双引号转换异常

客户进一步验证：将源端唯一索引的 DESC 去掉（改为默认 ASC）后，OMS 迁移后仍然会出现双引号被转为 () 的问题。该现象已被工程师确认并记录，说明唯一索引的双引号转换异常与 DESC 是两个独立但叠加的问题。

问题的风险及影响

• 兼容性风险：迁移后生成的异常索引格式 ((column) ASC) 不符合标准 MySQL 索引语法，可能影响后续的 DDL 操作（如索引重建、表结构变更）或与某些数据库工具的兼容性。
• 功能缺失：源端明确指定的降序索引（DESC）在迁移后被强制改为升序（ASC），可能导致依赖于特定排序顺序的查询性能或结果出现偏差。
• 维护复杂性：需要人工介入检查和修正异常的索引定义，增加了迁移后的运维负担。

适用版本

OMS 4.3.2 版本。

解决方法

在 OMS 4.3.2 bp1 发布前，建议采用以下手动修正方案。

步骤 1：结构迁移完成后，检查目标端索引定义

在目标端 OceanBase MySQL 租户中执行以下命令，检查表结构定义：

SHOW CREATE TABLE <table_name>;

步骤 2：如发现异常格式 ((字段) ASC)，先删除异常索引

DROP INDEX <index_name> ON <table_name>;

步骤 3：按正确语法重建索引

• 普通索引重建：

  CREATE INDEX <index_name> ON <table_name> (`column_name`);
  

• 唯一索引重建：

  CREATE UNIQUE INDEX <index_name> ON <table_name> (`column_name`);
  

注意：OceanBase MySQL 模式虽支持 DESC 语法，但实际底层为 ASC。如业务确实需要 DESC 语义，需在应用层或 SQL 中通过 ORDER BY ... DESC 补偿。

步骤 4：验证索引创建结果

SHOW INDEX FROM <table_name>;

确认 Column_name 为正常反引号格式，无嵌套括号。

规避方式

升级 OMS 4.3.2 bp1 及以上。