上周帮朋友搞了个数据库迁移，场景挺常见：一台老旧的 Linux 服务器跑了五年 Oracle，硬盘 I/O 开始报警，CPU 动不动就飙到 90%。客户的要求也很直接——换台新机器，数据不能丢，业务停机时间不能超过 4 小时。这种活儿在 DBA 圈子里叫“换血”，听着简单，做起来全是坑。
先说迁移前的准备工作。很多人一上来就想跑 expdp 或者 RMAN，结果发现源库版本是 11.2.0.4，新机器装的是 19c，直接导数据会报字符集不兼容。我习惯先在新服务器上搭好相同版本的 Oracle 环境，最好打上最新的 PSU 补丁。检查一下源库的归档模式、字符集、表空间大小，并把这些信息记下来，后面做参数比对用。有个细节容易忽略——源库的 redo log 大小。如果新机器磁盘性能更好，可以适当调大 redo 文件，能提升后续导入速度。我当时把 redo 从 1 GB 调到 4 GB，导入时间缩短了将近 20%。
真正动手迁移时，我选的是 RMAN 备份恢复配合数据泵的组合拳。先在新服务器上安装相同版本的 Oracle 软件，然后用 RMAN 做全库备份，把备份集拷贝到新机器。这里有个坑：新机器的目录路径必须和源库一致，否则 RMAN 恢复时会报路径不匹配。如果路径不一样，就得用 命令手动重定向。我当时因为新机器用了 SSD，分区结构变了，只能挨个文件指定新路径，花了半小时。恢复完成后，用数据泵导入用户数据，这样能规避一些 RMAN 跨版本恢复的隐患。
迁移过程中最头疼的是数据一致性。我见过有人直接用 expdp 全库导出，结果业务还在写入，导出的时间点对不上。正确做法是先停止应用，用 冻结数据文件，再用 RMAN 做在线备份。如果业务不能停太久，可以用 OGG 或者 Data Guard 做实时同步，但那种方案太复杂，小项目用不上。这次我采用折中方案：半夜三点停应用，做全库导出，同时记录 SCN 号，恢复时用 Flashback 闪回到那个时间点，保证数据不丢。
性能调优这块很多人容易忽略。数据迁移完成后直接跑生产业务，结果发现同样的查询在新机器上慢了 30%。问题出在统计信息上——旧库的统计信息不适用于新硬件。我习惯在导入完成后，用 包重新收集所有表的统计信息，包括直方图。另外，新机器的内存、CPU 配置不同，需要调整 和 参数。我把 SGA 从 8 GB 提到 16 GB，PGA 从 2 GB 提到 4 GB，查询响应时间从原来的 2 秒降到 0.8 秒。还有个技巧：检查新机器的 NUMA 架构，如果启用了 NUMA，建议把 Oracle 实例绑定到特定节点，避免跨节点内存访问导致性能抖动。
业务验证环节最容易翻车。数据导进去，应用连上了，但跑个简单的 SELECT 就报 ORA‑00942 表或视图不存在。大概率是用户权限没迁移完整。我习惯在迁移完成后，用 expdp 导出一份元数据日志，对比源库和新库的用户、角色、同义词、DBLINK 等对象。特别是 DBLINK，很多项目依赖远程数据库连接，迁移后忘了重建，应用直接报错。我当时还踩了个坑：源库有个自定义函数引用了 Java 存储过程，新机器没装 Java 组件，函数编译失败。后来补装了 组件才解决。
回滚方案一定要提前准备。迁移不是一锤子买卖，搞砸了得能退回去。我通常在新机器上完成导入后，保留源库的 RMAN 备份和归档日志，至少保留三天。如果新库跑了两天发现性能还不如旧库，或者业务报数据不一致，直接切回旧库。不过回滚有个前提：旧库在这段时间内不能做结构变更。我见过有人回滚时发现归档日志被删，无法做完整恢复，只能从备份里恢复数据，丢了半天业务。因此迁移前一定要跟业务方确认：迁移期间禁止任何 DDL 操作。
说说那些看似不起眼但能救命的细节。迁移完成后，记得检查监听器配置，确保 里的主机名、端口号都正确。还有，新机器的防火墙规则可能屏蔽了 Oracle 端口，我当时忘了放行 1521 端口，应用连不上，排查了半小时才发现。另外，建议在 crontab 里加上数据库备份脚本，别等出了事再想起备份。如果使用的是 Linux 系统，别忘了检查内核参数，如 和 ，这些默认值可能不适合 Oracle 运行大业务。
数据库迁移这事儿，说到底是体力活，但每个步骤都可能藏着雷。我的经验是：别迷信自动化脚本，手动检查每一步的产出，尤其是日志文件里的警告信息。比如 RMAN 恢复时出现 “file needs more recovery” 这种提示，别看表面成功了。这次帮朋友搞完后，他反馈说新机器跑了两周，性能稳定，没出过问题。我也没跟他提那些加班排查的晚上——干这行的，习惯就好。
