企业官网建设流程全解析

简介：针对Oracle11g 64位环境，提供其bin目录的核心文件包，重点包含imp.exe与exp.exe导入导出工具，面向需要完成数据迁移、备份恢复或环境同步的数据库管理员和开发者。包内共691个文件，压缩包126.04MB，以dll动态库、exe可执行程序、bat批处理脚本、pm脚本等类型为主，可在PL/SQL Developer中直接调用，免去完整安装Oracle客户端的繁琐配置。已有4158人学习。借助这些工具，用户能灵活完成表、模式或全库的导出与导入，支持过滤条件、压缩存储和一致性检查；配合图形界面操作，可显著提高大批量数据的迁移效率，减少命令行手工操作可能带来的失误，适合日常运维、测试库搭建及跨平台数据同步等场景。

1. 为什么一个 bin 目录能卡住一整条导入导出链路

你在一台 64 位 Oracle 11g 服务器上装了数据库，本地用 PL/SQL 图形化客户端连得挺顺畅，一到“导入/导出”就报错：找不到 exp.exe，或者找到了但双击毫无反应。更常见的是你从某台机器上拷了一个“Oracle 客户端工具包”，里面只有 imp.exe 和 exp.exe，拿到新机器却怎么都用不了。这个标题讲的就是这件事：Oracle 11g 64 位安装目录 bin 下的 imp.exe 和 exp.exe 是传统导入导出工具的核心文件，它们能跑通取决于文件是否完整、环境变量是否就位、字符集是否匹配，缺一项就翻车。大多数时候问题不在文件缺失，而在 DLL 依赖和 NLS_LANG 设置上。这篇笔记会把它讲透，让图形客户端里的导入导出按钮真正能用起来。

2. 先把工具搞清：exp/imp 在 11g 64 位环境里的真实地位

Oracle 11g 的 ORACLE_HOME\bin 目录里同时躺着两套导入导出工具：一套是标题里说的传统 exp.exe/imp.exe，另一套是以 expdp.exe/impdp.exe 为代表的数据泵。很多从业者分不清这两者，结果按数据泵的参数去写传统命令，或者反过来，在图形化客户端里配了 expdp 的路径，折腾半天还是失败。这里先把两套工具的定位讲清楚，后面所有命令和参数才有讨论基础。

2.1 两种工具一句话分辨：exp 和 expdp 差的不只是一个字母

传统 exp/imp 是 Oracle 早期就有的导入导出实现，数据泵 expdp/impdp 是 10g 开始推出的重写版本。功能上数据泵更强，但运行模型完全不同。

日常工作中你只需要记住一条：PL/SQL 图形化客户端的“导入/导出”按钮，底层调用的就是传统 exp/imp。图形工具没有跑数据泵的条件，数据泵需要你登录服务器用命令行操作，还要先建 DIRECTORY 对象。所以这个标题里 bin 目录的 imp.exe/exp.exe，是图形化导入导出链路里绕不开的一环。

2.2 bin 目录里哪些文件和你导入导出真正相关

只看到 imp.exe 和 exp.exe 两个文件，会让你误以为工具包就这两样。Oracle 的 exe 都是动态链接的，exp.exe 启动后要加载同目录下的一批 DLL，比如核心的 oci.dll、网络层相关的库文件。我见过有人图省事，从服务器上只拷贝这两个 exe 到 U 盘，拿到别的机器上双击，直接报 0xc000007b 或“缺少 DLL”，这就是典型的文件不完整。

正确做法是保留整个 bin 目录的相对结构。你不需要把 bin 里所有文件都拷走，但要保证 exe 所在目录的 DLL 文件集是完整的。最简单的判断标准：在命令行里进入 bin 目录，输入 exp help=y，如果能正常输出版本信息和参数列表，说明 DLL 依赖没问题；如果报错，缺文件。

另外注意一个常见误区：Oracle Instant Client 里通常没有 exp/imp。很多人下载了所谓的轻量客户端，配好之后图形工具能连库，但导入导出还是失败，因为 Instant Client 的 bin 下根本没有这两个 exe。标题里说的这个 bin 目录，是完整版 Oracle 安装或完整版客户端安装的产物，不是 Instant Client。

