这事儿得从头说起。去年秋天，我接手了一个让人头疼的项目——把一套跑了快十年的 Oracle 11g 数据库搬到新环境。客户那边的 IT 主管一脸愁容地告诉我，这套库支撑着他们的核心 ERP 系统，每天几千人同时在线，出一点岔子就得上新闻。我看了看数据库的版本，11.2.0.4，2013 年出的，连补丁都停更好几年。说实话，这种老库就像开了十几年的老车，看着还能跑，但谁也不知道什么时候会抛锚。客户想升级，却又怕动手术，折中方案是：先平行迁移到新服务器，跑稳了再考虑升级到 19c。
迁移的第一步，其实不是敲键盘，而是翻家底。我得搞清楚这库到底有多老——不光是版本，还有那些年积攒下来的“历史遗留问题”。比如，有些表空间用了古董级别的 ASSM（自动段空间管理），但参数配得乱七八糟；有些索引碎片率超过 70%，重建一次得花一个周末。最要命的是，里头还有一堆过时的数据类型，像 LONG 和 LONG RAW，Oracle 官方早就不推荐用了。我花了整整两天，用自己写的一套脚本跑遍了全库，把表结构、索引、约束、存储过程、定时任务全捋了一遍。结果发现，光存储过程就有 800 多个，很多还是十年前的开发人员写的，注释全是拼音加英文混搭，读起来像考古。
真正的迁移方案，我选了 Data Guard 物理备库加切换的方式。为什么不用逻辑迁移？因为这套库的数据量接近 3TB，逻辑导出导入得跑好几天，中间还得停业务，客户受不了。Data Guard 的好处是，主库跑着，备库在后台同步，切换时只停几分钟。但我得先解决一个老问题：主库和备库的硬件配置不一样。主库是旧的 HP 服务器，备库是新买的华为鲲鹏，CPU 架构不同。Oracle 虽然支持异构平台，但 11g 的 Data Guard 在跨架构时有个坑——必须用相同的字节序。好在都是小端序，问题不大，但为了保险，我特意在测试环境跑了两轮全量同步，确认没有数据差异。
同步过程比预想的要折腾。备库搭起来后，实时应用重做日志时，三天两头报 ORA-00600 错误。这错误是 Oracle 的“万金油”报错，啥都能往里装。我翻日志一看，原来是主库上有几个坏块，平时查不到，但 Data Guard 在应用日志时就会暴露。于是先修主库。我用了 RMAN 的块介质恢复，把坏块对应的数据文件单独修复了一遍。这个工作必须在业务低峰期进行，因为恢复时会影响对应表空间的查询。凌晨两点，我盯着屏幕，看着 RMAN 一行行输出 “media recovery complete”，后背全是汗。修完后，备库同步终于安稳了。
切换那天，我提前两周就和客户排好了停机窗口。凌晨一点，业务部门确认所有在线用户都退出了，我开始操作。先切掉应用端的连接，然后让主库做一次手动日志切换，确保所有数据都写进去了。接着把 Data Guard 配置改成切换模式，让备库变成主库。这一步看着简单，但最怕网络抖一下或者日志断流。我盯着告警日志，心跳跟着输出频率跳。三分钟后，备库成功变成主库，状态是 “ACTIVE”。我赶紧让测试组连上去跑几个关键交易，订单、库存、财务都能正常查询。整个过程用了不到八分钟，比预计的十五分钟还短。
但别以为切换完就万事大吉了。新环境跑起来后，第二天就出状况：有个批处理作业比原来慢了将近 40%。我查了半天，发现是新服务器的存储路径变了，导致一个临时表空间的 I/O 性能下降。原来主库用的是 SSD 盘，新库虽然也是 SSD，但 RAID 级别不一样，写入策略有差异。我调了表空间的数据文件分布，把临时表空间挪到单独的磁盘组，然后改了 Oracle 的异步 I/O 参数。再跑一遍批处理，时间恢复到正常水平。这事儿提醒我，数据库迁移不只是搬数据，还得适配新硬件的脾气。
回头看这次迁移，最深的感受是：老库迁移，功夫在事前。我见过太多同行，上来就开干，结果被隐藏的坏块、过时的数据类型、混乱的参数配置折腾得死去活来。Oracle 11g 虽然老了，但很多企业还在用，因为业务稳定，不敢轻易动。但安全漏洞和性能瓶颈摆在那里，迟早得走这一步。我的建议是，迁移前先用工具做一次全面的健康检查，把该修的修了，该清的历史数据清了，别把垃圾也带过去。另外，千万别迷信“零停机”的神话，该停的业务就停几分钟，总比迁移过程中出大事故强。毕竟，数据库迁移这事儿，稳比快重要一万倍。
