Oracle 11g exp/imp 命令行迁移实战：从原理到脚本化避坑

简介这份资源面向使用 Oracle 11g 64 位数据库的开发者与 DBA提供 bin 目录下的核心可执行文件重点解决在 PL/SQL Developer 等图形化工具中调用 imp.exe 与 exp.exe 完成数据导入导出的问题适用于数据库备份恢复、版本升级、服务器迁移及开发测试环境间的数据同步等场景。压缩包共 691 个文件约 126.04MB以 372 个 dll 动态库、118 个 exe 可执行程序、56 个 bat 批处理脚本为主另含 pm、flt、pl、lib 等辅助文件基本还原了 Oracle 管理工具集的完整结构。已有 4162 人学习下载说明其在同类需求中具备一定参考价值。读者可直接获得可用的导入导出工具及配套依赖省去从安装介质中单独提取的麻烦同时通过目录结构了解 sqlplus、oradim 等工具的相对位置便于后续排错与工具调用。1. 老库迁移现场为什么我还在翻 Oracle 11g 的 bin 目录上周帮一个做 ERP 二次开发的朋友收拾一台老服务器数据库是 Oracle 11g 64 位业务跑了七八年现在要整体搬到新环境。开发那边习惯用 PL/SQL Developer 点两下就导完结果这次数据量上到几十个 G图形界面直接卡死日志里只剩一句含糊的报错。最后还是回到最原始的路子进bin目录用exp.exe和imp.exe命令行把活干完。这份资源就是 Oracle 11g 64 位安装目录下的bin文件夹核心价值在于里面那对导入导出工具——imp.exe负责把.dmp文件灌回库exp.exe负责把库里的对象抽成.dmp。它解决的不是“新潮”问题而是老系统迁移、跨库同步、单表备份这类必须落地的脏活。适合谁手上还压着 11g 实例的 DBA、做遗留系统维护的后端、以及被 PL/SQL 导出卡到怀疑人生的开发者。命令行不花哨但参数可控、能写脚本、能挂定时任务这才是它到今天还没被淘汰的原因。2. exp.exe 与 imp.exe 的工作机制先搞懂它怎么搬数据2.1 客户端工具与数据库实例的关系很多人第一次用会懵exp.exe到底是在导“库”还是在导“文件”答案是它在客户端侧发起一个会话连上目标实例按你给的对象范围把数据字典和表数据序列化成 Oracle 专有的二进制.dmp格式。也就是说bin目录里的这两个 exe 是客户端程序它们不依赖本机装没装数据库服务只要能通过网络连到实例、并且版本匹配就行。11g 的exp属于传统导出Original Export和 10g 之后主推的 Data Pumpexpdp/impdp是两套东西。传统导出走的是老式通路优点是兼容性极好9i、10g 的 dmp 也能吃缺点是单线程、大表慢、不支持并行。我一般这么判断数据量在几个 G 以内、对象结构不复杂、或者对方只给了.dmp没给目录对象权限就用exp/imp上到几十 G、要并行、要 remap 表空间才切到 Data Pump。这里有个血泪经验——exp导出的 dmp不能用impdp直接导反过来expdp的 dmp 也不能用imp吃两套格式不互通别混用。2.2 三种导出模式与对象范围exp的模式决定了你拿到什么全库FULLY、按用户OWNER、按表TABLES。全库导出需要EXP_FULL_DATABASE角色一般生产环境不会随便给按用户是最常用的一个 schema 一个 dmp迁移时边界清晰按表适合补数据、修单点。参数上ROWSY/N控制要不要带数据CONSISTENTY让导出期间读一致会占用 undoDIRECTY走直接路径绕过 SQL 层、速度快但会锁表。下面这段是我常用的按用户导出模板直接抄# 进入 Oracle 11g 64bit 的 bin 目录路径按实际安装位置改 cd /u01/app/oracle/product/11.2.0/dbhome_1/bin # 按用户导出带数据、读一致、记录日志 ./exp.exe useridapp_user/app_pwd//10.0.0.12:1521/ORCL \ OWNERapp_user \ FILE/backup/app_user_20240601.dmp \ LOG/backup/app_user_20240601.log \ ROWSY \ CONSISTENTY \ STATISTICSNONE \ BUFFER10485760逐项说清楚userid是用户名/密码连接串11g 里连接串用//host:port/service_name最稳别用老式 SID 写法容易踩监听配置的坑OWNER指定 schema多个用逗号隔开FILE和LOG建议都写绝对路径相对路径会落到当前工作目录脚本里容易找不着ROWSY带数据只要结构就改NCONSISTENTY保证导出期间数据一致大表导出时 undo 表空间要留够不然会报ORA-01555STATISTICSNONE跳过统计信息迁移后重新收集更干净BUFFER调大能减少 IO 次数10M 是个稳妥值内存紧张就降到 1M。导出完先看 log 尾部有没有successfully completed再看 dmp 文件大小是否符合预期——我见过导出“成功”但文件只有几 KB 的多半是权限或对象名写错实际啥也没抽出来。2.3 imp.exe 的导入顺序与冲突处理导入比导出更容易翻车因为目标库往往已经有东西。imp默认行为是遇到已存在的表就报错跳过所以迁移场景一般配IGNOREY忽略对象已存在错误继续导数据或者干脆先建空用户。关键参数FROMUSER/TOUSER做 schema 映射TABLES只导指定表INDEXESN先不建索引大数据量导入完再建快得多CONSTRAINTSN同理。下面是我迁移单用户的标准动作# 先只导结构验证对象能建出来 ./imp.exe useridnew_user/new_pwd//10.0.0.20:1521/NEWDB \ FILE/backup/app_user_20240601.dmp \ LOG/backup/imp_struct.log \ FROMUSERapp_user TOUSERnew_user \ ROWSN IGNOREY # 结构没问题再灌数据索引和约束先跳过 ./imp.exe useridnew_user/new_pwd//10.0.0.20:1521/NEWDB \ FILE/backup/app_user_20240601.dmp \ LOG/backup/imp_data.log \ FROMUSERapp_user TOUSERnew_user \ ROWSY IGNOREY INDEXESN CONSTRAINTSN GRANTSN \ COMMITY BUFFER10485760FROMUSER/TOUSER是跨 schema 迁移的核心源用户叫app_user、目标叫new_user靠这一对参数完成映射不用改 dmp。COMMITY按数组批量提交避免大表导入时 undo 爆掉但注意它会让失败时回滚不完整所以导入前务必确认目标表是空的或可重建的。INDEXESN、CONSTRAINTSN把建索引和约束推迟几十 G 的数据能省下大量时间导完再单独跑建索引脚本。导入日志要重点搜ORA-开头的行IMP-00019行被拒绝通常是字符集或字段长度问题ORA-00955对象名已存在在IGNOREY下可忽略。字符集这块是玄学源库NLS_CHARACTERSET和目标库不一致时中文大概率变问号导之前一定用SELECT * FROM nls_database_parameters WHERE parameterNLS_CHARACTERSET;两边对一遍不一致就先改目标库字符集或走 Data Pump 的转换。3. 把命令行接进日常流程脚本化与 PL/SQL 协同3.1 用批处理/Shell 包一层避免手敲参数命令行最大的价值是可脚本化。生产上我不会每次手敲而是把连接信息、路径、日志名抽成变量写成一个可复用的脚本。Windows 服务器上用.batLinux 上用.sh逻辑一样拼参数、执行、检查返回码、归档日志。下面是个 Windows 批处理示例注意%ERRORLEVEL%的判断echo off set BIND:\oracle\product\11.2.0\dbhome_1\BIN set DMPD:\backup\app_user_%date:~0,4%%date:~5,2%%date:~8,2%.dmp set LOG%~dp0exp_%date:~0,4%%date:~5,2%%date:~8,2%.log %BIN%\exp.exe useridapp_user/app_pwd//10.0.0.12:1521/ORCL ^ OWNERapp_user FILE%DMP% LOG%LOG% ROWSY CONSISTENTY STATISTICSNONE if %ERRORLEVEL% NEQ 0 ( echo Export failed, check %LOG% exit /b 1 ) echo Export done: %DMP%%date:~0,4%这类截取是拿系统日期拼文件名避免覆盖^是批处理的续行符别漏%ERRORLEVEL%非 0 就退出并提示看日志这样挂到任务计划里失败能被监控捕获。Linux 下同理用date %Y%m%d拼名、$?判返回码。我一般还会在脚本末尾加一句grep -c ORA- $LOG非零就告警——导出“成功”但日志里藏 ORA 错误的情况太常见了。3.2 和 PL/SQL Developer 的配合姿势PL/SQL Developer 的导入导出菜单底层调的就是imp.exe/exp.exe只是它帮你拼了参数。所以当图形界面卡死或报错信息不全时正确做法不是反复点而是去它的“工具-导入表/导出表”里把生成的命令看一眼或者直接自己写命令行。实操里我常用 PL/SQL 做两件事一是导之前用SELECT COUNT(*)核对每张表行数导完再核一遍行数对不上立刻定位是哪张表被IMP-00019拒了二是用它跑建索引、收集统计信息的脚本比命令行里敲 SQL 舒服。注意 PL/SQL 导出时如果勾了“包含行”大表一样会卡这时候就该切命令行加DIRECTY或分表导。还有个细节PL/SQL 调exp时工作目录可能不是你以为的那个dmp 会落到奇怪的地方所以自己写脚本时路径一律用绝对路径别赌。3.3 版本匹配与 32/64 位的坑bin目录是 64 位安装自带的exp.exe/imp.exe也是 64 位。客户端和服务端版本有个老规矩导出工具版本不能低于源库版本导入工具版本不能低于 dmp 的导出工具版本。11g 的exp去连 12c 以上的库大概率报ORA-28040或直接不认这种就得换对应版本的客户端。另外 32 位客户端连 64 位库本身没问题但如果你混用了不同位数的bin目录可能遇到ORA-12154解析不到服务名——本质是tnsnames.ora和sqlnet.ora不在当前ORACLE_HOME下。我一般先echo %ORACLE_HOME%或echo $ORACLE_HOME确认环境变量指向哪个 home再确认bin是不是那个 home 下的别拿 A 安装的 exe 去连 B 配置的库。4. 避坑与排查那些让导入导出“假成功”的细节4.1 现象导出日志显示成功dmp 却只有几 KB原因通常是OWNER写错或当前用户没权限exp找不到对象就“成功”退出实际零对象。解决导出前先SELECT COUNT(*) FROM dba_tables WHERE ownerAPP_USER;确认对象存在导出后看日志里exporting table的行数零行就是没抽到东西。我习惯在脚本里加一句对象数校验对不上直接 fail。4.2 现象导入报 IMP-00019 行被拒绝中文变问号原因是源库和目标库NLS_CHARACTERSET不一致或者 dmp 里字段长度超过目标表定义。解决先对两边字符集不一致优先改目标库建库时定后期改风险高字段长度问题看日志里具体表和列ALTER TABLE ... MODIFY扩长后重导该表。字符集这块没有后悔药导之前对一遍能省一整天。4.3 现象大表导入到一半 ORA-01555 或 undo 表空间满原因是COMMITN默认导致整个表一个事务undo 撑爆。解决加COMMITY BUFFER10485760让imp按数组批量提交同时确认目标库 undo 表空间有足够余量临时扩一下再导。注意COMMITY下失败不会整体回滚所以导入前目标表最好是空的或可重建。4.4 现象imp 报 ORA-00955 对象名已存在大量表被跳过原因是目标库已有同名对象而IGNORE没开。解决迁移场景加IGNOREY继续导数据如果是重复导入同一批表先DROP或TRUNCATE再导别指望imp帮你覆盖。我一般导之前跑一遍“目标 schema 对象清单”和 dmp 里的对象对一遍心里有数再动手。4.5 现象命令行能连PL/SQL 里导出却报连接失败原因是 PL/SQL 用的ORACLE_HOME或TNS_ADMIN和你命令行环境不一致找的是另一套tnsnames.ora。解决统一环境变量或在连接串里直接用//host:port/service绕开 tns 解析。这个坑在装了多个 Oracle 客户端的机器上特别常见bin目录有好几份认准你要用的那份。5. 进阶技巧用 DIRECT 路径和分片导出压榨老工具数据量再往上走传统exp的单线程会成为瓶颈。我常用的两个提速手段一是DIRECTY走直接路径绕过 SQL 引擎直接读数据文件块速度能翻倍代价是导出期间表被锁、不能有活动事务所以只能放在维护窗口跑二是按表分片把大表拆成多个TABLES(t1,t2)的批次并行跑多个exp进程最后分别imp用时间换并发。下面这个分片脚本思路是把表清单按行数排序后切成 N 份# 从数据字典取大表清单按块数降序切成 4 片分别导出 sqlplus -S app_user/app_pwd//10.0.0.12:1521/ORCL EOF SET HEADING OFF FEEDBACK OFF PAGESIZE 0 SELECT table_name FROM ( SELECT table_name FROM user_tables ORDER BY blocks DESC ) WHERE ROWNUM 40; EOF # 将输出按 10 行一组切分分别调用 exp此处省略切分逻辑可用 awk NR%4思路说明先按blocks占用块数降序拿大表保证每片负载均衡切分后每片单独exp日志分开记哪片失败一目了然。DIRECTY和分片不要同时用在同一张表上直接路径本身会锁表并行反而互相等。验证方法很土但有效导完对每张表跑SELECT COUNT(*)和源库逐表比对行数一致再切业务。从那以后我每次做老库迁移都强制先跑一遍“对象数 每表行数”的双重核对再谈导入成功——exp/imp的“成功”两个字信一半就好。希望帮到你。本文还有配套的精品资源点击获取