简介：这份资源是Oracle 11g 64位版本的bin目录完整打包，面向使用PL/SQL Developer进行数据迁移的数据库管理员与开发者，重点解决imp.exe、exp.exe缺失导致无法图形化导入导出的问题。压缩包共691个文件、约126MB，以372个dll动态库和118个exe可执行程序为主，另含bat批处理脚本、pm与pl等辅助文件，涵盖sqlplus、oradim等常用管理工具，构成较完整的命令行工具集。已有4162人学习下载，说明其在同类需求中具备一定参考价值。读者可直接补齐bin目录中的导入导出组件，在PL/SQL Developer中调用exp.exe备份表、模式或整库，再用imp.exe还原到目标环境，适用于版本升级、服务器迁移及开发测试环境同步等场景，省去逐一手动配置命令行参数的麻烦。

1. 手里只有 dmp 文件，怎么把它塞进 Oracle 11g 64 位实例

接手一个老系统迁移的活儿，对方丢过来一个 3GB 的 dmp 文件，说“你导一下就行”。打开服务器一看，Oracle 11g 64 位，没装客户端工具，PL/SQL Developer 里点导入导出直接报找不到可执行文件。这种场景下真正缺的不是数据库，而是 bin 目录里那两个老面孔：imp.exe 和 exp.exe。这份资源就是 Oracle 11g 64 位版本的 bin 目录工具集，核心是经典导入导出程序 imp/exp，配合 PL/SQL 的导入导出向导使用。它解决的是“有 dmp、有库、但没工具链”的断档问题，适合还在维护 11g 存量系统、需要做逻辑备份迁移的从业者。注意它是传统 exp/imp 体系，不是数据泵 expdp/impdp，两者不通用，选错方向会白折腾半天。

2. 先分清 exp/imp 和数据泵：选错工具等于白干

2.1 两套体系到底差在哪

Oracle 的逻辑导出有两代工具。第一代是 exp.exe / imp.exe，客户端侧程序，生成二进制 dmp，走的是 exp 协议；第二代是服务端的数据泵 expdp / impdp，程序跑在数据库服务器上，通过目录对象写文件。很多人栽在第一步：拿到一个 dmp，直接 imp 进去，报 “不是有效的导出文件”，其实是数据泵导出的。反过来，用 impdp 去导 exp 生成的 dmp，同样报错。判断方法很简单，用十六进制看文件头，exp 的 dmp 开头通常是特定标记，数据泵的 dmp 头部结构完全不同。实操里我一般先问对方一句“你导出时敲的是 exp 还是 expdp”，问不到就看文件大小和生成时间，数据泵的 dmp 往往伴随一个 .log 文件同目录。

这份资源给的是 exp.exe / imp.exe，所以它对应的是传统体系。选它的理由通常有三个：目标库是 11g 且不允许在服务器上建目录对象、只需要导某几张表或某个用户、以及 PL/SQL Developer 的导入导出界面底层调用的就是这两个 exe。如果你的需求是全库迁移、并行加速、可断点重启，那应该走数据泵，这份资源帮不上。

2.2 版本兼容的硬规则

exp/imp 有一条铁律：低版本导出的 dmp 可以导入高版本，高版本导出的不能导入低版本。11g 的 exp 导出的文件，往 11g 及更高版本导没问题；但如果源库是 12c 用 exp 导的，往 11g 导就会报版本不兼容。另外 32 位和 64 位的 exp/imp 生成的 dmp 本身是跨平台通用的，但 exe 必须和你的客户端环境位数匹配。这份是 64 位版本，意味着它要放在 64 位 Windows 的 Oracle 客户端或服务端 bin 目录下，32 位环境放进去会直接提示不是有效的 Win32 应用程序。

2.3 把工具放到位：目录结构与 PATH