2.3 哪些场景必须用传统 exp/imp

传统工具虽然老，但在几类场景下是最可靠的选择：

• 要给低版本数据库交接数据。比如 11g 库导出的数据要导入一个 9i 或 10g 库，传统 exp 可以加 VERSION 参数降级，数据泵的限制更多。
• 图形化客户端做导入导出。这是默认链路，客户端工具只认传统 exp/imp。
• 临时导出几张配置表。几十 MB 的小表，开数据泵还要建 directory、给权限，传统 exp 一条命令就完了。
• 没有服务器 shell 权限。数据泵必须登录服务器跑，传统 exp/imp 只要网络通、有数据库账号就行。

边界也要说清楚：11g 里新增的部分对象类型，比如 SecureFile LOB，传统 exp 支持得不好，导出时可能报 EXP-00106 这类错误，遇到这种对象模型，老老实实用 expdp/impdp 在服务器端处理。

3. 把 64 位 bin 目录配成可用工具包：环境变量和调用链

文件在，工具还在，但图形客户端还是提示找不到 imp.exe，或者命令行里敲 exp 提示“不是内部或外部命令”。这一步要处理的是环境变量和工具调用链。Oracle 的命令行工具定位 ORACLE_HOME 依赖环境变量；图形客户端定位 exe 依赖它自己的配置项。这两条线都要打通，导入导出才算真正配好。

3.1 三条环境变量一次设对：ORACLE_HOME、PATH、NLS_LANG

在 Linux 或 Unix 服务器上，经验做法是在当前用户的配置里导出这三个变量。以 11g R2 为例：

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

在 Windows 上对应的写法是：

set ORACLE_HOME=C:\oracle\product\11.2.0\dbhome_1 set PATH=%ORACLE_HOME%\bin;%PATH% set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK

ORACLE_HOME 的作用是让 exe 找到它依赖的 DLL 和配置文件。PATH 的作用是让命令行在任何目录下都能直接敲 exp 或 imp，不用每次 cd 到 bin 目录。NLS_LANG 的格式是“语言_地区.字符集”，它告诉 exp/imp 当前客户端用什么字符集解释数据。

NLS_LANG 是最容易埋雷的变量。它不一定要和数据库字符集完全一致，但最稳的做法是和数据库一致。查询数据库端视角的推荐值可以执行：

SELECT userenv('language') FROM dual;

这个查询返回的就是一个标准的 NLS_LANG 格式字符串，直接抄下来用。设置完记得重新打开命令行窗口，环境变量才生效。

3.2 图形客户端是怎么找到 imp.exe 的：两种调用方式

图形化工具调用 imp/exp 的方式有两种。第一种是外部进程方式：工具配置里有一个“导入导出可执行文件路径”之类的选项，你填了 C:\oracle...\bin\imp.exe，工具就通过系统接口启动这个外部进程。第二种是工具内置了 OCI 驱动直连数据库，但导入导出动作仍然会拉起外部 exe。

这里有个 32 位/64 位纠缠的问题。如果图形客户端本身是 32 位进程，它启动一个 64 位的 exp.exe 是没问题的，因为这只是普通的进程创建，不是 DLL 注入。真正的冲突发生在 exp.exe 加载 DLL 时：64 位的 exe 必须加载 64 位的 DLL。如果你把 32 位客户端装的 DLL 路径放在了 PATH 前面，64 位的 exp.exe 就可能加载到 32 位 DLL，然后报 0xc000007b。所以 PATH 里哪个 bin 在前，决定了 exe 加载哪套 DLL。

配置图形工具时，注意区分两个概念：工具连接数据库用的 OCI 路径，和工具调用 imp/exp 的路径。前者决定你能不能连上库，后者决定导入导出按钮能不能用。很多人只配了前者，后者留空或者指向了 Instant Client，按钮自然是灰的。

3.3 验证链路：一条命令确定 exp 能连上库

环境变量配好之后，不要急着打开图形工具点按钮，先在命令行里验证整条链路。分三步走：

# 第一步：确认 exe 能被找到且 DLL 依赖完整 exp help=y # 第二步：确认数据库网络别名能解析 tnsping orcl # 第三步：用最小命令实际导出一张表 exp userid=system/口令@orcl file=/tmp/test.dmp log=/tmp/test.log tables=EMP rows=n

