oracle迁移Oceanbase数据迁移踩坑记（二）丨本际云推荐

oracle迁移Oceanbase数据迁移踩坑记（二）

事件背景

我是本际云服务器推荐网的小编小本本，今天分享的是oracle迁移Oceanbase数据迁移踩坑记的第二部分。上次分享问题多在全量迁移阶段，这次是续全量迁移后增量迁移问题填坑过程。测试用户只有4张表时全量、增量、数据校验、反向切换均没有问题，但当用户包含430张表时增量出现了问题。分析发现有的表可以实时同步，有的表数据无法同步。

oracle迁移Oceanbase数据迁移踩坑记（二）

踩坑过程

现将整个过程复现给大家：430张表数据导入测试用户，发起新的迁移作业。迁移任务成功跑通，并没有报错。表结构、全量数据成功迁移，源端和目标端增量进程均已成功启动，增量数据显示已经追平。检查链路监控延迟在20秒正常范围。但是，在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中发现没有无法同步数据表的信息，使用grep OGG_TEST /home/ds/store7103/log/store.log输出同步表的信息情况，使用grep environmentvariables /home/ds/store7103/log/store.log将输出的表信息与白名单的表进行对比，发现日志中输出表被截断，截断点之前的表可以实时同步，截断点之后的表无法同步。

问题解决：问题第一时间反馈给后端OB研发，分析定位为OMS平台问题，因之前测试表数量少没有测试出该缺陷，随后OB研发对于OMS平台进行了补丁升级，问题得到解决。

分析总结

国产化数据库仍在大规模商业化的路上，在具体迁移上线的过程中都是摸着石头过河，OMS数据迁移虽然是OB官方提供的ORACLE到OB数据库进行数据迁移的平台，但完整开放案例不多，很多数据迁移操作的具体步骤仍需要各现场根据自身业务场景予以验证测试，这个过程会不断出现新的问题。现场一是根据业务割接进度，尽量想方设法workaround，另一方面需要及时反馈OB原厂进行产品优化和升级。生态圈的完善本身也是在不断碰撞、完善中建立起来的，Oracle的生态花了多少年，我们每个人都知道，所以，在国产化的进程中，我们都要多一份耐心，多一份主动，多一份承担。这次的分享到此结束，希望这次分享能帮助到大家。

原创文章，作者：小编小本本，如若转载，请注明出处：https://www.benjiyun.com/yunzhujiyunwei/vps-yunwei/5918.html