對金融企業而言，系統架構從集中式轉向分布式是大勢所趨。在數據庫層面，要從單機數據庫轉向分布式數據庫雖極具誘惑，但更換數據庫，企業決策依然會非常謹慎，因為涉及到巨大的風險和成本，其中就包含數據庫遷移過程中的風險和成本。而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走出了堅實的一步，積累了彌足珍貴的經驗，這些都為今后的國產進程給出了很好的示范效應。
