聊数据库迁移这事儿，得先从真实场景说起。我有个朋友，在一家电商公司做 DBA，去年双十一前接到任务：把一套跑了五年的 Oracle 数据库从本地机房迁到阿里云。老板给的时间是两周，但数据量有 3 TB，业务还不能停超过 4 小时。他跟我吐槽时，脸上的表情就像要上刑场。熬了三个通宵，总算在截止日期前搞定。但中间出了个岔子——测试环境里跑得好好的脚本，到了生产环境就卡死，查了半天发现是字符集不一致，导致索引重建失败。这种坑，踩过的人都知道有多疼。
其实 Oracle 数据库迁移的核心就三件事：数据怎么搬、业务怎么停、出了问题怎么回滚。先说数据搬法，最笨的是用 exp/imp 导出导入，但碰上几百 GB 的数据，导出文件动辄几十个，传输和解压就能把人搞得崩溃。稍微聪明点的用 Data Pump（expdp/impdp），可以并行导出，还能压缩，速度能快三四倍。但遇到跨版本迁移，比如从 11g 迁到 19c，Data Pump 的参数设置就特别讲究，尤其是 compatible 参数，设不对直接报错。更高级的方案是用 GoldenGate 做实时同步，适合业务不能停的场景。但这玩意儿配置复杂，光 capture 和 apply 进程的调优就能写本书。
再说业务停机时间。很多老板觉得“不就是把数据拷过去嘛，一晚上搞定”。但现实是，数据量一大，全量导出加增量同步，再算上表空间、用户权限、存储过程、定时任务的迁移，四个小时根本不够用。我见过最离谱的案例是某银行做迁移，全量数据导出花了 7 小时，结果增量日志积压太多，GoldenGate 的 trail 文件撑爆了磁盘，被迫延长停机到 26 小时。所以靠谱的做法是先做预演，把真实数据量、网络带宽、磁盘 I/O 这些指标跑一遍，再跟业务方谈一个合理的窗口期。
迁移过程中最容易被忽视的是对象依赖关系。Oracle 里一个表可能有几十个索引、触发器、外键约束，还有物化视图和同义词。如果按默认顺序导，很多对象会因为依赖的表还没创建而报错。一个技巧是先导出 DDL，手动调整顺序，把基础表、分区表、索引、约束分批执行。但更坑的是自定义类型和包体，有些存储过程里引用了动态 SQL，依赖的表名是拼接出来的，这种在目标环境里根本查不出来，只有跑业务时才会炸。我见过一个场景，迁移完成后应用报错 ORA-00904，查了三天才发现是某个函数里硬编码了源库的表空间名。
回滚方案是很多人不愿意想但必须准备的事。最简单的做法是保留源库的完整备份，万一新环境出问题，直接用 Flashback Database 恢复到迁移前的时间点。但如果你用的是 Data Guard 做物理备库迁移，回滚反而麻烦——因为备库的角色一旦切换，源库的归档日志可能就被删了。更稳妥的做法是先用 RMAN 做全库备份，然后在新环境上搭建一套相同的测试库，用 Data Pump 做逻辑迁移，这样即使失败，源库还能正常跑。我习惯在迁移前写一个详细的回滚脚本，包括删除新环境对象、恢复源库连接、修改 DNS 解析，每个步骤都测试三遍。
还有网络和存储的坑。Oracle 数据库对网络延迟特别敏感，尤其是 RAC 环境下，节点间的心跳网络如果延迟超过 20 ms，就会触发脑裂。跨机房迁移时，如果源库和目标库不在同一个网段，必须提前测好带宽和延迟。有个朋友遇到过，迁移完成后应用连接延迟从 2 ms 飙升到 80 ms，查了半天发现是防火墙策略导致 TCP 三次握手多跳了两跳。存储方面，Oracle 对磁盘 I/O 的依赖远超 MySQL，如果新环境用的是共享存储，一定要先用 Orion 工具测 IOPS 和延迟，否则数据写入时可能直接卡住。
说个容易被忽略的点——审计和安全策略。很多企业迁移后才发现，新环境的安全策略比源库严格得多，比如密码复杂度、登录失败锁定、审计日志保留策略。如果源库的密码是明文存储的，或者用了过时的认证协议，迁移后可能直接无法连接。有个银行的案例是迁移后所有存储过程都无法编译，原因是新库的 PL/SQL 编译器版本升级，老代码里用了不推荐的关键字。所以在迁移前，一定要在目标环境上跑一遍 SQL*Loader 测试脚本，把所有存储过程、函数、包体都编译一次。
总结下来，Oracle 数据库迁移不是单纯的技术问题，而是项目管理问题。数据量大、依赖关系复杂、业务不能停、回滚方案要完整——这些因素加在一起，需要在动手前把每个环节的风险都想象一遍。我见过最成功的案例，不是技术多牛，而是迁移团队提前两个月就开始做压力测试，每周跑一次全量预演，把所有坑都踩一遍，正式迁移时只用了计划时间的一半。所以如果你现在正面临迁移任务，别急着敲键盘，先画个流程图，把数据流、依赖链、回滚路径都标清楚，然后再动手。毕竟，数据库迁移这事儿，慢就是快，稳就是赢。