拿到 bin 目录后不要整个覆盖你现有的 Oracle 安装。正确做法是把 exp.exe、imp.exe 以及它们依赖的 DLL 挑出来，放到一个已经配好环境变量的 Oracle 客户端 bin 下，或者单独建目录后把该目录加进 PATH。依赖的 DLL 主要是 oci.dll、oraociei11.dll 这一类，缺一个就会弹“无法启动此程序，因为计算机中丢失 XXX.dll”。我一般先备份原 bin，再把新 exe 拷进去，然后开一个新的 cmd 窗口验证，因为 PATH 的变更对已打开的终端不生效。

# Windows 下验证 exp/imp 是否可用，注意要在新开的 cmd 里执行 where exp where imp # 直接看版本，能出版本号说明依赖 DLL 齐全 exp help=y imp help=y

where用来确认实际调用的是哪个路径下的 exe，避免你拷了新的但系统仍走旧路径。exp help=y不连数据库，只打印参数帮助，是检验 DLL 依赖是否完整最快的手段——如果这里就崩，说明缺 DLL 或位数不对，跟数据库无关。参数help=y是 exp/imp 的通用开关，任何排错第一步都先跑它。

3. 用 exp.exe 导出：三种粒度与参数怎么配

3.1 三种导出模式的选择

exp 支持三种粒度：表模式（TABLES=）、用户模式（OWNER=）、全库模式（FULL=Y）。表模式最常用，适合单表数据修复；用户模式导出一个 schema 下所有对象，是迁移的常规选择；全库模式需要 DBA 权限，且 11g 下全库导出会包含系统对象，导入时容易撞上已存在的对象。实操里我优先用户模式，因为边界清晰，导入到新库时不会污染其他 schema。

# 用户模式导出，把 SCOTT 用户下所有对象导到文件 exp scott/tiger@ORCL OWNER=SCOTT FILE=D:\dump\scott_20240101.dmp LOG=D:\dump\scott_exp.log # 表模式导出，只导 EMP 和 DEPT 两张表 exp scott/tiger@ORCL TABLES=(EMP,DEPT) FILE=D:\dump\emp_dept.dmp LOG=D:\dump\emp_dept.log # 全库导出，需要 DBA 权限 exp system/manager@ORCL FULL=Y FILE=D:\dump\full.dmp LOG=D:\dump\full.log

第一行里scott/tiger@ORCL是用户名/密码@服务名，OWNER指定 schema，FILE是输出路径，LOG记录导出过程。第二行TABLES=(EMP,DEPT)括号内多表用逗号分隔，表名大小写按库里的实际对象名来，11g 默认大写。第三行FULL=Y全库，注意它会导出大量系统对象，导入时通常要配合IGNORE=Y。三个命令都建议带 LOG，因为 exp 的报错有时只在日志里完整呈现，控制台会被截断。

3.2 几个容易配错的参数

CONSISTENT=Y让导出期间数据保持一致快照，代价是需要回滚段空间，大表导出时如果回滚段不够会报 ORA-01555。DIRECT=Y走直接路径，速度快但不走 SQL 层，某些带触发器的表行为会有差异。COMPRESS=Y是压缩段分配，不是压缩文件，别指望它把 dmp 变小。QUERY参数可以带条件导出，比如只导某时间之后的数据，写法是QUERY="WHERE CREATE_TIME > TO_DATE('2024-01-01','YYYY-MM-DD')"，注意引号在 Windows cmd 下的转义，双引号包整体、内部用单引号。

# 带条件的一致性导出，只导 2024 年之后的数据 exp scott/tiger@ORCL TABLES=ORDERS QUERY="WHERE CREATE_TIME > TO_DATE('2024-01-01','YYYY-MM-DD')" \ CONSISTENT=Y FILE=D:\dump\orders_2024.dmp LOG=D:\dump\orders_2024.log

QUERY只对表模式有效，用户模式和全库模式不认这个参数。CONSISTENT=Y和DIRECT=Y同时用会有冲突，直接路径不支持一致性读，两个都写时 exp 会忽略其中一个，具体忽略哪个看版本，所以别同时配。反斜杠续行是 Linux 习惯，Windows cmd 里要写成一行或用^续行，这点在复制网上命令时经常翻车。

