Oracle 迁移到新数据库，最让人紧张的不是技术本身，而是切换那一刻。几亿条数据、数千个并发连接、不能出错不能停——怎么完成从 Oracle 到新数据库的无缝切换？
这个问题不是一道选择题，而是一道排序题：三种主流方案各有适用场景，选错的不只是技术路线，更是整个迁移周期的节奏。
三种方案各是什么？
停机割接
最直接的方案：选一个业务低谷期（通常是凌晨），停掉所有写入，把 Oracle 中的数据全量导出，导入到新数据库，验证无误后切换应用连接。
优点： 方案简单，操作步骤少，出问题的排查路径清晰。全量数据一次性迁移，不存在数据不一致的窗口期。
缺点： 业务必须停机，停机时间取决于数据量和导入速度。对于几百GB以下的小规模系统，停机窗口可以控制在数小时内；但数据量达到TB级别时，停机时间可能拉长到一天甚至更久。
适用场景： 数据量不大（几百GB以内）、业务可以接受数小时停机、系统复杂度较低的内部系统或后台管理类应用。
双写方案
应用层同时向 Oracle 和新数据库写入数据，读请求在稳定运行后逐步切到新库，最终下线 Oracle。
优点： 可以把停机窗口压到极短，业务感知较小。数据在写入时就同步到两端，不存在追赶增量的过程。
缺点： 一致性、回滚和测试复杂度最高。应用需要改造写入逻辑，处理双写失败的一致性问题（一边成功一边失败怎么办），还需要处理数据校验和异常回滚。开发成本和测试成本都显著高于其他方案。
适用场景： 对可用性要求极高、停机窗口极短的核心交易系统，且团队有足够的应用改造能力和测试资源。
增量同步方案
先做一次全量数据迁移，然后通过日志解析（如 Oracle 的 Redo Log / Archive Log）实时捕获增量变更，同步到新数据库。当两边数据追平后，选择一个时间点切换。
优点： 全量迁移可以在业务运行期间完成，不占用停机窗口。增量同步期间业务正常运转，切换时只需处理一个短暂的追赶窗口（通常几分钟到几十分钟）。
缺点： 需要可靠的日志解析和同步工具，对异构迁移（Oracle 到 MySQL 协议兼容的数据库等）的兼容性要求高。同步过程中如果出现大事务或 DDL 变更，可能需要人工干预。
适用场景： 数据量大（TB级别以上）、业务不能长时间停机，且目标数据库有成熟的同步工具支持的场景。
怎么选？四个关键决策维度
1. 可接受的停机时间
这是最硬的约束。如果业务方明确要求停机不超过30分钟，那停机割接基本可以直接排除，增量同步或双写是更合理的选择。如果业务能接受4-8小时的维护窗口，停机割接反而最省事。
2. 数据量级
数据量决定了全量迁移的耗时。一个经验参考：
- 500GB以内：停机割接可行，导入时间通常在2-4小时
- 500GB-5TB：建议增量同步方案，全量迁移在业务运行期间完成
- 5TB以上：增量同步几乎是唯一选择，同时需要关注同步工具的吞吐能力
3. 应用改造能力
双写方案需要改应用代码，这意味着开发、测试、灰度的完整周期。如果团队人力紧张或应用代码历史包袱重，双写的成本可能远超预期。相比之下，增量同步方案主要在数据库层面操作，对应用的侵入性更小。
4. 系统复杂度
系统涉及的表数量、关联关系、存储过程和触发器的数量，都会影响迁移难度。系统越复杂，越倾向于选择对应用侵入小的方案。如果一个系统有上百张表和大量 PL/SQL 存储过程，双写的改造工作量会非常庞大。
一个常见的误区
很多人在选方案时，会直接跳到"哪个方案最先进"，然后选双写或增量同步。但实际决策应该反过来：先看约束条件（停机时间、数据量、团队能力），再看哪个方案能匹配这些约束。最简单的方案如果满足约束，就是最好的方案。
还有一个容易忽略的点：三种方案不是互斥的。一些大型迁移项目会组合使用——先用增量同步完成全量+增量迁移，切换时再用一个短暂的停机窗口做最终校验和切换。这种"增量同步+短暂停机"的组合，在实践中非常常见。
迁移前必须做的三件事
无论选哪种方案，以下三件事都是前置条件：
第一，做一次完整的数据兼容性评估。 Oracle 的数据类型、字符集、存储过程语法与新数据库的差异，需要在迁移前全部梳理清楚。特别是日期类型、数值精度、空字符串处理这些细节，往往是迁移后才发现的坑。
第二，建立数据校验机制。 无论哪种方案，都需要在切换前后对新旧库的数据进行比对。行数校验是最基础的，关键业务表还需要做字段级的抽样比对或哈希校验。
第三，准备回滚方案。 切换后如果发现问题，能不能快速切回 Oracle？这要求在切换窗口内保留 Oracle 的写入能力，或者至少保留一个最近的可恢复快照。
工具层面的一些建议
增量同步方案的核心是同步工具的成熟度。以 Oracle 迁移到 MySQL 协议兼容的数据库为例，需要关注工具对 Oracle Redo Log 的解析能力、对大事务的拆分策略、对 DDL 变更的处理方式。不同产品的迁移工具链不同；以 TiDB 为例，PingCAP 提供的 Oracle 迁移方案通常结合第三方 CDC 工具（如 Oracle GoldenGate）或 OMT 工具来完成增量数据同步。工具选型必须结合自身的数据特征和目标数据库来评估，不能只看官方文档的兼容列表。
TiDB 在 Oracle 迁移中的对应能力
TiDB 兼容 MySQL 协议，应用层的连接方式不需要改造，降低了迁移对应用的侵入。在增量同步方面，TiDB 配合第三方 CDC 工具（如 Oracle GoldenGate）可以实现 Oracle 到 TiDB 的实时数据同步，支持"增量同步+短暂停机"的组合方案。此外，TiDB 的在线 DDL 能力使得迁移后的表结构变更不需要额外的停机窗口。
如果你正在规划 Oracle 迁移，建议先从兼容性盘点和增量同步工具的 POC 验证开始，确认数据类型、存储过程和同步链路的可行性，再确定最终的切换方案。