Oracle 11g数据库迁移这事儿，我干过不少二十次。每次接到任务，客户第一句话都是“数据不能丢，业务不能停”。说实话，这话听着简单，真要落地，就得把每个环节都抠细了。11g虽然是个老版本，但企业里用它的真的不少，尤其是那些核心系统——财务、ERP、CRM——全压在这上面。迁移不是把数据复制过去就完事儿，你得考虑兼容性、停机时间、回滚方案，甚至还要防着那些十年没碰过的存储过程突然报错。今天我就把实战经验掰开揉碎，跟你聊聊怎么平稳高效地完成这件事。
第一步，先弄清楚手头的数据到底有多大。别小看这个，很多团队一上来就选工具，结果发现数据量超过 5 TB，用传统 exp/imp 导出导入，光导出就得跑两天两夜。我见过一个案例，某保险公司用 11g 存了八年保单数据，单表最大的有 2 亿行，他们最初想用 Data Pump 直接迁移，结果跑了 36 小时还没完，中间网络闪断一次，全部得重来。后来我建议他们先压缩数据，再用并行度调优，把时间压到 8 小时。具体操作很简单：导出时加 compression=all，导入时设 parallel=4，配合 direct‑path，速度能翻倍。但并行度别超过 CPU 核数的一半，否则 I/O 会堵死。
接下来，环境差异是最大的坑。11g 在 Windows 和 Linux 上的表现完全不同，尤其是字符集和时区设置。有个真实教训：某电商公司迁移时，源库是 AL32UTF8，目标库是 ZHS16GBK，结果所有用户姓名全变成乱码。他们花了三天才排查出来，只能回滚。正确的做法是迁移前用 查清字符集，如果不一致，就用 DBCA 重建目标库，或者在 Data Pump 中使用 参数转换。另外，时区也必须对齐，特别是涉及时间戳的业务，差 8 小时这种低级错误我见得太多。
测试环境不能省，但很多人把测试做成形式主义。我见过最离谱的，测试只验证了表结构和行数，上线后才发现某个触发器在新库上跑不了，因为 11g 的某些函数在不同版本里行为变了。比如 在 11g 里对 NULL 的处理就和其他版本不一样。我的做法是：先做全量数据比对，用 自动比对两边的表记录，差异超过 0.1 %就报警；然后跑一遍核心业务流程，从登录到报表生成，每个步骤截图保存；再进行压测，用 LoadRunner 模拟高峰流量，看看目标库能否扛住。这一步至少花一周，但能帮你躲开 90 % 的坑。
停机窗口是绕不开的痛点。业务部门永远要“零停机”，但现实是数据量大时，全量迁移加增量同步很难在几小时内完成。我常用的策略是“两步走”：先做一次全量迁移，跑完后再做增量同步，使用 Oracle GoldenGate 或 Data Guard 的物理备库方式，把变更日志实时传到目标库。这样停机窗口只需要增量应用的时间，通常不超过 30 分钟。具体操作：迁移前配置好日志归档和捕获进程，全量完成后启动应用进程，等两边数据一致后直接切换。注意，如果源库是 RAC 环境，GoldenGate 配置要小心节点切换问题。
回滚方案不是备胎，而是底线。我见过一个团队迁移时没做回滚，结果上线后发现性能不如旧库，想回退时源库已经被清理，数据丢了三天，CEO 亲自道歉。我的标准做法是：迁移前给源库做一次冷备，用 RMAN 备份到独立存储；迁移过程中保留所有日志和归档；目标库上线后，保留源库运行至少两周，期间不开清理脚本。万一出问题，直接恢复 RMAN 备份，最多只会丢几小时的数据，业务能立刻恢复。另外，迁移前给所有关键表做一次逻辑备份，用 expdp 导出一份 dmp 文件，作为保险。
性能调优是迁移后最容易忽视的环节。很多人以为数据过去了就完事，结果发现同样的 SQL 在旧库跑 0.1 秒，新库却跑 10 秒。原因通常是统计信息没更新，或者分区策略变了。11g 的 CBO 优化器依赖统计信息，迁移后必须跑一遍 ，否则执行计划全是错的。我习惯用 对比关键查询的路径，如果出现全表扫描，就检查索引是否重建。另外，如果目标库是 Exadata 或新硬件，可能需要调整并行度和内存参数，例如把 调大 50 %，但别超过物理内存的 80 %。
文档和交接不能写成流水账。我见过最差的交接文档，只写“迁移完成，目标库正常”，连 IP 地址都写错。合格的文档应该包含：迁移前后环境对比表（IP、端口、目录结构、参数文件）、操作步骤清单（精确到每条命令）、回滚手册（图文并茂）、压测报告（含截图和数据）、问题记录表（问题、解决方案、责任人）。特别是问题记录，很多人觉得丢脸就不写，但下次别人踩坑时，这些记录就是救命稻草。我习惯把文档写成一个“踩坑指南”，比如“注意：目标库的 默认是 DB，容易撑爆 表空间，记得改成 OS 级别”。
说到底，Oracle 11g 数据库迁移这事儿，技术方案网上能抄到，但真正决定成败的是细节把控和风险意识。每次迁移，我都把自己当成凌晨三点被电话叫醒的人，把所有可能出问题的地方提前堵住。数据无缝过渡不是口号，而是你把每个环节都当回事之后的自然结果。下次接到迁移任务，别急着选工具，先问自己：回滚方案写好了吗？测试环境跑过极限场景吗？如果业务问“万一出问题怎么办”，你能脱口而出答案吗？只要能清晰回答这三个问题，这活儿你就接得住。