3.3 导出失败的常见信号

导出中途报 ORA-01555 是回滚段不足，解决要么加大回滚段，要么去掉 CONSISTENT 改成分批导。报 EXP-00008 通常是遇到了不支持的对象类型，比如某些 XML 类型或空间索引，日志里会指明具体对象，可以选择性排除。报 EXP-00091 是统计信息问题，不影响数据本身，可以忽略或用STATISTICS=NONE关掉统计信息导出。这些错误码在日志里都有上下文，别只看最后一行。

4. 用 imp.exe 导入：顺序、覆盖与权限

4.1 导入前必须确认的三件事

第一，目标库字符集要和源库一致或兼容，否则中文会变问号，这个坑一旦踩了只能重导。用SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER='NLS_CHARACTERSET';查两边字符集。第二，目标用户是否存在，imp 不会自动建用户，用户不存在会报 ORA-00959。第三，表空间是否够，导入大表前先看目标表空间剩余。这三件事确认完再动手，比导到一半失败回滚省事得多。

4.2 从用户到表的导入命令

# 用户模式导入，FROMUSER 到 TOUSER 可以做 schema 改名 imp system/manager@ORCL FROMUSER=SCOTT TOUSER=SCOTT_NEW \ FILE=D:\dump\scott_20240101.dmp LOG=D:\dump\scott_imp.log # 表模式导入，只导指定表 imp scott/tiger@ORCL TABLES=(EMP,DEPT) FILE=D:\dump\emp_dept.dmp \ IGNORE=Y LOG=D:\dump\emp_dept_imp.log # 全库导入，忽略已存在对象错误 imp system/manager@ORCL FULL=Y FILE=D:\dump\full.dmp \ IGNORE=Y LOG=D:\dump\full_imp.log

第一行FROMUSER和TOUSER是 imp 的杀手锏，能把源 schema 的对象导到目标 schema 下，做环境隔离时特别有用，比如把生产数据导到测试用户。第二行IGNORE=Y表示对象已存在时跳过而不报错，表模式导入到已有表的库时必须加，否则一遇到已存在的表就中断。第三行全库导入同理，IGNORE=Y几乎是标配。所有命令都带 LOG，imp 的报错比 exp 更多更杂，日志是唯一能回溯的依据。

4.3 导入顺序与依赖问题

imp 导入时会自动处理大部分依赖，但有几类对象顺序敏感：序列（SEQUENCE）的当前值、触发器、以及外键约束。默认情况下 imp 先导表结构和数据，再导索引约束，外键一般能自动处理。但如果目标库已有数据且外键冲突，会报 ORA-02291。解决办法是先CONSTRAINTS=N跳过约束导入，数据导完再单独补约束。序列的当前值 imp 会尝试恢复，但如果导入过程中有应用在写库，序列可能被推高，这点在割接窗口里要留意。

# 先导数据不导约束，适合目标库已有外键的场景 imp scott/tiger@ORCL FROMUSER=SCOTT TOUSER=SCOTT_NEW \ FILE=D:\dump\scott.dmp CONSTRAINTS=N IGNORE=Y LOG=D:\dump\imp_noconstraint.log

CONSTRAINTS=N只跳过约束，索引和触发器照常导。导完数据后需要手工或再跑一次带ROWS=N的导入来补约束，ROWS=N表示只导结构不导数据，两者配合能实现分阶段导入。这个组合在数据量大、约束多的库上很实用，代价是多一次导入操作。

5. 避坑清单：那些让导入导出卡住的真实原因

5.1 现象：imp 报 IMP-00010 不是有效的导出文件

