OceanBase迁移服务（OceanBaseMigration Service，OMS）是OceanBase提供的一种支持同构或异构RDBMS与OceanBase之间进行数据交互的服务，它提供了数据的在线迁移和实时增量同步的数据复制能力。上次分享的问题（《oracle迁移Oceanbase数据迁移踩坑记（一）》）多在全量迁移阶段，这次是续全量迁移后增量迁移问题填坑过程。为了验证增量同步和回退过程，我们重新发起了新链路的测试，一开始测试用户只有4张表，全量、增量、数据校验、反向切换均没有问题。后来发起一个用户包含430张表的链路时增量反复出现问题，分析发现有的表可以实时同步，有的表数据无法同步。
现将整个过程复现给大家：430张表数据导入测试用户，发起新的迁移作业。
场景复现：
迁移任务成功跑通，并没有报错，如下图所示。
1.表结构、全量数据成功迁移，源端和目标端增量进程均已成功启动。
2.增量数据显示已经追平。
检查链路监控延迟在20S正常范围。
问题重现：
在Oracle端（源端）的OGG_TEST表中插入数据，并提交。
OB端（目标端）的OGG_TEST表并没有更新。
而在Oracle端（源端）的另一张表MAPPING_LIST表中插入数据，并提交。
OB端（目标端）的MAPPING_LIST发生更新。
问题分析：
检查OMS迁移作业，确认未同步表在白名单配置中
登录OMS主机，检查/home/ds/store作业号/conf/crawler.cof文件中白名单中有未同步表。
登录OMS主机，检查/home/ds/run/增量链路的组件号/conf/jdbcweiter.conf中也配置过未同步表。
检查日志/home/ds/store7103/log/store.log中发现没有无法同步数据表的信息。
#grepOGG_TEST home/ds/store7103/log/store.log
输出同步表的信息情况
#grep'environment variables' home/ds/store7103/log/store.log
将输出的表信息与白名单的表进行对比，发现日志中输出表被截断，截断点之前的表可以实时同步，截断点之后的表无法同步。
白名单：
日志：
问题解决：
问题第一时间反馈给后端OB研发，分析定位为OMS平台问题，因之前测试表数量少没有测试出该缺陷，随后OB研发对于OMS平台进行了补丁升级，问题解决。
上次有说OB国产化数据库仍在大规模商业化的路上，在具体迁移上线的过程中都是摸着石头过河，OMS数据迁移虽然是OB官方提供的ORACLE到OB数据库进行数据迁移的平台，但完整开放案例不多，很多数据迁移操作的具体步骤仍需要各现场根据自身业务场景予以验证测试，这个过程会不断出现新的问题，现场一是根据业务割接进度，尽量想方设法workaround，另一方面需要及时反馈OB原厂进行产品优化和升级。生态圈的完善本身也是在不断碰撞、完善中建立起来的，oracle的生态花了多少年，我们每个人都知道，所以，国产化的进程中，我们都要多一份耐心，多一份主动，多一份承担。这次的分享到此结束，希望这次分享能帮助到大家。
