做数据库迁移这事儿，很多人上来就慌，觉得Oracle这玩意儿太庞大、太复杂，动不动就是几十个T的数据，几百张表，加上各种存储过程、触发器、作业调度，光想想就头疼。但说穿了，迁移的本质就是把数据从一个地方搬到另一个地方，关键是你得把规划想清楚。我见过太多团队，前期没规划好，上了生产环境才发现字符集对不上、主键冲突、时间戳乱了，只能回滚，浪费的不仅是时间，还有客户的信任。
第一步，你得搞清楚迁移的动机。是为了上云？还是换硬件？或者是做版本升级？不同的动机直接决定了你的技术选型。比如你从Oracle 11g迁到19c，那可以用Data Guard做物理同步，在线切换，几乎零停机。但如果是跨平台迁移，比如从Linux迁到Windows，那物理方案就不好使了，得用逻辑导出导入或者GoldenGate。我有个朋友去年做金融系统的迁移，就是因为没分清物理和逻辑的区别，用了Data Guard做异构迁移，结果数据文件格式对不上，折腾了两周才搞定，气得他直拍桌子。
数据迁移最怕什么？最怕的是你以为迁移完了，结果业务跑起来报错。所以第二步，你必须做详细的源端评估。别光看表结构，要看索引、约束、触发器的依赖关系。Oracle的序列、同义词、物化视图，这些东西经常被人忽略。我建议你先跑一遍Oracle的DBMSMETADATA.GETDDL，把所有对象的DDL都导出来，然后用文本对比工具跟目标库的结构做比对。别嫌麻烦，这一步省了，后面全是坑。还有数据量，别只看表的大小，要看行数、分区情况、LOB字段的存储方式。有个客户曾经迁移一张有CLOB字段的表，因为没注意段空间管理方式，结果迁移到目标库后，CLOB字段全部变成空值，数据丢了整整三天。
第三步，你得选对迁移工具。Oracle官方给的工具不少，Data Pump、SQL*Loader、GoldenGate，还有RMAN。但这几个东西各有各的脾气。Data Pump适合全量迁移，速度快，支持并行，但数据类型转换有时候会出幺蛾子。GoldenGate适合增量同步，适合做不停机迁移，但配置复杂，对网络带宽要求高。我个人的经验是，如果数据量在10T以下，业务允许停机几小时，直接用Data Pump做全量导出导入最简单。如果数据量大，或者要求零停机，那就用GoldenGate做全量加增量，先全量同步一次，再实时同步增量日志，做切换。
有个案例特别典型。一家电商公司在双十一前要做数据库迁移，数据量大概8T，业务要求停机时间不超过30分钟。他们选了GoldenGate方案。先花了两周做全量数据同步，然后开了实时增量。到了切换那天，他们发现GoldenGate的进程卡住了，原因是源库的归档日志被删了，GoldenGate追不上。只能紧急回滚，双十一当天用老库扛着，差点出事故。这个教训告诉我们，用GoldenGate之前，一定要跟DBA确认归档日志的保留策略，至少要保留到增量同步追上为止。
第四步，测试和验证不能走过场。很多人觉得数据迁移完了，查一下行数对上就行了。这太天真了。你要验证的是业务逻辑，不是数据量。比如订单表，你要随机抽几条订单数据，从创建到付款到发货，走一遍完整的业务流程，看看状态流转对不对。存储过程里的游标、异常处理，也要全部跑一遍。我建议你写一个自动化脚本，把源库和目标库的表数据做逐行比对，用MD5或者RMAN的校验功能。别嫌慢，这一步是保险。有个团队迁移完，业务跑了一周才发现，所有的日期字段都差了8小时，因为源库用的是本地时区，目标库用的是UTC，转换规则没配好。
第五步，切换流程要像手术方案一样精细。什么时候开始停止业务写入？多长时间完成一次增量同步？切换后多久回滚？这些时间点都要精确到分钟。我见过最靠谱的切换方案，是提前三天做了一次全量预迁移，然后每天做增量同步，切换当天只花10分钟做一次增量同步，然后直接改DNS指向新库。还有个团队更绝，他们用GoldenGate做了双向同步，切换后如果发现问题，还能再切回去，相当于有个保险绳。当然，双向同步的代价是配置更复杂，资源消耗也更大。
迁移完不代表结束，你还要做一段时间的并行运行。新库上线后，别急着把老库删了。让业务在新库上跑一两天，同时把老库的只读快照保留着，方便随时对比数据。我建议你监控新库的AWR报告，看看SQL执行计划有没有变化，索引有没有失效，统计信息有没有更新。Oracle的优化器特别敏感，同样的SQL，换个环境执行计划就可能变。有个客户迁移后，一个原来跑0.1秒的查询，在新库上跑了10秒，原因是统计信息没收集，优化器走了全表扫描。所以迁移完成后，强制做一次全库的统计信息收集，很有必要。
数据库迁移这事儿，说难不难，说简单也不简单。核心就三点：搞清楚动机、选对工具、做好验证。别想着一步到位，也别指望工具能解决所有问题。该手动检查的地方，一个字都别省。毕竟数据是企业的命根子，出了事没人能帮你兜底。
