搞数据库迁移这事儿，说白了就是一场“拆弹演练”。你手里的 Oracle 数据库可能跑了十年、二十年，上面挂着几十个业务系统，用户早就习惯了它“从不宕机”的节奏。可当政策要求国产化替代，或者云厂商抛出“降本 30%”的橄榄枝时，你不得不面对现实：迁移不是敲几行命令就能搞定的事。我见过太多团队，前期调研拍胸脯，一到真刀真枪的割接日，就出现数据不一致或应用连接超时，灰头土脸回滚。所以，真正的迁移方案必须从规划那天起就把“容错”刻在骨子里。
先说规划的起点。你得先摸清家底，别光看数据字典里有多少张表。去问业务方：哪些表在凌晨两点还有写入？哪个报表查询能吃掉整个 CPU？这些细节往往藏在运维日志的角落里。我参与过一个项目，迁移前调研发现某张日志表每天增长 200 GB，但业务方坚持“不能停写”。方案是把这张表单独做增量同步，迁移当天只切 5 分钟的数据。这种“定制化”规划，比拿个通用脚本跑一遍靠谱十倍。记住，Oracle 的迁移从来不是技术问题，而是业务理解问题。
到了选型阶段，别被厂商的 PPT 带偏。逻辑迁移用 expdp/impdp，适合小库，但遇到几 TB 的大库，光导出就要一天一夜，中间网络抖动一下全白干。物理迁移用 RMAN 或者 Data Guard，速度快，但对停机窗口要求高。还有个隐藏选项：OGG（Oracle GoldenGate），适合零停机场景，但配置复杂，单是抽取进程的延迟监控就能让人崩溃。我的建议是：如果业务允许 2 小时停机，直接上 RMAN 物理备份恢复，这是最稳的路。别追求花哨的“在线迁移”，你省下的那点时间，可能要用十倍精力去排查字符集乱码。
测试阶段千万不能省，但很多人把测试做成了“走过场”。你以为在测试环境跑一遍同样的脚本就完了？错。真正要测的是极端情况：比如迁移过程中源库突然写入 10 万条订单，目标库的同步进程能不能扛住？再比如，网络闪断 5 分钟后，增量同步能不能自动续传？我见过最惨的案例，测试环境数据量只有生产库的十分之一，结果上线当天目标库的 redo log 撑爆了磁盘——因为测试时根本没模拟高峰期的写入量。所以，测试要造“脏数据”，要模拟网络抖动，甚至要演练回滚流程。回滚不是承认失败，而是给你留条活路。
正式迁移那天，心态要像外科医生一样冷静。先做全量备份，再做增量同步，停应用、做最终一致性校验。有个细节容易被忽略：时间戳。Oracle 的时间精度有时会到毫秒，但目标库如果是其他数据库，时间类型可能只支持到秒。别等割接完才发现报表里的时间对不上。另外，迁移脚本要分版本管理，每一步都要有回滚命令。我习惯在迁移前打印一份“作战手册”，每完成一步就划掉一行，旁边标注实际用时。这样即使中途出问题，也能快速定位是哪个环节卡住了。
割接后的验证，比迁移本身更考验人。别光盯着数据条数，要跑业务场景。比如电商系统的“下单—支付—发货”全流程，在目标库上走一遍。如果某个存储过程报错，别急着骂 DBA，先检查权限映射——Oracle 的 schema 权限和角色分配，迁移后经常会变成一团乱麻。还有个小技巧：把生产环境的慢查询日志抓出来，在目标库上重跑一遍，对比执行计划。我见过一个案例，迁移后某条查询从 0.1 秒变成 10 秒，原因是统计信息没更新，优化器走了全表扫描。这种坑在验证阶段踩不到，上线后就是故障。
别忘了人的因素。数据库迁移从来不是 DBA 和架构师能单独搞定的。业务方需要确认数据一致性，运维团队要盯着监控告警，安全部门要检查加密配置。我建议开个“迁移作战室”，拉个微信群，每个环节设一个“决策人”。比如，当数据校验发现差异超过 1% 时，谁来拍板是继续还是回滚？这个权利不能给技术经理，得交给业务总监。因为只有他知道，停机半小时造成的损失是否比数据不一致的风险更小。迁移是技术活，更是管理活。
