OMS信创迁移中常见的坑

OMS

• 选择OMS时，建议直接选择OMS最新版本，并单独部署OMS，建议使用物理机，或大内存虚拟机。
• OMS 4.2.x版本，只支持表、索引对象迁移，其余对象需使用dbcat迁移。
• OMS 4.3.x版本，支持table、index、type、procedure、view、sequence、synonym、function，

OMS 坑一：OMS 4.3.1开始全量校验需要单独配置

OMS 4.3.1开始，全量校验只能单独配置，无法在数据迁移链路中配置全量校验。意味着需要至少两个变更窗口进行数据迁移+数据校验

OMS 坑三：全量迁移速度慢

OMS全版本，数据全量迁移速度极限峰值也就100+M

OMS 坑四： 索引后置

全量数据迁移时，一定要选择索引后置。先迁移数据，再创建索引。若索引跟随表结构迁移，迁移效率有时有10倍以上的差异。性能差异原因这里不再追述，懂得都懂。

Oracle迁移到OB_oracle

坑一：INTERVAL分区

OB 4.2.x版本不支持INTERVAL分区，需要在目标端修改表结构，或者源端改造分区表。

坑二：分区表行迁移

OMS不支持开了行迁移的表，需要关闭行迁移后才可迁移数据。关闭行迁移的影响：若业务逻辑有更新分区键的场景需要业务同步整改。

坑三：Oracle迁移到OB不支持外键

Oracle迁移数据时，有外键的场景下，部分表无法迁移成功。无论从数据迁移角度、还是数据库最佳实践层面都不建议在数据库层面通过外键来约束数据一致性。建议业务逻辑改造，通过业务代码约束数据一致性。

坑四：大事务PDML丢数

OMS全版本不支持PDML大事务，大事务PDML会造成数据丢失，产生数据不一致问题。该BUG目前OMS端无法解决。
BUG触发场景：PDML事务产生的归档日志超2个归档时，会丢失事务数据，造成数据不一致。
BUG原理：OMS的store组件使用logminer挖掘归档日志，在挖掘时是两个归档日志为一组进行完整事务挖掘。当并行事务跨三个归档日志时，store组件会错误的把本该提交的commit事务误判为rollback。
BUG规避方案：

• 源端禁用PDML；
• 调大redo log size，使PDML日志不超过2个归档日志。
• 依靠全量校验的的数据修复功能修复缺失数据：谨慎使用

坑五：全量校验对数据库有写入动作。

OMS 4.3.1 BP1，通过备库同步数据后发起全量校验，部分表校验失败。排查日志发现失败的表在校验时，对数据库有写请求，由于备库只读，导致校验程序报错。此问题怀疑时BUG，已经开单跟原厂沟通，目前没有得到有效答复。

坑六： 非法数据

oracle的日期格式校验跟OB不同，导致OB入库校验不通过。

坑七： 字符集

历史Oracle库会有GBK字符集，新建OB租户一般要求使用UTF-8字符集，涉及到字符集转换，char/varchar2字段需要扩字段。
解决方案：

• 源端扩字段长度
• 目标端扩字段长度，OMS 4.3.X版本支持一键扩字段长度。

坑八： 表名&字段名超过30字节

Oracle 12C之后的版本，表名、字段名可以超过30个字节的限制，导致OMS的表结构迁移失败。
解决方案： OMS报错后会给出解决方案，根据实际情况处理即可

MySQL迁移到OB_MySQL

坑一: 源端表要有主键

数据迁移依赖表上的主键，没有主键的表需要在源端创建主键。

坑二： 开启增量只能从主库抽取数据

增量抽取只能从主库抽取，对主库有侵入。

坑三 自增列字段类型选bigint

OB MySQL租户的BUG：OB自增列在自增时会跳跃，并且跨段很大。int字段类型会在较短的时间内达到上限，造成数据无法写入。