接到这个活儿的时候，我正对着电脑屏幕发呆——Oracle数据库迁移，这事儿说起来简单，做起来全是坑。你想想，一个企业跑了好几年的系统，数据量动辄几百GB甚至TB级别，迁移过程中哪怕丢一条记录，都可能让财务对不上账、让用户登不上系统。所以，我打算用最实在的方式，把迁移这活儿掰开揉碎了讲给你听。
咱们先从最基础的说起：迁移前得摸清家底。别上来就想着怎么导数据，先搞清楚你手里是个什么数据库。我见过太多人，连表空间大小、索引数量、存储过程行数都没统计，就开始跑迁移脚本，结果半路卡住，进退两难。你该做的第一件事，是用查清楚所有数据文件的位置和大小，再用看看表空间的使用率。这就像搬家前先量好门框尺寸，不然沙发搬不进去，你只能干瞪眼。
确认完基础信息，下一步就得选迁移工具。市面上选项不少，但别被花里胡哨的功能迷了眼。Data Pump是Oracle官方自带的，稳定可靠，适合大多数场景；GoldenGate适合需要零停机的高可用场景，但配置复杂得像解数学题；还有第三方工具如Navicat、DBeaver，适合小规模数据。我的建议是：数据量在100GB以下，用Data Pump的expdp/impdp组合；超过1TB，考虑用RMAN做物理备份恢复；要是遇到跨版本迁移（比如从11g到19c），必须先用检查兼容性，不然导进去一堆报错，你哭都来不及。
工具选好了，接下来是最容易翻车的环节：制定迁移计划。别想着周末下午三点开始，周一早上八点前搞定——这种理想主义在数据库迁移里活不过两集。你得先评估业务容忍的停机时间：如果是电商平台，黄金时段停机一小时，损失可能就是几百万；如果是内部OA系统，半夜停机四小时，大家顶多吐槽两句。我习惯的做法是：先做一次全量预迁移，记录耗时和错误日志；再根据预迁移结果，把正式迁移安排在业务低谷期，比如周五晚上十点到周六凌晨六点。别忘了，你还要预留两小时的回滚时间——万一出问题，至少能退回去。
正式开始迁移前，还有个关键动作：数据一致性检查。别以为expdp导出来就万事大吉，Oracle的SCN（系统变更号）机制决定了数据一致性是动态的。你需要在源库上执行强制写入所有脏数据，再用记录当前SCN。导出时加上参数，确保导出的数据是那个时间点的快照。我当年迁移一个银行的交易系统，就是因为没做这一步，导致迁移后对账差了47笔交易，排查了整整两天才找到原因。
数据导出完成后，别急着往目标库导入。先检查目标库的环境配置：字符集是否一致？对比源库和目标库的NLSCHARACTERSET；表空间是否创建？别指望impdp会自动建表空间，你得先手工建好对应的表空间和数据文件；权限是否足够？确保导入用户有DBA或至少IMPFULLDATABASE角色。这些细节看起来繁琐，但少一个都可能让导入到一半就报错——比如字符集不匹配导致中文乱码，你到时候改起来比重新导一遍还费劲。
导入过程同样需要精细操作。用impdp时，记得加上和参数，把源库的模式和表空间映射到目标库。如果你要跨平台迁移（比如从Windows到Linux），还得处理大小写敏感问题——Windows下Oracle默认不区分大小写，Linux下却区分，这会导致存储过程找不到对象。我的经验是：导入前先把目标库的设为FALSE，导入完成后用重新编译所有无效对象。另外，别忘了用参数加速导入，但别超过CPU核心数的两倍，不然IO会成为瓶颈。
数据导入完成后，你以为就结束了？最忙的环节才刚刚开始。先做数据校验：在源库和目标库分别执行，对比关键表的数据行数和校验和。如果业务允许，还可以抽几个核心交易流程跑一遍回归测试。然后是性能调优：用重新收集统计信息，把执行计划刷成最新的；检查索引是否失效，这条SQL你得跑三遍。我见过最坑的情况是：数据全导进去了，但查询比原来慢了十倍，原因是统计信息还是旧的，优化器选错了执行路径。
这也是最容易被忽视的一步：切换后的监控与回滚预案。迁移完成后，至少需要监控48小时：看alert日志有没有ORA-错误，看AWR报告里等待事件是否异常，看连接池是否有断开重连。同时，你得准备好回滚脚本——不是心理安慰，是真得能跑通。我建议在正式切换前，把源库的完整备份做个快照（比如用ZFS或存储卷的快照功能），这样一旦发现问题，可以在十分钟内回退到切换前的状态。记住，数据库迁移不是百米冲刺，而是马拉松——跑得快不重要，跑得稳才关键。
写到这里，我想起刚入行时带我的老DBA说过的话：“数据库迁移，七分准备，两分执行，一分运气。”这句话至今受用。你掌握了这些步骤，至少能避开90%的坑。但别指望看完一篇文章就成为迁移高手——每个数据库都有自己的脾气，多练几次，多踩几个坑，你才能真正做到安全高效。