原因通常是拿数据泵的 dmp 去喂 imp，或者文件在传输中被截断、被当文本改过编码。解决：先用expdp对应的impdp试，确认文件类型；检查文件大小和源端是否一致，FTP 传输要用二进制模式，ASCII 模式会破坏二进制文件。这个坑在跨机器拷贝 dmp 时高发，血泪经验是传完先比对 MD5。

5.2 现象：导入中文全是问号

原因是源库和目标库字符集不一致，比如源是 ZHS16GBK，目标是 AL32UTF8，而 dmp 里的字节流按源库编码解释。解决：导入前确认两边NLS_CHARACTERSET，不一致时要么改目标库字符集（风险高，需停机），要么在导入会话里设置NLS_LANG环境变量匹配源库编码。NLS_LANG的格式是SIMPLIFIED CHINESE_CHINA.ZHS16GBK这种，设错等于没设。

5.3 现象：exp 导出到一半报 ORA-01555 快照过旧

原因是用了CONSISTENT=Y但回滚段不够支撑整个导出时长。解决：加大 UNDO 表空间，或去掉一致性导出改成分批按表导，或把大表拆成多个 QUERY 条件分批导。别指望调大UNDO_RETENTION就万事大吉，导出时长超过保留时间照样报。

5.4 现象：PL/SQL Developer 点导入导出没反应或报找不到 exp

原因是 PL/SQL 的导入导出向导依赖本机 bin 目录下的 exp.exe/imp.exe，路径没配或位数不匹配都会失败。解决：在 PL/SQL 的偏好设置里确认 Oracle Home 指向正确的客户端目录，把这份 64 位 exe 放进该目录的 bin 下，重启 PL/SQL。32 位 PL/SQL 配 64 位客户端也会出问题，位数要一致。

5.5 现象：导入后表在但数据是空的

原因是导出时用了ROWS=N，或者导入时加了ROWS=N，或者IGNORE=Y跳过了已存在的表导致数据没进去。解决：查导出日志确认是否带 ROWS 参数，导入时如果目标表已存在且想覆盖数据，得先 truncate 或 drop 再导，IGNORE=Y只是跳过不覆盖。这个坑最隐蔽，因为命令不报错，导完一看数据没变。

6. 把 exp/imp 用稳的几个进阶习惯

真正让这套老工具在生产里不出事的，不是记住多少参数，而是几个固定动作。第一个习惯是导出前先跑一次exp help=y和imp help=y，确认 exe 和 DLL 在当前会话里是通的，这一步十秒钟，能挡掉一半“工具没配好”的低级故障。第二个习惯是任何导出都带 LOG 且导出后立刻看日志尾部，exp 的成功提示是“成功终止导出, 但没有警告”，有警告也要逐条看，警告里往往藏着对象被跳过的信息。

第三个习惯是导入前做一次“空跑”：用imp ... SHOW=Y只列出 dmp 里的对象清单而不实际导入，确认里面确实有你要的表和用户。SHOW=Y配合LOG能把 dmp 内容打印出来，是判断 dmp 是否完整的后悔药。

# 只查看 dmp 内容不导入，确认对象清单 imp scott/tiger@ORCL FILE=D:\dump\scott.dmp SHOW=Y LOG=D:\dump\show_content.log

SHOW=Y会遍历 dmp 并输出对象定义，不写库，适合在正式导入前核对。注意它仍然需要连库，因为要解析目标环境，但不会产生数据变更。

第四个习惯是版本对齐检查。下面这张表是我排错时常用的对照，遇到兼容性报错先对一遍：

最后说一个验证导入是否真正成功的技巧：别只看 imp 返回“成功终止导入”，要连库跑SELECT COUNT(*)对源库和目标库的关键表行数，再抽查几张表的MAX(主键)或时间字段。行数对得上、抽样数据对得上，才算导完。从那以后我每次导完 dmp 都强制走一遍行数比对和SHOW=Y预检，宁可多花五分钟，也不在割接当晚被一个空表打脸。希望帮到你。

本文还有配套的精品资源，点击获取