exp help=y 如果正常输出一大版参数说明，说明 bin 目录和 PATH 没问题。tnsping orcl 确认 TNS 别名解析正常。最后那条最小导出命令，tables=EMP 指定只导一张演示表，rows=n 表示不导数据只要结构，几十 KB 的 dmp 几秒就出来。跑通了，图形客户端里大概率也能用。

第三步里如果报 ORA-12154，说明 TNS 别名找不到，检查 tnsnames.ora 是否在 $ORACLE_HOME/network/admin 下。如果报口令错误，注意用户和密码之间是斜杠，Linux 下特殊字符要加引号。

4. 用 imp.exe / exp.exe 干活：高频命令与参数组合

环境配通了，接下来是实际干活。传统 exp/imp 的参数体系虽然老，但只要几个关键参数理解了，覆盖日常 80% 的导入导出需求没压力。这一章给的是可以直接抄走的命令写法，每条命令后面的参数说明注意看一眼，改错了不报错但结果不对的情况更坑。

4.1 参数文件是命令行最长情的伙伴：把口令写进 parfile

命令行里直接写 userid=system/口令@orcl，口令会出现在 shell 历史和进程列表里。我一般把参数写进一个 parfile 参数文件，这样口令不进命令行，参数还有注释，团队交接也方便：

# exp.par userid=system/口令@orcl file=/backup/scott.dmp log=/backup/scott.log owner=SCOTT buffer=10485760 statistics=none grants=y rows=y

执行方式：

exp parfile=exp.par

owner=SCOTT 表示按用户 SCOTT 导出。buffer 是缓冲区字节数，调大到 10MB 能减少取数往返，对大表有帮助。statistics=none 表示不导出统计信息，这样导入端不会带着一套可能不适用的统计信息。grants=y 保留对象授权。rows=y 导出表数据。

Windows 下注意路径写法，建议用正斜杠 C:/backup/scott.dmp，避免反斜杠在某些场景下的解析问题。parfile 文件本身的编码也要注意，中文路径或中文口令在 Windows 记事本另存为 ANSI 编码最稳。

4.2 按用户导出整个 schema：owner 与 BUFFER/STATISTICS 的取舍

4.1 的参数文件就是按用户导出的标准写法。这里补充一个场景：如果只要导出某一个用户，又不想在命令行里写一长串参数，parfile 是最优解。但如果你没有权限或不便建 parfile，命令行写法是这样：

exp userid=system/口令@orcl \ file=/backup/scott.dmp \ log=/backup/scott.log \ owner=SCOTT buffer=10485760 \ statistics=none grants=y

反斜杠是换行符，在 Linux shell 下有效，Windows cmd 下要写一行。BUFFER 这个参数，我对超过 5GB 的表会调到 50MB 左右，但注意它不是越大越好，超过阈值后收益递减。统计信息那行建议保留 statistics=none，否则导入完成后统计信息可能还是旧库的，优化器选错执行计划是后续性能问题的常见来源。

4.3 只导结构或只导数据：ROWS 和 INDEXES 怎么组合

不同场景对数据的取舍需求不一样。初始化一个测试环境，通常只要表结构；迁移一个历史表，可能只要数据。传统 exp/imp 里控制这个的核心参数是 ROWS 和 INDEXES：

# 只导结构，建表语句和存储过程等对象，不含行数据 exp userid=system/口令@orcl parfile=exp_struct.par rows=n # 只导数据，假设结构目标库已有 exp userid=system/口令@orcl parfile=exp_data.par rows=y indexes=n

参数组合的意思是：rows=n 时导出端不读取表数据，dump 文件里只有 DDL；rows=y 时数据照常导出，indexes=n 则跳过索引和约束相关的导入指令。常见的搭配下表：

大表场景我建议用“先导数据再补索引”的组合。索引在数据导入时重建，等于每插一行都要维护索引，速度会差很多。先 indexes=n 导完数据，再用脚本批量建索引，整体耗时往往能压缩一半以上。

4.4 跨低版本数据库交付：version 参数和它的副作用

