DB2 LUW迁移Aurora PostgreSQL：DMS 3.5.3/3.5.4数据验证失败

通过AWS SCT和DMS将本地DB2 LUW迁移至AWS Aurora PostgreSQL，数据加载已成功完成，但出现版本差异问题：

• DMS复制实例3.5.2版本：数据验证可正常完成
• DMS复制实例3.5.3/3.5.4版本：尽管已在目标表创建唯一索引，数据验证仍未执行

目标表与唯一索引定义如下：

CREATE TABLE xyz (
  xxx CHARACTER VARYING(22) NOT NULL,
  xxx_dt DATE NOT NULL,
  xxx_cd SMALLINT NOT NULL,
  zxxx_cd CHARACTER(7),
  state_xxx CHARACTER(2),
  xxx_reading INTEGER,
  xxx_uom CHARACTER(1),
  xxx_nb CHARACTER VARYING(17),
  xxx_id INTEGER NOT NULL,
  xxx_in CHARACTER(1) NOT NULL,
  xxxn_in CHARACTER(1) NOT NULL);

CREATE UNIQUE INDEX ip_xxx
  ON xyz (xxx ASC, xxx_dt ASC, xxx_cd ASC, state_xxx ASC, xxx_reading ASC, xxx_nb ASC) NULLS NOT DISTINCT;

1. 验证NULLS NOT DISTINCT索引兼容性 #

DMS 3.5.3/3.5.4版本可能对PostgreSQL的NULLS NOT DISTINCT唯一索引存在识别问题。3.5.2版本的验证逻辑未严格校验该属性，而高版本引入的严格检查导致无法将其作为验证的唯一键。

2. 替换为主键约束（优先方案） #

若业务逻辑允许，将唯一索引替换为主键约束，DMS对主键的兼容性和识别优先级更高：

-- 删除原唯一索引
DROP INDEX ip_xxx;

-- 添加主键约束（确保列组合无重复，符合业务主键规则）
ALTER TABLE xyz ADD CONSTRAINT pk_xyz PRIMARY KEY (xxx, xxx_dt, xxx_cd, state_xxx, xxx_reading, xxx_nb) NULLS NOT DISTINCT;

3. 手动指定验证列 #

如果无法修改索引类型，在DMS迁移任务中手动指定验证列：

• 编辑DMS迁移任务，进入「数据验证」配置模块
• 选择「自定义验证规则」，为表xyz指定验证列：xxx, xxx_dt, xxx_cd, state_xxx, xxx_reading, xxx_nb

4. 查看DMS日志定位具体错误 #

检查DMS复制实例的CloudWatch日志，搜索数据验证相关的报错信息，比如索引识别失败、列类型不匹配等，明确故障根源。

5. 临时回退版本 #

若上述方案无法快速解决，可临时将DMS复制实例回退至3.5.2版本，完成验证后再考虑升级（需关注AWS后续版本是否修复该兼容性问题）。

内容的提问来源于stack exchange，提问作者Lakshmi Narayana