最佳实践！Oracle数据库迁移难题，使用OceanBase能解决吗？

如今在数据库迁移领域，经过长期的研发技术的投入，国内技术厂商打破了国外数据库厂商的垄断，可以做到在不影响生产业务的情况下，安全、高效、实时地将数据库数据迁移到同构或异构数据库上。

以国内某保险客户核心系统FF去O为例，当客户需要将 Oracle 数据库数据首次迁移到国产数据库OceanBase 时，可在业务不停的情况下，实时将 Oracle 数据库的数据迁移过去，且增量数据也实时迁移过去，并在首次全量数据传输完成后，再同步到目标端数据库中。那么，数据库是如何进行迁移的？迁移过程存在问题如何解决呢？今天就来聊一聊。

借助OceanBase，成功实现数据迁移

在客户核心系统FF中，Oracle源端总共有15张表分区表，22亿条记录需要迁移到Oceanbase 目标端。未做专门优化前，全量迁移耗时11个小时，平均每秒5.5w条记录，速度太慢，不符合客户目标。

基于此，客户借助OceanBase数据迁移服务（OceanBase Migration Service，以下简称为OMS）对系统进行了四次优化，成功实现数据迁移。第一次通过调整OMS参数，增大并发、增加链接数，jvm内存优化后，clog每分钟产生130个64M日志（约8.5G日志），cpu跑满，网络out流量500M，但observer目标端服务端出现明显瓶颈。

于是第二次主要对observer内核参数进行优化，调整参数后，每分钟OB日志量下降到20个左后，但是cpu利用率仍然非常高，OMS还没开始导入任务，observer节点的cpu能耗费将近50%。

紧接着，第三次直接手动清理内部表，同时把租户leader打散到3个zone，利用3台机器资源多点写入能力同时迁移数据。结果显示，OMS每秒迁移提升到大约7w条记录，全量迁移减少到7个小时左右完成。

但优化还在继续，第四次通过对schemal表结构进行优化，分区表改造成非分区表以及后建索引，OMS在3个小时内完成全量数据迁移，大大减少了数据迁移时间。从整个迁移过程来看，OceanBase迁移服务主要解决了四个重要的问题。

OMS数据迁移优化后，性能大大提升

OMS作为OceanBase 一站式数据传输和同步的产品，它支持多种关系型数据库，消息队列与 OceanBase 之间的数据复制，是集数据迁移、实时数据同步和增量数据订阅于一体的数据传输服务。

依托于OMS，迁移过程也并不是完全一帆风顺，虽然未产生重大生产事故，但过程中也出了几次故障。比如是否发生内存或cpu保护，全量进程是否存在gc情况、是否有异常报错等，这些都是需要进一步排查的。而这些故障背后既反映了国产数据库在面对复杂场景上能力的提升，也反映了分布式架构带来的根本性变化。

对此，OceanBase对OMS数据迁移性能问题排查进行了方法总结，具体如下：

今天国内仍有金融机构的核心业务仍然运行在国外的数据库上，这是一个我们无法回避的现实。数据库的替换不仅是一个产品的替换，替换的目的不单纯为了“国产”两个字，更重要的是：替换后的新系统必须具备老系统和国外产品不具备的能力，不仅是性能和稳定，更多是对业务的敏捷支撑能力，和面对海量业务和不确定性的业务高峰时刻的处理能力，以及更上一层楼的金融级高可用能力。

不过令人惊喜的是，关于这些，OceanBase已经走出了坚实的一步，积累了弥足珍贵的经验，这些都为今后的国产数据库迁移作出了很好的示范。