要把 11g 导出的数据交到一个 10g 或 9g 的库里，直接导肯定不行，低版本的 imp 不认高版本的 dmp 文件头。传统工具给了一条路，用 VERSION 参数降级导出：

# 在 exp.par 里增加一行 version=10.2.0.1.0

这样导出的 dmp 文件头按照 10.2.0.1.0 的格式生成，低版本 imp 就能识别。副作用是版本低于 11g 的对象类型会被静默跳过或写警告到 log 里，比如 11g 才有的虚拟列、部分新的存储选项。我常用的做法是先看 log 文件里有没有 EXP-00106 或“skipping”字样，有就说明丢东西了，需要改用数据泵处理。

4.5 常规导入 scott 到 hr：fromuser、touser、ignore、commit

导入端的高频命令是把一个 schema 的数据导入另一个 schema：

imp userid=system/口令@orcl \ file=/backup/scott.dmp \ log=/backup/imp_scott.log \ fromuser=SCOTT touser=HR \ ignore=y commit=y buffer=10485760

fromuser=SCOTT 告诉 imp 这个 dmp 里的对象属于哪个用户，touser=HR 表示导入到目标用户。ignore=y 表示导入过程中遇到目标端已存在的对象不报错跳过。commit=y 表示每批数据插入后立即提交，避免一个大事务把回滚段撑爆。

这里要注意一个边界：传统 imp 没有 expdp 里那种 REMAP_TABLESPACE 参数。如果 dmp 里的对象属于某个表空间，而目标库没有同名的表空间，导入会报 ORA-00959。处理办法是预先在目标库创建同名表空间，或者干脆换数据泵工具做表空间重映射。

5. 避坑：64 位 bin 里 exp/imp 的五个典型翻车点

导入导出报错不怕，怕的是报错信息看了不知道往哪查。这一章把我踩过和见别人踩过的坑集中拆开，每条按现象、原因、解决三个层面写，你遇到同类问题时直接对号入座。

5.1 EXP-00091 和乱码：NLS_LANG 才是幕后黑手

现象：exp 导出时日志里出现“EXP-00091: Exporting questionable statistics”，导入后中文字段变成乱码或问号。

原因：EXP-00091 本身只是统计信息相关的警告，但它背后往往是 NLS_LANG 没有设置或与数据库字符集不一致。exp 导出时用 NLS_LANG 指定的字符集去解释客户端数据；两端不一致时，中文字符在转换过程中被替换，导入端自然乱码。

解决：先查数据库字符集，设置一致的 NLS_LANG。查询用这段：

SELECT parameter, value FROM nls_database_parameters WHERE parameter IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

拿到字符集后，比如结果是 ZHS16GBK，就把 NLS_LANG 设成 SIMPLIFIED CHINESE_CHINA.ZHS16GBK，重新打开命令行再导出。注意 Windows 下注册表里也可能有 NLS_LANG 项，改了注册表要完全退出图形客户端再重进。

5.2 64 位工具撞上 32 位进程：0xc000007b 还是找不到文件

现象：图形客户端里点导入导出没反应，或在命令行运行 exp 报错，窗口一闪而过。控制台里手动运行报“0xc000007b”或“不是有效的 Win32 应用程序”。

原因：0xc000007b 是典型的位数不匹配错误，64 位 exe 加载了 32 位 DLL，或者反过来。另一种情况是 PATH 里排前面的 bin 目录里根本没有 exp.exe，系统找到了别的 Oracle 客户端目录。把两个 exe 单独拷到别的目录也会触发类似问题。

解决：确认 PATH 里第一个 Oracle bin 目录是你要用的那个版本；不要单独拷贝 exe，保留整个 bin 目录结构；如果图形工具自带的客户端是 32 位的，而你想调 64 位 exp.exe，确认工具配置里导入导出路径明确指向 64 位 bin，并且在命令行先把 PATH 验证好。

5.3 IMP-00010：看着是 dmp，其实早坏了

现象：imp 一执行就报“IMP-00010: not a valid export file, header failed verification”，换了几台机器都一样。

