--- title: "其他数据库迁移至 OceanBase 数据库最佳实践 - OceanBase 最佳实践 | OceanBase 文档中心" description: 其他数据库迁移至 OceanBase 数据库最佳实践 本文介绍如何从其他数据库迁移数据至 OceanBase 数据库。 本文将首先介绍常规的全量迁移和增量迁移方法，然后提供性能优化方法供参考，最后给出迁移的实践案例。 我们推荐您使用 OceanBase 提供的数据迁移服务（OMS）进行其他数据库至 OceanBase… image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 # 其他数据库迁移至 OceanBase 数据库最佳实践 更新时间：2026-07-28 [编辑](https://github.com/oceanbase/best-practices-doc/edit/master/zh-CN/300.migrations/400.migrate-data.md) 适用产品： OceanBase 数据库 适用场景： 数据迁移及导入 本文介绍如何从其他数据库迁移数据至 OceanBase 数据库。 本文将首先介绍常规的全量迁移和增量迁移方法，然后提供性能优化方法供参考，最后给出迁移的实践案例。 我们推荐您使用 OceanBase 提供的数据迁移服务（OMS）进行其他数据库至 OceanBase 数据库的迁移。更多信息，参考 [OceanBase 迁移服务文档](https://www.oceanbase.com/docs/oms-doc-cn)。 ## 数据迁移流程 按以下步迁移数据： 1. 完成准备工作。 使用 OMS 迁移数据前，您需要对源或目标数据库进行创建迁移用户、为用户授权等准备工作。详情请参见 [创建数据库用户](https://www.oceanbase.com/docs/enterprise-oms-doc-cn-1000000005119967)。 2. 新建数据源。 在 OMS 控制台，分别新建源端和目标端的数据源。详情请参见 [新建数据源](https://www.oceanbase.com/docs/enterprise-oms-doc-cn-1000000005120075)。 3. 新建数据迁移项目。 根据业务需求，在数据迁移项目中选择源端、目标端、迁移类型和迁移对象。迁移类型包含结构迁移、全量迁移、增量同步、全量校验和反向增量。详情请参见对应类型的数据迁移项目文档。 4. 通过预检查后，启动数据迁移项目。 5. 查看数据迁移项目的状态。 数据迁移项目启动后，会根据选择的迁移类型依次执行。详情请参见 [查看数据迁移项目的详情](https://www.oceanbase.com/docs/enterprise-oms-doc-cn-1000000005120032)。 6. （可选）停止并释放数据迁移项目 确认数据迁移项目成功，并不再需要同步源库和目标库的数据后，您可以清理当前的数据迁移项目。详情请参见 [释放和删除数据迁移项目](https://www.oceanbase.com/docs/enterprise-oms-doc-cn-1000000005120036)。 ## 性能调优 本节将通过性能调优优化 OMS 的数据迁移效率。调优分为三个方面：源端规格、目标端规格和 OMS 调优。 ### 源端规格 首先，通过监控工具查看源端数据库的性能，确定是否存在瓶颈。 #### 监控指标 - **CPU 使用率**：查看 CPU 资源是否被耗尽。 - **内存使用**：确保内存足够且未出现内存泄漏或溢出。 - **磁盘 I/O**：检查是否有磁盘瓶颈，影响数据读取速度。 - **网络带宽**：确保网络传输速度不受限。 #### 调优方法 1. **升级硬件配置**： - 增加 CPU 核心数。 - 扩充内存容量。 - 使用更高性能的磁盘（如 SSD）。 2. **优化数据库配置**： - 调整缓冲区大小、连接池等参数。 - 清理未使用的索引和表。 - 执行必要的数据库维护，如重建索引、分析表等。 3. **查询优化**： - 分析慢查询并进行优化。 - 使用索引提升查询性能。 - 将复杂查询拆分为多个较小的查询。 ### 目标端规格 与源端类似，通过监控工具查看目标端数据库的性能数据，确定是否存在瓶颈。 OceanBase 优化建议： | 措施 | 说明 | | --- | --- | | 打散 Leader | 将 Leader 打散到所有机器：`ALTER TENANT [tenant_name] primary_zone='RANDOM';`。 | | 调大 OceanBase 租户内存 | `ALTER RESOURCE POOL MODIFY UNIT='UNIT_CONFIG(unit_memory_size, ...)';` | | 开启 Clog 日志压缩 | `ALTER SYSTEM SET clog_transport_compress_all = 'true';`，`ALTER SYSTEM SET clog_transport_compress_func = 'zlib_1.0';`<\br> 租户级别：`ALTER SYSTEM SET enable_clog_persistence_compress='true';` | | 调整写入限速 | `ALTER SYSTEM SET write_throttling_trigger_percentage =80;`。当写入达到此阈值时，写入速度变慢。 | | 调整触发冻结的阈值 | 将 freeze_trigger_percentage 从默认值 20 调整到 70。 | | 调低转储阈值 | `ALTER SYSTEM SET freeze_trigger_percentage=30;`。当写入数据量很大时，调低转储阈值，让 OceanBase 提前转储。 | | 调高转储和合并并发 | `ALTER SYSTEM SET _mini_merge_concurrency=0;` 和 `ALTER SYSTEM SET minor_merge_concurrency=0;`。当为 0 时，表示默认为 2。当机器 资源充足时，调高此参数提高转储速度。 | | 调高合并线程数 | `ALTER SYSTEM SET merge_thread_count=64;` | | 刷新执行计划 | `ALTER SYSTEM FLUSH PLAN CACHE TENANT = 'tenant_name';`。数据迁移可能导致数据分布和统计信息发生变化。刷新执行计划可以确保数据库使用最新的统计信息，从而提高查询性能。 | ### OMS 调优 在确认源端和目标端没有瓶颈后，可以通过调整 OMS 组件和并发度来提高性能。 #### 优化 OMS 机器资源 - 确保 OMS 机器的 CPU、内存和网络带宽等资源充足，以便设置更高的链路任务并发数。 - 使用多台机器部署 OMS，以分散各个组件的任务，提高整体性能。 #### 注意 OMS 迁移的性能越高，源端数据库的压力（大批量数据读取）就会越高。 #### 调优组件 1. **调整并发**： OMS 通过调整并发的方式实现对 CPU 使用的限制，无强制的 CPU 隔离能力，在多链路高压力的环境下可能造成 CPU 争用严重。调整 OMS 任务的并发度，增加并发任务数以提高数据传输速度。 并发度一般和机器 CPU 核数相关，最大可以设置成 CPU*4。设置并发时，请考虑机器上是否运行其他任务。全量迁移建议更改目的端并发，多数情况是目的端存在瓶颈。如果源端存在瓶颈再调整源端并发。 全量迁移并发调整： ![migration-6-zh](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/oms/oms-enterprise/migration-6-zh.png) 增量同步并发调整： ![migration-7-zh](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/oms/oms-enterprise/migration-7-zh.png) 在 `connector` 任务目录下运行 `./connector_utils.sh metrics` 查看 metrics 信息，其中 `DISPATCHER: wait record:0, ready batch:0` 中，如果 wait record 是 0 或者非常低比如 100 以内就是源端瓶颈，如果 ready batch 比较多则是目的端瓶颈。如果 wait record 比较多但是没有 ready batch 可能是存在热点。 2. **任务拆分**： 将大表或复杂表的数据迁移任务拆分为多个较小的任务，以提高传输效率。 3. **增量同步配置**： 调整 `store` 和 `Incr-Sync/Full-Import`，以优化增量同步性能。OMS 的增量由 Store 和 Writer 组件组成，Store 负责源端解析日志，Writer 负责目标端数据写入。因此 Store 在全量迁移开始时拉起，Writer 在全量结束后拉起。 Store 解析有问题可以尝试调整以下参数： ```text deliver2store.logminer.fetch_arch_logs_max_parallelism_per_instance=日归档/500g +1 deliver2store.logminer.max_actively_staged_arch_logs_per_instance=上述参数*2 deliver2store.logminer.staged_arch_logs_in_memory=true //需要配合调整 JVM，若有大事务可开启减少落盘 deliver2store.logminer.max_num_in_memory_one_transaction=3000000 //需要上面参数为 true deliver2store.logminer.only_fetch_archived_log=true //只解析归档 deliver2store.logminer.enable_flashback_query=false deliver2store.parallelism=32 ``` OMS 参数经验值： | 参数名 | 说明 | | --- | --- | | datasource.connections.max | 增大数据库连接数至 200 | | light-thread | 并发最多可调整为 200 | | batch_select | 调整为 300 | | batch_insert | 调整为 200 | | ob max_allowed_packet | 调整为 512M | #### 说明 在数据迁移后，将系统变量和参数务重新修改为默认值。 ## 实践案例 本节介绍如何将数据从 Oracle 迁移至 OceanBase 数据库。Oracle 源端总共有 15 张表分区表，22 亿条记录需要迁移到 OceanBase 目标端。未优化前，全量迁移耗时 11 小时，平均每秒 5.5w 条记录，速度太慢，不符合客户目标。 1. 优化 OMS。 ```text -- OMS 参数调整，增大并发 ## 读线程 source.workerNum: 并发度和机器 CPU 核数量相关，最大可以设置为 CPU*4 ## 写线程 sink.workerNum: 并发度和机器 CPU 核数量相关，最大可以设置为 CPU*4 ## 一个切片查询的批数量 source.sliceBatchSize: 大表通常设置为 1000 ## 最大连接数 source.databaseMaxConnection limitator.platform.threads.number 32 --> 64 limitator.select.batch.max 1200 --> 2400 limitator.image.insert.batch.max 200 --> 400 -- 增大链接数 limitator.datasource.connections.max 50 --> 200 -- JVM 内存优化 -server -Xms16g -Xmx16g -Xmn8g -Xss256k --> -server -Xms64g -Xmx64g -Xmn48g -Xss256k 11 ``` 经过上述调整后，Clog 每分钟产生大约 130 个 64MB 日志（约 8.5GB 日志），CPU 使用率达到满载，网络出口流量达到 500MB。因此，目标端 OceanBase 出现了瓶颈。 2. 优化目标端 OceanBase 数据库。 ```sql -- OceanBase 开启日志压缩 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'; -- OceanBase 加大转储线程 ALTER SYSTEM SET _mini_merge_concurrency=32; ALTER SYSTEM SET minor_merge_concurrency=32; -- OceanBase 加大合并线程数 ALTER SYSTEM SET merge_thread_count=64; -- OceanBase 写入限流 ALTER SYSTEM SET writing_throttling_trigger_percentage =80; -- 降低转储内存阈值，让 OceanBase 提前转储 ALTER SYSTEM SET freeze_trigger_percentage=30; ``` 经调整 OceanBase 内核参数后，每分钟 OceanBase 日志量下降到约 20 个，但 CPU 利用率仍然非常高。原因是大分区表 TRUNCATE 操作后带来的 Checksum Task 开销。如果启动了 Checksum Task 维护，而 OMS 尚未开始导入任务，OceanBase 节点的 CPU 能耗将近 50%。 3. 手动清理内部表。 ```sql -- 清理 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'); -- 租户 Leader 打散到三个 Zone ALTER TENANT tenant_name SET primary zone='RANDOM'; ``` 通过调整 OceanBase 部署架构，借助多点写入能力提升性能，OMS 迁移速度提升到大约 7w/s，全量迁移减少到 7 个小时左右完成。 4. 分析慢 SQL。 ```sql SELECT * FROM gv_plan_cache_plan_explain WHERE ip=xxx.xx.xx.x AND port=2882 AND plan_id=160334 AND tenant_id=1004; ``` 优化方法：将分区表改为非分区表。根据历史经验，单表数据不超过 10 亿行或者单表容量不超过 2000GB 可以不考虑分区表。临时删除二级索引，只保留主键，待全量迁移完毕后再建二级索引。 经过以上 Schema 表结构的优化，并将分区表改造成非分区表以及后建索引，OMS 在 3 个小时内完成全量数据迁移，减少了数据迁移时间。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线