最近帮一个朋友处理 Oracle 数据库迁移的事，折腾了大半个月，中间踩了不少坑。说实话，这类活儿在圈子里算不上新鲜，但每次上手，总会遇到一些新状况让人措手不及。数据库迁移听起来就是复制粘贴，真正动手时，门道多得能写成书。尤其是 Oracle，它在企业级市场里占了半壁江山，从老版本到新版本、从物理环境到云上，迁移需求越来越多。我的朋友公司用的是 Oracle 11g，系统跑了快十年，数据量接近 5 TB，业务部门天天抱怨查询慢，运维也担心硬盘哪天会坏。老板拍板决定迁到 Oracle 19c，顺便换个性能更好的服务器。项目批下来，麻烦事儿才真正开始。
迁移前的准备，很多人容易走两个极端：要么觉得“直接导数据就行”，要么过度规划搞出一堆文档。其实最关键的是先摸清楚现状。我的第一件事就是让朋友把数据库的架构图、表空间分布、用户权限清单、存储过程等全部导出来。不看不知道，一看吓一跳——他们库里有十几个老旧索引，有些表甚至十年没动过，还有一堆废弃的定时任务。这些冗余东西如果直接迁过去，新库照样慢。更坑的是，他们有些表用了 Oracle 11g 才支持的特定分区功能，而 19c 的分区语法有调整。如果不提前做兼容性检查，迁移后跑不起来，那才叫欲哭无泪。所以第一步，花一周时间做审计，把需要清理、重构的内容列清楚，比急着动手重要得多。
迁移方案的选型是决定成败的关键一步。市面上工具不少，Oracle 官方有 Data Pump、RMAN，还有 GoldenGate；第三方工具如 AWS DMS、SQL Developer Migration 也常见。但具体选哪个，要看业务容忍度。朋友公司业务是 24 小时的电商平台，停机时间不能超过半小时。那 Data Pump 这种全量导出导入就不行了，3 TB 数据光导出就要几个小时。我建议用 GoldenGate 做实时同步，先搭建一个准实时的备库，等数据追平后再切换短窗口。这种方案代价高，GoldenGate 配置复杂，需要额外授权，但能保证业务几乎不中断。如果业务能接受几小时停机，RMAN 做全量备份恢复就更省事，成本低，操作也简单。选方案时，别只听厂商吹，要结合自己的业务现状和数据量来决定。
测试迁移这一步，很多人图省事直接跳过，觉得“反正生产环境早晚要跑一遍”。这种想法太危险。我朋友一开始也想省事，被我硬拉着做了三轮测试。第一次用一小部分数据，验证兼容性和脚本能否跑通；第二次模拟全量数据，测试网络带宽和磁盘 I/O 瓶颈。结果发现他们内网带宽只有 1 Gbps，全量迁移要跑十几个小时，赶紧找网络部门把链路升级到 10 Gbps，才勉强达标。第三次做了回滚演练，模拟迁移失败后的恢复。这一步特别重要，万一迁移中断，必须保证业务能回退到老库继续跑。测试时要记录每一步的耗时、错误日志，甚至监控 CPU、内存、I/O 的变化，这些数据后面可用于调优。
正式迁移那天，我和朋友团队开了作战会议，把流程拆成小时级节点。先停掉非核心业务，把老库切换到只读模式，启动 GoldenGate 同步。数据追平后，进行数据一致性校验，用 checksum 对比关键表的记录数。这一步不能省，我发现有些表在同步过程中因为网络抖动丢了几行数据，多亏校验及时发现。随后切应用连接，修改 DNS 和配置文件，新库上线。整个过程花了差不多 4 小时，但实际停机窗口只有 15 分钟——就是只读模式到验证通过的这段时间。当然，中间也出现了小插曲：有个存储过程的游标在 19c 里报错，因为旧版语法被废弃。幸好提前准备了应急脚本，现场改代码重新编译，问题立刻解决。
迁移后的优化容易被当成收尾工作忽视。实际上，新环境需要重新做性能调优。Oracle 19c 的优化器比 11g 智能很多，但统计信息、参数配置都得重新调整。我让朋友跑了一周业务，然后分析 AWR 报告，发现有些 SQL 在新库上执行计划变了，原本走索引的变成了全表扫描。这主要是因为新版本的统计信息收集策略不同，需要手动刷新或设置固定计划。另外，存储和网络层面也要跟进，比如新库使用 SSD，I/O 参数要从 HDD 模式改成 SSD 优化。这些细节调完后，查询响应时间从原来的平均 200 毫秒降到 50 毫秒，业务部门终于满意了。
回顾这次迁移，最深的体会是：技术方案再牛，也架不住规划和测试不到位。很多人以为数据库迁移就是搬运活，其实更像一次系统重构。必须把老库里的垃圾清理掉，把不兼容的地方改掉，还要保证新库跑得比老库快。这背后是对数据库架构、业务逻辑、硬件性能的综合理解。团队协作也很关键，DBA、网络工程师、应用开发、运维，少一环都可能卡壳。朋友公司这次还能算顺利，主要因为前期沟通充分，每个环节都有对接人。如果中间有人掉链子，后果可能是业务中断几小时，甚至数据丢失。
说点实在的：如果你也在计划 Oracle 迁移，记住三件事。第一，别迷信工具，再好的工具也需要人配合。Data Pump 快，但遇到大表分区不兼容仍会报错；GoldenGate 稳，但配置复杂，没经验的人搞不定。第二，测试比实施更重要，宁可多花一周测试，也别省那三天时间。第三，给自己留条后路，回滚方案必须写进计划，没人能保证 100% 成功。数据库迁移这活儿，干好了没人夸你，干砸了所有人都会找你算账。但如果真的能平稳落地，那种成就感，比写一万行代码还过瘾。
