点击上方“IT那活儿”公众号--专注于企业全栈运维技术分享，不管IT什么活儿，干就完了！！！ 在某oracle数据库替换oceanbase国产库项目现场，使用OMS工具在进行数据迁移时，迁移数据的实时速度变得非常慢，由300MB/S变成了50K/S，严重影响了迁移进度。
考虑到此次迁移的数据量与以前并没有不同，在不考虑遇到BUG的情况下，影响迁移速度的情况有以下几种可能：
联系源端oracle数据库维护人员，确认下当前数据库是否有异常，得到的反馈是数据库没有异常等待和锁，CPU、内存、IO等资源也没有异常。检查下目标端oceanbase库运行情况，QPS、TPS、负载也不高。除了OMS的连接之外没有其它的会话。联系主机人员，帮忙检查下OCEANBASE库的操作系统。得到的反馈主机负载很正常。操作系统日志没有异常。联系主机人员，帮忙检查下OCEANBASE库用到的硬盘。得到的反馈是硬盘状态正常。也进行了写入测试，能达到500MB/S。2.4 检查网络
联系网络人员，检查下网络负载是否过大。得到的反馈是网络宽带利用率正常，抓包看交互正常，源端与目标端的IP网络也是通的。
在目标端数据库进行写入测试，1亿条数据，5分钟就写完了。排查问题至此，想到可能影响迁移速率的问题都已排除，那问题在哪里呢？此次迁移与上一次的迁移有何不同？有什么变化？既然发现了不同，虽然有点不符合逻辑，那就向oceanbase的技术支持人员咨询，将上面的排查结果与技术支持人员进行了同步，给出了如下继续排查的建议：- 缩小迁移范围，确认下是否是由某张表的问题导到的迁移速度变慢。
确认全量迁移速度快与速度慢的参数差异。
经过多轮测试，最终确认迁移速度慢的表有3张。
这3张表与其它表的区别是这是分区表，分区数量每表张表1000多个。迁移快的OMS全量迁移链路与迁移慢的全量迁移链路的参数差异是enablePartitionBucket,慢的那条OMS链路，因为配置了configurl后，自动设置此参数值为true。当前使用的OMS版本是4.1.0。后续发布的版本中已经修正了此参数。目前此版本如果遇到了此问题，需手动修改此参数为FALSE。触发迁移慢的3张表经过业务人员确认，不需要反向增量，那就在后续的迁移过程中避免使用configurl。
