作者简介：严军(花名吉远)，十年以上专注于数据库存储领域，对大数据、分布式、高并发、高性能、高可用有丰富的经验.主导过蚂蚁集团核心系统去IOE，数据库LDC单元化多活项目，常年负责蚂蚁重大数据库活动（如双11、双12、春节红包大促），现任阿里云分布式数据库架构师和云数据库架构师，专注于金融行业数字化转型过程中头部客户同构和重构数据库架构和迁移咨询工作。精通Oracle、Mysql、OceanBase数据库 ，擅长分布式数据库架构设计、数据库优化、容灾高可用方案设计。

           OceanBase 迁移服务（OceanBase Migration Service，OMS）是 OceanBase 提供的一种支持同构或异构 RDBMS 与 OceanBase 之间进行数据交互的服务，具备在线迁移存量数据和实时同步增量数据的能力。本文以国内某保险客户核心系统FF数据库升级为例，介绍Oracle到OceanBase数据迁移最佳实践。

FF系统Oracle 到OceanBase数据迁移OMS案例分析

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

第一次优化

优化手段
1、oms 参数调整，增大并发线程，
limitator.platform.threads.number  32 --> 64
limitator.select.batch.max         1200 --> 2400
limitator.image.insert.batch.max   200  --> 400
limitator.datasource.image.ob10freecpu.min=0
2、增大链接数
limitator.datasource.connections.max 50  --> 200
3、jvm内存优化
-server -Xms16g -Xmx16g -Xmn8g -Xss256k --> -server -Xms64g -Xmx64g -Xmn48g -Xss256k
11

优化结果：

通过调整oms参数，增大并发、增加链接数，jvm内存优化后，clog 每分钟产生130个64M 日志（约8.5G日志），cpu 跑满，网络out流量500M，observer目标端服务端出现明显瓶颈。

第二次优化

优化手段
1、OBserver开启日志压缩
ALTER SYSTEM SET clog_transport_compress_all = 'true';
ALTER SYSTEM SET clog_transport_compress_func = 'zlib_1.0';
--租户级别日志压缩
alter system set enable_clog_persistence_compress='true';
2、OBserver 加大转储线程
alter system set _mini_merge_concurrency=32;
alter system set minor_merge_concurrency=32;
3、OBserver加大合并线程数
alter system set merge_thread_count=64;
4、OBserver写入限流
alter system set writing_throttling_trigger_percentage =80;
5、降低转储内存阈值，让obsever提前转储
alter system set freeze_trigger_percentage=30;

优化结果

此次主要对observer 内核参数进行优化，调整参数后，每分钟OB日志量下降到20个左后，但是cpu 利用率仍然非常高，原因分析是大分区表truncate后带来的checksumtask的开销问题，如果开始了checksumtask维护，oms还没开始导入任务，observer节点的cpu能耗费将近 50%，这个影响非常大，属于ob缺陷，需要内核后续修复。

第三次优化

手动清理内部表，避免checksumtask 开销占用cpu 资源，同时把租户leader 打散到3个zone，利用3台机器资源多点写入能力同时迁移数据。

优化手段
1、清理truncate 掉的分区表元数据
delete from __all_sstable_checksum where sstable_id in 
(select table_id from __all_virtual_table_history where table_name='table_namexxx' minus 
 select table_id from __all_virtual_table where table_name='table_namexxx');
2、租户leader打散到三个zone
alter tenant tenant_name set primary zone='RANDOM';

优化结果

此次优化，主要是绕过OB内核bug，通过调整OB部署架构，借助多点写入能力提升性能，OMS每秒迁移提升到大约7w条记录，全量迁移减少到7个小时左右完成。

第四次优化

分析OBserver 上面的慢sql，检查发现，慢sql的执行计划为MULTI_PART_INSERT, 分布式执行计划，因为客户使用的分区表，同时有全局索引，会导致执行计划是分布式执行计划，效率比较差。

优化手段
1、分区表改成非分区表
根据历史经验，单表数据不超过10亿行或者单表容量不超过2000GB可以不考虑分区表
2、临时删除二级索引，只保留主键，待全量迁移完毕后再建二级索引

优化结果

此次优化，主要是对schemal表结构进行优化，分区表改造成非分区表以及后建索引，OMS在3个小时内完成全量数据迁移，大大减少了数据迁移时间

OMS数据迁移性能问题排查方法总结

全量迁移关注的性能指标，按照并发维度来，一个并发一般读取源端的网络流量在1-2M之间，使用tsar --traffic --live -i1s查看网络情况，如果网络流入在[并发数*1,并发数*2]M之间则说明正常。rps一般一个并发在1000左右，这个rps和具体的表的数据字段多少，单行记录大小都有关系。

OMS数据迁移性能优化方法总结

我们将OMS数据迁移常用的优化方法总结为下列表格供大家参考，往往可以达到事半功倍的效果。