1. 先搞清楚 .dmp 文件到底是什么再看怎么打开1.1 .dmp 不是文本文件直接开只会看到一堆乱码在正式开始前说说这个文件到底是个啥。用过数据库导出的人都知道Oracle 备份或迁移离不开 .dmp 文件。它本质上是 Oracle 导出工具把数据库对象表结构、索引、约束、存储过程、视图、同义词、序列等和数据记录按照一种特殊的二进制格式打包后的产物。既然是二进制的用 Notepad、vim 或者 UltraEdit 直接打开大概率会看见“^^”之类的乱码读取不到任何接续信息。早期我干过一个蠢事用 UE 去打开一个 2GB 的 dmp电脑直接卡死最后强制重启。实际上dmp 文件自带了一个文本头部里面记录了“导出工具类型、数据库版本、导出时间、字符集”等信息。这部分内容你用 strings 或者 vim 的二进制模式是能瞄到几行的但完整、准确的内容必须用正规工具去解析。我需要强调的是这里说到的“查看”包含两个层面第一个层面是“文件层面”只看头部和元信息想知道这个 dmp 是哪台服务器、什么版本导出来的。第二个层面是“内容层面”想看清楚里面有哪几张表、每张表的字段和类型、表里的数据行是多少、能不能直接在原库里恢复。多数读者的真实需求是第二层给我一个 .dmp我不用先建库、不用真的导入就能把里面的东西翻出来。这完全可行且方法不止一种。1.2 两类 .dmp 必须分清传统 exp/imp 和数据泵 expdp/impdp这里有一个最大的坑很多刚接触 Oracle 的同行栽在这上面。同样是 .dmp 后缀它们背后的格式完全不同传统 exp/imp导出/导入实用工具从 Oracle 早期版本延续下来的工具通过 SQL 语句逐条读取数据生成的文件可以被 imp 读取。它兼容性比较强Oracle 7/8i/9i/10g/11g 时代的 dmp 文件多数都能用。数据泵 expdp/impdpOracle 10g 开始提供的服务端工具。它导出的是一个带元数据描述符的专用格式普通 imp 根本读不了必须用 impdp 来配合。判断一个文件到底属于哪一类最直接的办法看导出信息。传统 exp 导出的文件在扫描时在头部会打印Export file created by EXPORT:V11.02.00这样的字样数据泵导出的文件会被 impdp 识别为Master table ... present或.dmp中的“DMP”标识。也可以直接看生成工具如果别人交付 dmp 时带着的是 impdp/expdp 命令史那肯定是数据泵如果带的是 exp/imp那就是传统格式。版本问题也要小心。导出工具版本、数据库版本、目标库版本三者之间有一个“下兼容、上不兼容”的规则高版本的 imp 可以读低版本 exp 导出的 dmp低版本的 imp 不能读高版本 exp 导出的 dmpexpdp 生成的 dmp 一般只能由同版本或更高版本的 impdp 读取。这个规则直接决定了你用什么版本的客户端去“查看”。比如别人给你一个 11g 的库导出的 dmp你拿 19c 的 imp 去看大概率没问题反过来拿着 11g 的客户端去读一个 19c 导出的文件就会直接报错。所以开工之前先确认三方版本链条能省掉后面不少排查时间。2. 查看传统 exp 导出的 .dmpimp showy 是核心方法2.1 showy 的原理与参数说明传统 exp 生成的 dmp 文件最正统、最完整的“查看”方式就是使用 imp 命令的 show 模式。show 参数的全称是“仅显示导出文件内容不执行导入操作”。它的原理并不复杂。imp 在解析 dmp 文件时会把其中记录的对象定义和数据记录逐条读出来正常情况下它会把这些内容写入目标库完成导入。但一旦指定showy它就只做“读取和回显”不做任何写入操作。理解了这一点你就明白为什么这个模式开号、锁库、记账等影响什么都不用担心它是一个纯只读的解析动作。典型命令如下imp username/passwordorcl filepath/to/export.dmp showy fully logview.log参数拆解username/passwordorcl任选一个有权限的账号即可实际上 show 模式基本不真正使用网络连接去写库但命令语法还是需要一个合法的 usid。file要查看的 dmp 文件路径。showy打开只读回显模式。fully表示查看整个导出文件的所有对象。如果不写 fully则默认只查看与当前登录用户相关的对象可能会漏掉很多内容。logview.log建议一定加上。直接把屏幕输出重定向到日志文件方便后期搜索、翻页而且几十万行 DDL 在屏幕上滚动谁也看不清。运行完成后view.log 里面就是一份完整的“内容清单”。这份清单包括了导出文件的基本信息导出工具版本、字符集每张表的 CREATE TABLE 语句表数据对应的 INSERT 语句受 rows 参数影响索引、约束、触发器、视图、序列等对象的创建语句所以你看showy 某种意义上就是把 dmp 文件“翻译”成了一本 SQL 脚本书而且用的还是智能翻译不会破坏原文件。2.2 实操把 DDL 和 INSERT 语句完整导出成 SQL 脚本我来演示一个实际场景。假设我收到一个order_export.dmp是 10g 库上用 exp 导出的我现在想知道里面有哪些表以及能不能直接生成一份可以用于重建的 SQL。命令imp scott/tigerorcl fileorder_export.dmp showy fully logorder_view.log日志里会出现类似这样的内容Import: Release 11.2.0.1.0 - Production on 周一 4月 25 10:32:05 2024 Export file created by EXPORT:V10.02.01 via conventional path import done in ZHS16GBK character set and AL16UTF16 NCHAR character set . . importing table ORDER_MAIN 12 rows imported CREATE TABLE ORDER_MAIN (ORDER_ID NUMBER(10, 0), CUSTOMER_NAME VARCHAR2(50 BYTE), ORDER_DATE DATE, STATUS CHAR(1 BYTE)) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 STORAGE(INITIAL 65536 NEXT 1048576 ...) LOGGING . . importing table ORDER_ITEM 34 rows imported注意这段日志里的关键信息第一行EXPORT:V10.02.01说明了这是 10.2.0.1 版本的传统 exp 导出文件按前面的版本对照规则我用 11.2 的客户端来读是没问题的。后面的CREATE TABLE语句就是完整表结构。如果你只想看表结构看这些行就够了。每张表后面跟着n rows imported这是文件里的数据行数统计随后每一行对应一条 INSERT 语句。如果我只想看表结构而不想看几千条 INSERT 语句可以在示例命令后面追加rowsnimp scott/tigerorcl fileorder_export.dmp showy fully rowsn logorder_view_ddl.log这样日志里就只保留 CREATE TABLE、CREATE INDEX 等 DDL 语句日志文件小很多看起来也更清爽。有一个细节值得说show 模式下日志里出现的 row count 是“导出时记录的行数”而不是实际导入的行数因为我根本没有真正导入。但这正是我们想要的“查看”效果不碰库也能知道数据量。2.3 只查看某张表或者某个用户的内容有时候 dmp 巨大光表就有几百张我不想把整个文件全部回显出来只想确认某一张表“在不在文件里、结构对不对”。这种情况不需要看完整库用 tables 或 fromuser 参数做筛选即可。比如只想看 ORDER_MAIN 这张表imp scott/tigerorcl fileorder_export.dmp showy tables(ORDER_MAIN) logorder_main_view.log如果想看某个用户 schema 导出的所有内容imp system/managerorcl fileorder_export.dmp showy fromuserSCOTT logorder_view.log这两个和全量查看的本质区别在于imp 只解析与匹配对象有关的部分日志文件里不会出现其他表的定义定位速度更快。需要提醒的是tables 参数对解析效率有一定好处但它不会跳过对整文件的索引和头部的读取。因为你拿到的还是一个流式文件imp 必须从头扫描判断哪些记录属于目标表。所以即使只看一张表文件特别大时也会有相对明显的读取时间这是正常现象。3. 查看数据泵导出的 .dmpimpdp sqlfile 是正道3.1 为什么 expdp 导出的文件不能直接丢给 imp数据泵是 10g 开始的服务端工具之后的 11g、12c、19c、21c新环境导出基本都走 expdp。如果你拿到一个新的 .dmp 文件却用传统 imp 去“查看”大概率会收到类似消息IMP-00014: 无法使用导入文件或者干脆提示文件格式不对。原因我之前提过expdp 生成的 dmp 是一种带“主表”元数据描述的文件格式只有安装了相同大版本范围的 impdp 客户端才能解析。在查看数据泵文件之前先确认它确实是数据泵格式再准备对应版本的 Oracle 环境或者安装对应的客户端工具是比较稳妥的思路。我在实际工作中经常看到有人把 expdp 的 dmp 改名成 .bak 或者 .tar再拿去给 imp 读取结果报错。其实格式识别不靠扩展名靠的是文件内部的标记是否符合 imp 的解析规则。3.2 用 sqlfile 生成 DDL 脚本数据泵文件无法像传统 exp 那样直接是“print 出 INSERT 语句”这个能力严格来说impdp 的 sqlfile 参数可以把 dmp 中的 DDL 语句提取到服务器上的一个 .sql 文件里但并不支持把表数据INSERT 语句也提取出来。这是它和传统 exp showy 一个很关键的差异。实际操作步骤第一步确认你有一个 directory 对象便于命令直接引用文件路径。例如CREATE OR REPLACE DIRECTORY DUMP_DIR AS /data/dump; GRANT READ, WRITE ON DIRECTORY DUMP_DIR TO scott;第二步执行 impdp指定 sqlfileimpdp scott/tigerorcl DIRECTORYDUMP_DIR DUMPFILEorder_export.dmp SQLFILEview_script.sql这里注意sqlfile 文件名是写在服务器磁盘上的不是本地DUMPFILE 中的 dmp 文件也必须放在 DUMP_DIR 对应的操作系统目录中。执行之后在 /data/dump 下会生成 view_script.sql里面是完整的 DDL 语句包括CREATE TABLE SCOTT.ORDER_MAIN ... CREATE INDEX SCOTT.IDX_ORDER_MAIN_DATE ... CREATE OR REPLACE TRIGGER SCOTT.TRG_ORDER_MAIN ...还可以组合 include 或 exclude 参数只提取想要的对象类型。比如只生成表的定义impdp scott/tigerorcl DIRECTORYDUMP_DIR DUMPFILEorder_export.dmp SQLFILEview_table.sql INCLUDETABLE或者只看索引impdp scott/tigerorcl DIRECTORYDUMP_DIR DUMPFILEorder_export.dmp SQLFILEview_index.sql INCLUDEINDEX这种精确提取在排查问题时非常有用比如怀疑索引没导出直接跑一条查看索引的 SQLFILE 命令几十秒就能验证不用等全量导入。3.3 sqlfile 的局限性与替代方案前面说到了 sqlfile 不支持提取表数据。那么在 expdp/impdp 体系下如果确实想看看表中数据内容有几种办法用 expdp 在导出时就加上CONTENTDATA_ONLY导出一个只含数据的小 dmp然后再用传统步骤处理但这属于“重新导出”的思路对已拿到手的文件无效直接把 dmp 导入一个临时库再写 SELECT 去查。这个方案最稳代价是必须有一个可用的临时实例使用第三方的 dmp 解析工具后面会单独讲。还有一个小限制是sqlfile 输出的 DDL 和原始文件里的字节码格式可能有些出入特别是在 storage 子句方面。比如文件里导出的表可能带 INITIAL/NEXT/MAXEXTENTS 等存储参数生成的 sqlfile 默认会把它们一并带出来。对于只想看逻辑结构的场景这种噪音反而容易干扰视线。一般我在看结构时都会顺手把日志里的 STORAGE(...) 片段忽略只看字段、类型、约束和索引主体。4. 各种轻量级“瞄一眼”的方法与临时环境实战4.1 用 strings 或文本工具快速识别元信息到了这一章说说不需要安装 Oracle 客户端、也不依赖数据库环境中怎么快速判断一个 .dmp 的出处和内容。Linux 系统里我用得最多的是 strings 命令strings order_export.dmp | head -80传统 exp 导出的 dmp 头部是明文字符串通常会输出EXPORT:V11.02.00 Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 ... SCOTT ORDER_MAIN数据泵文件在头部也会输出类似这样的信息DMP Oracle Database 19c Enterprise Edition Release 19.0.0.0.0通过 strings我可以快速确认文件的导出格式传统还是数据泵数据库版本号字符集相关参数导出 include 的对象名在字符串列表里能看到表名、用户名等。Windows 环境下可以用类似工具比如 Sysinternals 的 Strings.exe或者用 Notepad 以 UTF-8/ASCII 方式搜索“EXPORT:”关键字。有次接手一个 E 盘的文件同事先用 Notepad 搜了一把几秒就看到了“EXPORT:V10.02.01”立刻告诉我这是 10g 传统导出省去了装客户端的时间。这个方法只能看个大概不能替代 imp 或 impdp最大价值在于“快速分类”拿到陌生文件时第一件事别急着跑全量查看而是先确定类型和版本再决定用哪套工具链。4.2 在临时实例上建库导入彻底看清楚有些场景下光看 DDL 和数据行数还不够我想直接看一下表里的实际数据内容。比如同事提供一个 dmp说是客户系统里的配置表里面有几条关键的参数记录我需要验证这几条记录的值是否符合预期。这种需求最干净的做法是在一台空闲的测试服务器上装一个相同或向上兼容版本的 Oracle 库创建好表空间和用户名然后直接执行 imp/impdp 把数据导进去。导入完成后就可以光明正大地用 SELECT 去查数据、对比值。优点很明显所见即所得。缺点同样明显Oracle 库安装和初始化比较重需要 DBA 权限而且导入过程中如果目标表空间不足、字符集不匹配还会引入新的问题。所以我的习惯是先走 showy 或 sqlfile 做“第一遍查看”确认文件来源、版本、大致对象和行数都合理后再考虑要不要临时建库做全量验证。4.3 第三方图形化工具的可取与不可取市面上也有一些第三方工具试图直接解析 dmp 文件比如一些数据库管理工具的“导入”向导或者专门做 dmp 可视化的轻量软件。我用过的经验是对付小文件、简单场景它们可以快速预览表和字段遇到版本跨度大、字符集复杂、对象类型多的企业级 dmp它们经常解析不全或者直接崩溃。原因在于 Oracle 的 dmp 格式并没有对外公开完整规范第三方工具只能靠逆向或部分适配。生产环境里拿到的导出文件很多带压缩或加密选项第三方工具就更无能为力了。所以我把它们定位成“辅助工具”真正可靠的方案还是官方 imp/impdp。5. 常见问题与排查实录5.1 版本不匹配导致的读取失败这是我在帮别人排查时碰到频率最高的问题。现象通常是IMP-00010: 不是有效的导出文件头部验证失败 IMP-00000: 未成功终止导入第一眼可能觉得是文件损坏但多数情况不是而是客户端版本低于导出版本。比如你用 9i 的 imp 去读 11g exp 导出的文件就会中招。解决思路先用 strings 查看头部里的 EXPORT 信息确认导出版本找一个等于或高于该版本的 imp 客户端最好版本差在 1 个大版本以内如果手头有多版本的 Oracle 安装包直接切换 ORACLE_HOME 环境变量比反复装客户端更高效。数据泵文件也类似但它的报错更早通常一开始接触文件就提示格式或版本不支持。总而言之查看 dmp 之前版本矩阵这件事必须先行把“谁来读”和“读什么”对齐后面才顺利。5.2 字符集不一致导致乱码或报错字符集是另一个高频坑。比如文件是从 ZHS16GBK 环境的库导出的而当前查看用库默认字符集是 AL32UTF8showy 或 sqlfile 模式下的中文注释、中文表名就可能出现乱码。不过要区分两种情况只是查看 DDL 和注释乱码不影响你对结构的理解但很容易误判字段是否带注释真正导入时报错比如字符集转换不合法出现 ORA-12899 值过大等数据类错误这时需要确认源库和目标库的字符集兼容关系。我在查看时一般会顺手记录日志里import done in ZHS16GBK character set这样的信息作为后续导入或迁移的参考。如果要避免乱码影响分析可以把查看环境的 NLS_LANG 环境变量设置为和源库一致的字符集例如export NLS_LANGAMERICAN_AMERICA.ZHS16GBK再执行 imp 或 impdp。这个技巧能改善大部分中文乱码问题。5.3 DBA 权限与监听问题showy 模式虽然不写数据但 imp 命令在启动时还是要创建一个会话、验证用户名密码。如果遇到 ORA-1017 用户名密码无效或者连接时报监听错误那就连查看都做不了。碰到这种情况我的排查顺序是确认连接串是否正确能否用 sqlplus 正常登录目标库确认目标库监听状态和 tnsnames.ora 配置使用一个具有 DBA 权限或至少 EXP_FULL_DATABASE 角色的账号来执行查看因为 fully 需要读取全部对象的信息权限不足时可能报 ORA-31631 或者直接提示权限不够。如果手头没有现成的目标库也可以用 Oracle 自带的纯客户端工具配合一个空的连接串。有时候为了省事我甚至会在本机的任意一个已有库上执行 showy因为反正它不会真正写入权限和库版本只要满足“能连上”就能跑。5.4 dmp 文件拷过来后 md5 不一致或报文件损坏还有一个比较常见的小问题文件传输过程中损坏。小文件还好几十 GB 的 dmp 走网络传到一半断了或者存储介质有问题解析时就会在中途报错而且报错位置和真实损坏位置往往不相符。我的经验是大文件先做 md5 或 sha256 校验确认和源端一致再开始解析如果已经在解析过程中报“读取文件错误”“文件尾部异常”而文件本身没被截断可以试试用 Oracle 官方提供的 dbms_backup_restore 或其他修复工具但成功率不高最实在的办法是让源端重新导出一次导出时加上COMPRESSN方便后续传输和校验。6. 几点实在的工作心得说回开头那个同事的问题。最后我用 imp showy 帮他把那个老环境的 dmp 文件完整扫了一遍日志里出现了 20 多张表的建表语句和行数统计他现场确认了需要的几张配置表数据都在整个过程没有创建任何临时表。这就是查看 dmp 最典型的价值快速、安全、不污染环境。根据我个人的习惯再补充几条可复制的心得。第一查看 dmp 文件的工具选型要按“先分类再选择”的思路走。拿到文件先不要急着执行命令先用 strings 确认类型、版本、字符集然后判断该走 imp showy传统导出还是 impdp sqlfile数据泵。有时候客户给的压缩包解压出来忘了说明导出方式这个方法最快。第二日志文件一定要留。不管用哪一种方式查看都把输出定向到 log 文件里保存。因为查看 dmp 往往只是第一步后续迁移、比对、复盘都需要这些日志。没有日志等于白看。第三不要在核心生产环境上随手导入未知 dmp。就算文件看起来再安全也要先在测试库或者 show 模式里过一遍。我在生产库上见过有人盲目导入 dmp结果表空间被撑满、AWR 快照被挤掉最后花了大半天清理这就是没有敬畏心的代价。最后一个小技巧如果你只是想知道某张表是否存在其实不一定非要打开 dmp。可以先看导出对应的脚本或者数据泵的 job 日志这些文件很多时候和 dmp 一起交付。如果对方没有给再走解析路线。能少跑一次全量扫描就少跑一次毕竟上百 GB 的 dmp 解析也要时间。数据库文件查看这件事说难不难说简单也有不少门道。把上面的方法掌握住绝大多数 .dmp 到手上都能快速看出个大概。真遇到特别复杂的文件那就回到最基础的方法临时库导入再仔细查。这两条路走通基本就没有解决不了的查看需求了。