原因：dmp 文件是二进制格式，最常见的情况是文件在传输过程中被损坏。FTP 用了文本模式传输、下载中断但文件大小看起来正常、用压缩软件打开后另存为普通文件，这三种情况我都见过。另一个可能是低版本 imp 读高版本 dmp，但那个报错信息通常不同。

解决：先检查文件头。用十六进制查看器或直接 strings 命令提取可读字符：

strings suspect.dmp | head -20 # 或更精确一点 head -c 32 suspect.dmp | od -A d -t x1

正常的 dmp 文件头能看到 “EXPORT:V11.02.00” 之类的版本标记。看不到标记，基本可以断定文件已损坏。重新导出后用二进制模式传输，传输完比对文件大小和源文件是否一致。

5.4 导入半小时不动：BUFFER、COMMIT 与回滚段的三角关系

现象：一个 200MB 的 dmp 导了两个小时还没完，或者中途报 ORA-01555、ORA-01650 回滚段相关错误。表也不大，速度就是上不去。

原因：默认情况下 imp 是在整个表导入完成后才提交，一个大表就是一个超大事务。BUFFER 默认值偏小，每批次取数量少，加上回滚段不断增长，整体性能自然拉胯。

解决：两条参数配合调。BUFFER 调大到 10485760 以上，COMMIT=Y 开启分批提交：

imp userid=system/口令@orcl \ file=/backup/big.dmp \ log=/backup/big_imp.log \ buffer=10485760 commit=y

代价也要说清楚：commit=y 之后，导入过程中途失败时，已提交的部分不会自动回滚，不能指望整个导入的原子性。生产环境做数据初始化时，我一般先用 commit=n 做小表验证逻辑，确认无误后再对大表用 commit=y 提效。

5.5 导完“成功”但少对象：grants/indexes/triggers 开关没对齐

现象：imp 日志显示成功结束，但对比源库发现缺索引、存储过程编译失效、部分表的授权没有了。

原因：导入导出的开关是一个体系，exp 端没导出来的东西，imp 端再怎么配也找不回来。最常见的情况是从别人那儿复制了一个 exp 参数模板，里面 grants=n 或 triggers=n，导出时静默丢掉了授权和触发器。

解决：全量迁移场景下，我固定用这组开关保证导出完整：

exp userid=system/口令@orcl \ owner=SCOTT \ grants=y triggers=y indexes=y \ constraints=y statistics=none

导入端对应保持全开。导出完成后，在 log 文件里搜索“warning”和“skipping”字样，有就要回头检查。存储过程编译失效不一定是导入问题，导入顺序导致依赖对象还没建完是常态，导入完再执行一次重新编译脚本即可。

6. 花 10 秒给不熟悉的 dmp 做体检：show=y 的只读检查法

接手别人给的 dmp 文件，最忌讳直接 imp。你不知道里面是什么版本导出的、有哪些对象、原 schema 是谁，贸然导入大概率中途报错。传统 imp 自带一个只读体检模式，show=y，它只解析 dump 文件并输出内容清单，不向数据库写入任何对象。

imp userid=system/口令@orcl \ file=/backup/unknown.dmp \ log=/backup/preview.log \ show=y

跑完之后打开 preview.log，能看到导出工具的版本、原用户、每张表的建表和插入语句。用几条命令快速提取关键信息：

# 看导出工具版本 grep "Export" /backup/preview.log | head -5 # 统计里面有多少张表 grep -c "CREATE TABLE" /backup/preview.log # 看原 schema 名 grep "CREATE TABLE" /backup/preview.log | head -3

我接手陌生 dmp 的习惯是固定三查：第一查版本，确认是不是 11g 或更高版本导出的，决定导入端用哪个版本的 imp；第二查 show 输出里有没有格式警告，有警告说明文件可能有瑕疵；第三查原 schema 和表空间名，和目标库对不上就提前准备同名表空间，别等导入到一半才报 ORA-00959。

这个体检还有个额外价值：show=y 不需要目标库有足够空间，几百 MB 的 dmp 几秒钟就能完成检查，比导入失败再排查快得多。也是因为吃过几次“直接导入才发现文件头不对”的亏，现在任何 dmp 到我手上，第一动作永远是 show=y 而非 imp。希望这些经验帮你在导入导出这条路上少踩几个坑。

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