做数据库迁移这事儿，干过的人都知道，表面看是个技术活，实际上更像是一场心理战。尤其是 Oracle 到 Oracle 的迁移，看上去都是自家兄弟，应该问题不大吧？可真上手了，从旧库到新库的每一步，都藏着让你头疼的坑。我见过太多人，项目规划做得漂漂亮亮，结果一到正式割接，就出现数据对不上或业务报错，通宵加班，还落得个“技术不行”的骂名。说白了，迁移不是简单搬数据，而是要确保业务平滑过渡，用户几乎感觉不到变化。今天就跟大家聊聊，怎么把这件“瓷器活”干得漂亮，少走弯路。
第一步，别急着动手，先摸清旧库的底细。很多人上来就想着用什么工具、怎么传输，结果做到一半才发现旧库的表空间分区不合理，或者有些表根本没有索引，迁移过去性能直接崩。我习惯的做法是先跑一遍统计信息，看看哪些表数据量大、哪些外键关系复杂。特别要注意那些长年累月堆积的历史表，动不动上亿行，这种表直接用 expdp 全量导出，时间扛不住，中途断了还得重来。这时就得考虑分区迁移或分批抽取。还有那些 LOB 字段，尤其是 CLOB 和 BLOB，处理起来特别慢，得单独规划。再检查一下旧库的字符集，和新库是否一致，不一致的话，数据写入时的乱码问题够你喝一壶的。把这些功课做好，后面才能从容应对。
工具选对了，能省一半的力气。Oracle 迁移工具有不少，Data Pump（expdp/impdp）是最常用的，但别把它当成万能钥匙。我见过有人用 expdp 全量导出 300 GB 的库，结果网络抖动一下，传输中断，又得从头来。所以，对大库建议分表空间导出，或者使用 expdp 的并行参数，配合网络传输的压缩功能。还有一种更稳的方法是用 RMAN 做异构平台迁移，比如从 Linux 到 Windows，这种方式能保证数据一致性，但前提是熟悉 RMAN 的备份恢复流程。如果业务要求停机时间短，就要考虑 GoldenGate 或 LogMiner 做增量同步：先全量迁移，再不断抓取归档日志里的变化，切到新库。别嫌工具多，关键是根据业务容忍度来选。能接受停机 4 小时，就用 Data Pump；只能停机 10 分钟，就得搞实时同步。
数据迁移过程中，最怕的就是“差之毫厘，谬以千里”。我有个血的教训：之前帮一家电商公司迁移订单库，全量跑完后对比，发现少了 2000 多行数据。查了半天，原来旧库里有几个触发器，在导出时没禁用，导致数据在导出过程中被改写。所以，迁移前一定要清理掉那些“捣乱”的触发器、作业和定时任务。序列号（sequence）也要特别注意，迁移后如果序列值没有对齐，新插入的数据可能与旧数据冲突。物化视图的刷新策略是否需要调整，这些细节都要列清单，一条条确认。建议在迁移前先做一次小规模演练，把整个流程走一遍，包括数据校验和应用测试。哪怕花一周时间演练，也比正式上线后出问题强。演练时用真实的数据子集，别用假数据，假数据看不出性能瓶颈。
数据搬完了，新库的配置优化才是重头戏。很多人觉得数据能查能写就完事，殊不知同样的 SQL，在旧库跑 0.1 秒，到了新库可能变成 10 秒。原因很简单：新库的统计信息没有更新，优化器选错了执行计划。所以，迁移完成后第一件事就是收集全库的统计信息，尤其是大表，不能偷懒。另外，检查新库的参数设置，比如 SGA、PGA 的大小，是否与旧库匹配。旧库用了多年，参数调优过无数次，新库默认的参数往往不适合生产。举个例子，旧库开了并行查询，新库默认没开，结果报表跑半天不出数。还有存储过程里的硬编码路径、数据库链接依赖，都要一一检查。我习惯在新库上跑一遍旧库的 AWR 报告，对比负载情况，看看有没有明显异常。
数据校验这个环节，很多人会忽略，觉得工具跑完了就万事大吉。但现实是，哪怕用最成熟的工具，也可能因为网络丢包、磁盘坏道导致数据不一致。因此，校验必须做，而且不能只对行数。我常用的方法是随机抽几张关键业务表，用 checksum 或 MD5 比对整行数据，确保每个字段都一致。对于金额、库存这类敏感数据，还要做交叉验证：比如从旧库跑出总金额，新库再跑一遍，看是否相等。迁移后可能因为数据顺序问题导致外键约束失效，这时要重建索引和约束。校验工具可以使用 Oracle 自带的 DBMS_COMPARISON 包，或者自行编写脚本，核心思路只有一句：信自己，别只信工具。校验完后，还要让业务部门跑一遍核心流程，如登录、下单、查询，确保功能正常。
别忘了回滚方案。迁移这事儿，没有人敢打包票 100% 成功。所以，在正式割接前一定要准备好回滚脚本和数据备份。旧库不要急着下线，保留两三天，万一新库出问题还能切回去。回滚方案不仅要写文档，还要演练一次，确保能在半小时内恢复业务。我见过最惨的情况是，新库迁移完后业务跑了一个小时发现数据不对，旧库已经被清理，只能从头恢复备份，损失了两天的数据。回滚不是备选项，是必选项。迁移完成后，监控系统要第一时间接入新库，关注慢查询、死锁、连接数爆增等问题。通常割接后的 48 小时内是问题高发期，需要有人盯着。
说一千道一万，Oracle 数据库迁移没有捷径，靠的就是细心和预案。从旧库到新库，每一步都像走钢丝，但只要把底细摸透、工具选对、校验做全、回滚备好，这活儿就能干得漂亮。记住一句话：迁移不是为了证明技术多牛，而是让业务在不知不觉中完成升级。能做到这一点，你才算真正掌握了平滑过渡的精髓。下次再有人让你做迁移，别慌，按这个路数来，稳得很。
