前几天帮一个做电商的朋友处理数据库故障，折腾到凌晨三点。他那边系统突然崩了，运维跑路，留下的只有一堆 dmp 文件，连说明文档都没有。我盯着那个几 GB 的 dmp 文件，心想要是恢复不了，他今年双十一的数据全得打水漂。这种情况在圈子里很常见，很多公司为了省成本，运维只会半吊子，备份倒是做了，恢复能力却为零。dmp 文件说简单也简单，说坑也坑，关键是要懂它背后藏了多少门道。
dmp 文件恢复的第一步，不是直接敲命令，而是弄清楚这个文件到底是怎么导出来的。我见过太多人一上来就用 imp，结果报错一堆不知所措。exp 和 expdp 虽然都是导出工具，但生成的 dmp 文件格式完全不同。老版本的 exp 是客户端工具，导出的 dmp 在导入时与数据库版本的兼容性差得离谱。比如用 11g 的 exp 导出的文件想恢复到 19c，十有八九会碰到字符集或数据类型的兼容问题。更坑的是，很多人根本没记录导出时的参数，导致恢复时不知道是用 direct=y 还是常规模式。所以拿到 dmp 文件后，第一件事用 strings 命令扫一遍，看看文件头里有没有版本号、字符集、导出模式等关键信息。要是文件头都坏了，就只能做好最坏的打算。
确认完文件状态后，就该决定恢复策略了。这里有个容易被忽视的点：恢复时目标库的表空间必须提前建立好。很多人以为 imp 会自动建表空间，其实不然。如果导出时用了特定的表空间名，而目标库里没有同名表空间，imp 就会把数据丢到用户的默认表空间里。结果数据虽然进来了，但查询性能、分区管理全乱套。我有个客户就吃过这个亏，恢复后发现数据散落在多个表空间，花了整整一个周末重新整理。所以，先查清 dmp 文件涉及哪些表空间，提前建好，规格最好和原库保持一致。
实际操作中，imp 和 impdp 的选择也是个技术活。imp 是传统工具，兼容性好，老版本的 dmp 文件它都能啃下来，但速度慢得像老牛拉车，几十 GB 的文件可能要跑好几个小时。impdp 是数据泵，速度快，但要求客户端和服务端版本匹配，而且文件必须放在数据库服务器的特定目录里。如果在远程机器上操作，还得先把 dmp 文件传到服务器，网络传输的时间足够你喝几杯咖啡。我的经验是，能用 impdp 就别用 imp，除非文件版本实在太老。但要注意，impdp 对字符集的敏感度更高，一旦字符集不匹配，数据乱码的概率比 imp 大三倍。
说到字符集，这是个容易翻车的地方。很多人在恢复时根本不看字符集，结果数据进去了，查询出来全是乱码。dmp 文件导出时，Oracle 会把当前数据库的字符集信息写入文件头。恢复时，imp 或 impdp 会默认用目标库的字符集去解析。如果两个字符集不兼容，比如源库是 ZHS16GBK，目标库是 AL32UTF8，数据就会出问题。解决方案有两个：一是提前修改目标库的字符集，但这操作风险大，需要停机；二是在 impdp 时指定 remap_charset 参数，把数据强制转换成目标库的字符集。我更推荐后者，至少不用动数据库底层配置，出问题还能回滚。
恢复过程中还有个隐藏的坑，就是权限和依赖关系。dmp 文件里可能包含存储过程、视图、触发器等对象。这些东西在恢复时，如果用户权限不够或依赖的表还没导入，就会报错。很多人看到报错就慌，以为文件坏了。其实这往往是 Oracle 的执行顺序问题。imp 在默认情况下是按顺序导入的，如果先导入了依赖视图的表，再导入视图本身，就没问题。但如果顺序反了，视图会因为找不到基表而创建失败。解决办法很简单：可以使用 impdp 的 parallel 参数，或者分两步走——先导入表结构和数据，再单独处理其他对象。我习惯用 sqlfile 参数先生成 DDL 脚本，手动检查依赖关系，再执行导入。
文件大小和恢复时间也是需要考虑的因素。几十 GB 的 dmp 文件，用 impdp 恢复可能只需要一两个小时，但如果是 imp，跑上五六个小时很正常。而且恢复过程中最怕中断，网络波动、磁盘空间不足、用户操作失误都可能导致失败。一旦中断，之前的时间全白费。所以恢复前一定要检查磁盘空间，至少预留 dmp 文件两倍以上的容量。另外，最好在恢复前设置一个回滚段，这样即使出问题，也能快速清理已导入的数据，避免留下垃圾表。我自己吃过这个亏：一个 50 GB 的文件恢复到 80% 时断了，结果数据库里多出一堆没有索引的表，清理起来比重新导入还麻烦。
还有一点容易被忽略：恢复完成后一定要做验证。很多人数据导进去就觉得大功告成，结果一个月后才发现某个表少了十万条。dmp 文件恢复不是简单的复制粘贴，它涉及数据类型转换、约束检查、索引重建。有时 imp 会忽略外键约束，导致数据完整性受损。我的做法是，恢复完成后，用 PL/SQL 或 sqlplus 对关键表做 count(*)，与源库的备份清单对比，同时检查 alert 日志，看有没有 ORA-00600 之类的内部错误。如果一切正常，才算真正恢复成功。否则，那个 dmp 文件随时可能变成定时炸弹，在最需要数据的时候炸得你措手不及。
那天的故障处理，花了整整一天才把数据全捞出来。朋友请我吃了顿饭，席间感叹说，早知道当初就该让我帮忙搭个灾备系统。我笑着说，现在知道也不晚，至少你手里还有 dmp 文件。但很多人连这道防线都没守好，备份了等于没备份。所以，别把 dmp 文件恢复想得太简单，也别把它想得太复杂。该花的功夫一点不能省，该做的验证一步不能少。数据库这东西，从来都是细节决定成败。
