这事儿我琢磨了挺久，还是得从一次亲身经历说起。前阵子帮朋友公司处理 Oracle 11g 数据库迁移，那叫一个折腾。他们的系统跑了好几年，数据量堆到快两个 TB，应用层五花八门，有的还是老掉牙的 Java 1.6。迁移方案选来选去，最终决定从物理服务器迁到云上，目标版本是 19c。你猜怎么着？光做兼容性测试就花了三周，因为几个存储过程里用了 11g 特有的语法，19c 直接报错。这事让我意识到，迁移不是单纯的技术活，而是“考古”活——得把那些尘封的代码、配置、依赖全翻出来，逐个检查，一不留神就会踩坑。
很多人觉得数据库迁移就是“导出‑导入”三板斧，逻辑简单得很。但现实里，这玩意儿比拆炸弹还刺激。11g 时代，很多企业喜欢搞自定义函数、分区表，甚至直接操作 Oracle 的隐藏参数。这些“野路子”在旧环境里跑得欢，一迁到新版本，轻则性能下降，重则直接宕机。比如分区表，11g 支持的分区类型和 19c 不完全一样，数据格式有细微差别，迁移时如果用了 expdp/impdp，部分分区索引可能重建失败。再比如字符集，很多老库用的是 ZHS16GBK，目标库要是 UTF8，转换时一个不小心，中文数据就会乱码。这些坑文档里写得清清楚楚，但实际动手时，总有人觉得“应该没问题”，结果半夜三更被电话叫醒。
迁移的另一个大坑是停机窗口。很多企业要求业务中断不能超过 4 小时，可 11g 迁移到 19c，光全量数据导出就可能超过这个时间。朋友公司那 2 TB 数据，用 expdp 单进程导出，跑了 6 个多小时。后来没办法，只能上增量同步——先全量导一次，然后靠 Data Guard 或 GoldenGate 实时同步增量数据，在窗口内切库。这招听起来简单，但配置 GoldenGate 时，需要处理 11g 特有的归档日志格式和表结构变更的同步，一个参数设错，数据就会丢失。更头疼的是，迁移后还得做数据校验，比如比对表行数、校验和，这些操作本身也耗时，必须提前规划好脚本和资源。
性能问题也是迁移后的大考。11g 的优化器版本和 19c 差了好几代，同样的 SQL，执行计划可能大变样。朋友公司有个核心报表，以前跑 3 分钟，迁完直接变成半小时。查了半天，发现是一个索引的统计信息没更新，19c 自动选择了全表扫描。这种问题靠 DBA 手动调优根本忙不过来，得提前在测试环境做全量 SQL 回归，用 Oracle 的 SQL Tuning Advisor 跑一遍，找出执行计划变化的语句，提前加索引或改参数。更狠的做法是直接冻结优化器版本，比如设置 optimizerfeaturesenable='11.2.0.4'，但这样一来，19c 的新特性全废了，等于白升级。
别忘了那些“隐形”的依赖项。很多业务系统里，数据库和应用层之间还有中间件、ETL 工具、定时任务。比如用 crontab 调 SQL*Loader 的脚本，迁移后路径变了，加载失败。或者用 ODBC 连接的老系统，新库的监听配置改了，连不上。这些细节光靠 DBA 一个人盯不过来，必须拉上开发、运维，甚至业务方一起过流程。朋友公司有个财务系统，迁移后对不上账，查了两天才发现是凌晨跑批的存储过程里，有个时间函数在新环境里返回了不同格式。这种问题在测试环境根本测不出来，因为测试数据量少，时间范围窄。
安全合规这块也常被忽略。11g 的审计功能相对简单，很多企业直接用默认配置。但 19c 的审计策略更严格，比如强制开启统一审计，旧系统里的细粒度审计策略可能不兼容。迁移后合规审计一查，发现日志不全，又得返工。更麻烦的是加密和脱敏——有些老系统用 DBMSOBFUSCATIONTOOLKIT 加密数据，这个包在 19c 已经废弃，必须改成 DBMS_CRYPTO。改起来倒不难，但涉及历史数据的解密再加密，操作不当就会锁表。朋友公司就被这个坑过，一个月的财务数据全乱了，靠备份恢复才救回来。
说到底，数据库迁移这事儿，技术只是表面，核心是管理。你必须有清晰的回滚方案——万一迁移失败，怎么在 4 小时内切回旧库？备份要留好，恢复脚本要提前测试。还要有沟通机制——谁负责通知业务方，谁盯日志，谁处理报错，都得提前确定。朋友公司那次迁移采用“滚动升级”的思路：先迁一个非核心模块，跑两周稳定了再迁核心业务。虽然总耗时拉长到两个月，但风险降了一大截。这让我想起一句话：数据库迁移不是终点，而是新老系统磨合的开始。那些看似繁琐的测试、回滚、校验，实际上是在为未来的运维铺路。要是图省事跳过哪一步，迟早会加倍还回来。
