简介这是一款基于Java编写的Oracle数据库导入导出桌面工具面向数据库运维人员、开发工程师及对命令行操作不熟悉的技术用户用于解决数据迁移、备份恢复、离线分析等场景下的导入导出需求。压缩包共198个文件约45.31MB以68个dll、25个jar、24个properties、22个exe及字体、证书、配置等支持文件为主构成完整的Java运行与程序资源体系其中jre环境不建议删除否则程序无法启动。工具提供图形化界面简化了表空间、用户密码、数据文件路径、表/模式及压缩选项等参数设置并配套操作说明文档涵盖启动流程、注意事项与常见错误处理。目前已有1985人学习下载适合希望降低Oracle导入导出门槛、快速完成数据迁移与备份恢复的读者参考使用。1. 一次数据迁移引发的工具选型思考上周帮朋友处理一个 Oracle 到 Oracle 的数据迁移源库 11g目标库 19c中间隔着两个版本和一堆字符集差异。他一开始想用 SQL Developer 的导出向导结果 200 多万行的表导到一半直接卡死日志里只留下一句含糊的“stream read error”。后来换成命令行工具同样的数据量十几分钟跑完还顺手把索引和约束一起带过去了。这件事让我意识到Oracle 数据库导入导出这件事图形化工具和命令行工具之间的差距远比想象中大。这份 Oracle 数据库导入导出工具资源核心就是围绕 exp/imp、expdp/impdp 以及 SQL*Loader 这几套官方工具链展开的。它解决的不是“怎么点下一步”的问题而是当数据量上来、版本有差异、字符集不统一时怎么选对工具、配对参数、避开那些让人半夜爬起来查日志的坑。适合已经会用 PL/SQL Developer 或 Navicat 做简单导出但一遇到大表、跨版本、部分表迁移就心里没底的中级从业者。如果你正在做数据库课程设计或者刚接手一个需要把测试库数据搬到生产库的任务这份资源里的参数组合和排查思路能直接抄作业。2. 工具链拆解exp/imp 与 expdp/impdp 的选型边界2.1 两套工具的本质差异exp/imp 是 Oracle 早期提供的客户端工具数据流经过客户端中转适合小数据量、跨网络、跨平台的场景。expdp/impdp 是 10g 之后引入的服务端工具数据直接在数据库服务器上读写文件不经过客户端网络速度差距在数据量超过 10GB 后会非常明显。我做过一个对比测试同一张 8GB 的表exp 导出耗时 22 分钟expdp 只用了 6 分钟差距主要来自网络传输和客户端内存缓冲。但 expdp 有个硬性前提必须先在数据库服务器上创建 DIRECTORY 对象并且 Oracle 进程用户对该目录有读写权限。很多人在 Windows 上装 Oracle 后直接用 expdp报 ORA-39002 和 ORA-39070就是因为没建目录或者路径权限不对。exp 则没有这个限制只要能连上数据库就能跑这也是它在一些临时取数场景下仍然被使用的原因。2.2 参数配置的实操要点先看 expdp 的典型命令结构# 创建目录对象指向服务器上的实际路径 sqlplus / as sysdba CREATE OR REPLACE DIRECTORY dpdir AS /u01/app/oracle/dump; GRANT READ, WRITE ON DIRECTORY dpdir TO scott; # 导出命令按 schema 导出 expdp scott/tigerorcl \ DIRECTORYdpdir \ DUMPFILEscott_%U.dump \ LOGFILEscott_exp.log \ SCHEMASscott \ PARALLEL4 \ COMPRESSIONALL \ CONTENTALLDIRECTORY必须用大写因为 Oracle 内部存储的是大写对象名。DUMPFILE里的%U是通配符配合PARALLEL参数使用时会生成多个文件比如 scott_01.dump、scott_02.dump。PARALLEL4表示启用 4 个并行进程但要注意这需要足够的 CPU 和 I/O 资源盲目调高反而会因为资源争抢变慢。COMPRESSIONALL在 11g 之后可用能显著减小 dump 文件体积但会消耗额外 CPU如果服务器 CPU 本身吃紧建议改成COMPRESSIONDATA_ONLY或者干脆不压缩。导入时的参数对应关系# 导入到目标库重映射 schema 和表空间 impdp system/managertargetdb \ DIRECTORYdpdir \ DUMPFILEscott_%U.dump \ LOGFILEscott_imp.log \ REMAP_SCHEMAscott:scott_new \ REMAP_TABLESPACEusers:users_new \ TABLE_EXISTS_ACTIONREPLACE \ PARALLEL4REMAP_SCHEMA和REMAP_TABLESPACE是跨环境迁移时最常用的两个参数。比如源库用 SCOTT 用户目标库想换成 APPUSER就写REMAP_SCHEMAscott:appuser。TABLE_EXISTS_ACTION有 SKIP、APPEND、TRUNCATE、REPLACE 四个值REPLACE 会先 drop 再 createTRUNCATE 只清数据不删表结构APPEND 是追加数据。生产环境用 REPLACE 要格外小心万一 remap 写错了可能把目标库已有的表给删了。2.3 字符集不一致时的处理策略字符集问题是导入导出里最隐蔽的坑。源库是 ZHS16GBK目标库是 AL32UTF8直接 impdp 进去中文全部变成问号。正确的做法是在导出前确认源库字符集导入时用NLS_LANG环境变量做转换。Linux 下export NLS_LANGAMERICAN_AMERICA.AL32UTF8 impdp ...但 NLS_LANG 只影响客户端和数据库之间的字符集转换如果 dump 文件本身已经是用 GBK 字符集导出的导入到 UTF8 库时Oracle 会自动做转换前提是目标库的字符集是源库字符集的超集。GBK 转 UTF8 是没问题的反过来 UTF8 转 GBK 就可能丢字符。如果数据里包含生僻字或者 emojiGBK 根本存不下这种情况只能改库字符集或者用 SQL*Loader 逐行处理。3. 大表与部分表迁移从数据泵到 SQL*Loader 的落地路径3.1 按表名过滤导出实际工作中很少整库导出更多是按业务模块导几张表。expdp 支持TABLES参数expdp scott/tigerorcl \ DIRECTORYdpdir \ DUMPFILEorders.dump \ LOGFILEorders_exp.log \ TABLESorders,order_items,order_status \ QUERY\WHERE order_date TO_DATE(2024-01-01,YYYY-MM-DD)\QUERY参数可以对每张表加过滤条件但要注意它只对TABLES模式生效而且如果表名和查询条件里有特殊字符需要用反斜杠转义。另外QUERY里的子查询不能引用其他表只能基于当前表的列做过滤。如果过滤条件复杂建议先建一张临时表把数据筛出来再导出临时表。3.2 SQL*Loader 处理外部文件导入当数据来源是 CSV、TXT 或者 Excel 导出的文本文件时SQL*Loader 是更合适的选择。它比外部表灵活比 insert 语句快。一个典型的控制文件-- orders.ctl LOAD DATA INFILE orders.csv BADFILE orders.bad DISCARDFILE orders.dsc APPEND INTO TABLE orders FIELDS TERMINATED BY , OPTIONALLY ENCLOSED BY TRAILING NULLCOLS ( order_id INTEGER EXTERNAL, order_date DATE YYYY-MM-DD HH24:MI:SS, customer_id INTEGER EXTERNAL, amount DECIMAL EXTERNAL, status CHAR(20), remark CHAR(500) )OPTIONALLY ENCLOSED BY 处理字段里包含逗号的情况比如备注字段写成了hello, world。TRAILING NULLCOLS允许数据行末尾缺少字段时自动填 NULL不然会报错。BADFILE和DISCARDFILE分别记录格式错误和不符合条件的记录导入完成后一定要检查这两个文件里面往往藏着数据质量问题。执行命令sqlldr scott/tigerorcl \ controlorders.ctl \ logorders_sqlldr.log \ badorders.bad \ errors100 \ directtruedirecttrue启用直接路径加载绕过 SQL 引擎速度比常规路径快很多但代价是加载期间表会被锁定而且不会触发触发器。如果表上有触发器或者需要实时可见就去掉这个参数。errors100表示允许 100 条错误记录超过就终止。生产环境建议设小一点比如errors0有问题立刻停下来排查。3.3 增量同步的取巧方案如果需求是每天同步增量数据用 expdp 全量导出再导入就太笨了。常见做法是建一张增量临时表用MERGE INTO或者INSERT ... SELECT配合时间戳字段做增量拉取。比如-- 在目标库建增量表 CREATE TABLE orders_inc AS SELECT * FROM orders WHERE 10; -- 每天从源库拉取前一天的数据 INSERT INTO orders_inc SELECT * FROM orderssource_link WHERE update_time TRUNC(SYSDATE) - 1 AND update_time TRUNC(SYSDATE); -- 合并到主表 MERGE INTO orders t USING orders_inc s ON (t.order_id s.order_id) WHEN MATCHED THEN UPDATE SET t.amount s.amount, t.status s.status WHEN NOT MATCHED THEN INSERT VALUES (s.order_id, s.order_date, s.customer_id, s.amount, s.status, s.remark);这种方式依赖数据库链路source_link需要源库和目标库之间网络互通并且源库用户有 CREATE DATABASE LINK 权限。如果网络不通就只能用 expdp 导出增量数据到文件再通过文件传输搬到目标库导入。TRUNC(SYSDATE)是 Oracle 里常用的日期截断函数取当天零点配合-1就是前一天零点。4. 避坑排查导入导出中那些让人血压升高的瞬间4.1 ORA-39002 与 ORA-39070目录对象没建对现象执行 expdp 立刻报 ORA-39002 invalid operation 和 ORA-39070 unable to open the log file。原因DIRECTORY 对象不存在或者 Oracle 进程用户对目录路径没有写权限。Windows 上还可能是路径用了反斜杠Oracle 不认。解决先用SELECT * FROM dba_directories;确认目录对象存在再用ls -ld /u01/app/oracle/dump检查权限。Linux 下 Oracle 用户必须对该目录有 rwx 权限Windows 下要确保路径是D:\dump这种格式并且在 Oracle 服务里配置了正确的用户。4.2 ORA-01555快照过旧现象导出大表时跑到一半报 ORA-01555 snapshot too old。原因UNDO 表空间不够或者导出时间太长UNDO 数据被覆盖了。expdp 在一致性读模式下需要保留导出开始时刻的数据镜像。解决临时加大 UNDO 表空间或者用FLASHBACK_TIME参数指定一个较近的时间点。更根本的办法是错峰导出避开业务高峰期减少 UNDO 压力。如果表特别大考虑分区导出每次只导一个分区。4.3 导入后索引和约束丢失现象impdp 导入完成后表数据都在但索引、主键、外键全没了。原因导出时用了CONTENTDATA_ONLY只导了数据没导元数据。或者导入时EXCLUDE参数把约束排除了。解决检查导出命令里的CONTENT参数需要元数据就用CONTENTALL或CONTENTMETADATA_ONLY。如果已经导入了数据可以单独再导一次元数据impdp ... CONTENTMETADATA_ONLY。另外EXCLUDEINDEX,CONSTRAINT这种写法会明确排除索引和约束除非有特殊需求否则不要加。4.4 字符集转换导致中文乱码现象导入后查询中文显示为问号或者乱码。原因源库和目标库字符集不一致且 NLS_LANG 设置错误。解决导出前用SELECT * FROM nls_database_parameters WHERE parameterNLS_CHARACTERSET;确认源库字符集。导入时设置NLS_LANG为目标库字符集比如export NLS_LANGAMERICAN_AMERICA.AL32UTF8。如果 dump 文件已经生成且乱码只能重新导出没有后悔药可吃。4.5 并行度设置过高导致性能下降现象设置了PARALLEL8结果比单线程还慢。原因并行进程争抢 I/O 和 CPU 资源或者 dump 文件所在的磁盘本身带宽不够。解决并行度不是越高越好一般建议设置为 CPU 核数的一半到相等。先用PARALLEL2跑一次观察系统负载再逐步调高。另外DUMPFILE要配合%U使用否则多个并行进程会写同一个文件导致冲突。5. 验证导入结果与几个提效习惯导入完成后别急着交差先跑几个验证查询。第一核对表数量SELECT COUNT(*) FROM user_tables;和源库对比。第二核对关键表行数SELECT COUNT(*) FROM orders;大表可以用SELECT COUNT(*) FROM orders SAMPLE(1);估算。第三检查无效对象SELECT object_name, object_type FROM user_objects WHERE statusINVALID;如果有无效的存储过程或函数需要重新编译。-- 重新编译无效对象 BEGIN FOR rec IN (SELECT object_name, object_type FROM user_objects WHERE statusINVALID) LOOP IF rec.object_type PROCEDURE THEN EXECUTE IMMEDIATE ALTER PROCEDURE || rec.object_name || COMPILE; ELSIF rec.object_type FUNCTION THEN EXECUTE IMMEDIATE ALTER FUNCTION || rec.object_name || COMPILE; ELSIF rec.object_type VIEW THEN EXECUTE IMMEDIATE ALTER VIEW || rec.object_name || COMPILE; END IF; END LOOP; END; /这个匿名块会遍历所有无效对象并尝试重新编译。注意如果无效是因为依赖的表或视图确实不存在编译会再次失败这时候需要先解决依赖问题。还有一个习惯每次 expdp/impdp 都保留完整的日志文件并且在命令里加上LOGTIMEALL参数。这样日志里会记录每个步骤的耗时出问题时能快速定位是卡在哪个环节。我一般会在导出脚本开头加一行date结尾再加一行date这样日志里能直接看到总耗时不用去翻 Oracle 的日志时间戳。另外如果经常需要导同样的几张表可以把 expdp 命令写成一个 shell 脚本参数用变量替换。比如#!/bin/bash DATE$(date %Y%m%d) DUMPFILEorders_${DATE}.dump LOGFILEorders_${DATE}.log expdp scott/tigerorcl \ DIRECTORYdpdir \ DUMPFILE${DUMPFILE} \ LOGFILE${LOGFILE} \ TABLESorders,order_items \ CONTENTALL \ COMPRESSIONDATA_ONLY \ LOGTIMEALL这样每天跑一次dump 文件自动按日期命名不会覆盖。脚本里还可以加一个判断如果 expdp 返回码不是 0就发邮件告警。这些细节看起来不起眼但真到了出问题的时候能省下大量翻日志的时间。从那以后我每次做导入导出都强制走一遍“确认字符集、检查目录权限、保留完整日志、导入后验证行数”这四步。希望帮到你。本文还有配套的精品资源点击获取