金融客户使用OceanBase数据迁移OMS，最终迁移效果如何？

对金融企业而言，系统架构从集中式转向分布式是大势所趋。在数据库层面，要从单机数据库转向分布式数据库虽极具诱惑，但更换数据库，企业决策依然会非常谨慎，因为涉及到巨大的风险和成本，其中就包含数据库迁移过程中的风险和成本。而OceanBase数据迁移OMS的出现，至少一定程度上消除了这一阻碍。

以国内某保险客户核心系统FF去O为例，就借助OMS的迁移能力与优势将Oracle数据库迁移到了OceanBase中。

OMS的迁移能力与优势如何？

在业务评估与改造方面，此前迁移一个业务最少需要花费一到两个月时间，进行业务改造和适配，但基于OMS自动化的兼容性评估报告以及负载回放能力，业务前期改造时间可大大缩短。

数据迁移和校验方面，虽然迁移时长与数据量及网络资源密切相关，但在提升迁移质量方面，OMS可以将增量迁移的延迟控制在毫秒级，即便跨城的情况下，最多也只需要三秒钟，而对于验证出所有不一致的数据，OMS还提供修正的结果方案，从而极大提升迁移和校验的整体效率。

在业务切换方面，通常切换前需要制定比较严密的方案，并且切换之前和过程中需要检查和校验环节非常繁琐，因为一步差错就可能会导致数据不一致，OMS通过引入大规模编排能力把所有繁琐环节都落到了平台中，OMS还提供了集成部分中间件的能力，无论在迁移还是校验过程中都用时很少。

保险客户使用OMS，最终迁移效果如何？

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

从整个迁移过程来看，OceanBase迁移服务OMS主要解决了四个重要的问题。第一次通过调整OMS参数，增大并发、增加链接数，jvm内存优化后，clog每分钟产生130个64M日志；第二次此次主要对observer内核参数进行优化，调整参数后，每分钟OB日志量下降到20个左后。

第三次通过调整OB部署架构，借助多点写入能力提升性能，OMS每秒迁移提升到大约7w条记录，全量迁移减少到7个小时左右完成；第四次对schemal表结构进行优化，分区表改造成非分区表以及后建索引，OMS在3个小时内完成全量数据迁移，大大减少了数据迁移时间。

值得一提的是，在OMS迁移过程也出现了几次故障。比如是否发生内存或cpu保护，全量进程是否存在gc情况、是否有异常报错等，这些都是需要进一步排查的。而这些故障背后既反映了国产数据库在面对复杂场景上能力的提升，也反映了分布式架构带来的根本性变化。对此，OceanBase对OMS数据迁移性能问题排查进行了方法总结，具体如下：

这些年我们看过很多的文章都是对于数据库替换的分析和畅想，但是面对实际的大规模复杂的核心应用系统的技术平台替换，过程中还有很多在各种“分析”文章中想不到的问题，尤其对于现有运行的环境的各种适配和兼容、对应用的友好性等很多。

关于这些，Oceanbase走出了坚实的一步，积累了弥足珍贵的经验，这些都为今后的国产进程给出了很好的示范效应。