Java调用Oracle Data Pump必须通过SSH远程执行expdp/impdp命令，不能直连数据库或仅用JDBC调用DBMS_DATAPUMP；需预配DIRECTORY对象、环境变量及权限，并解析stdout日志判断真实状态。
Java 调用 Oracle Data Pump 必须走操作系统命令，不能直连数据库执行
oracle data pump（expdp/impdp）是服务端工具，运行在数据库服务器本地，不提供 jdbc 接口或 pl/sql 过程直接触发导出/导入任务。java 应用只能通过 runtime.exec() 或 processbuilder 启动远程服务器上的命令，本质是“远程执行 shell 命令”，而非“调用数据库功能”。
这意味着：你必须确保 Java 应用所在机器能以某种方式登录目标数据库服务器（如 SSH），且该服务器已安装 Oracle Client + Data Pump 环境，并配置好对应用户的 Oracle 环境变量（ORACLE_HOME、PATH、TNS_ADMIN 等）。
常见错误现象：Exception in thread "main" java.io.IOException: Cannot run program "expdp": error=2, No such file or directory —— 说明目标机器没配好环境，或 Java 进程根本没在数据库服务器上运行。
- 不要尝试用
CallableStatement调用DBMS_DATAPUMP包来“绕过命令行”：它只能创建 job，但 job 仍需数据库后台进程执行，且无法跨实例控制远程 Data Pump；更关键的是，DBMS_DATAPUMP不暴露导出文件路径、日志位置等应用层需感知的关键参数 - 若 Java 应用和 Oracle 数据库不在同一台机器，必须借助 SSH（如 JSch）先建立连接，再在远端执行
expdp，不能只靠本地ProcessBuilder - Windows 上若用
cmd /c expdp ...，注意转义特殊字符（如&、|、空格路径），Linux 下同理需处理单引号、美元符
使用 JSch 实现安全、可控的远程 expdp/impdp 执行
JSch 是最常用的纯 Java SSH 客户端库，适合从应用服务器发起对 Oracle 服务器的命令调用。重点不是“能不能连”，而是“如何让命令可靠执行并捕获结果”。
关键点在于：Data Pump 命令常需交互式确认（如覆盖已有 dump 文件）、超时等待、日志解析。JSch 的 ChannelExec 默认不分配伪终端（PTY），导致某些环境下的 expdp 报错 ORA-39002: invalid operation 或静默失败。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 必须调用
setPty(true)开启伪终端，否则expdp可能因检测不到标准输入而拒绝运行 - 务必设置超时（
connect(10000)），避免因远端卡死导致 Java 线程永久阻塞 - 不要只读
InputStream（stdout），expdp的进度、错误、警告全混在InputStream中；getErrorStream()在 PTY 模式下通常为空，所有输出都走 stdout - 示例片段（简化）：
ChannelExec channel = (ChannelExec) session.openChannel("exec"); channel.setCommand("expdp system/password@orcl DIRECTORY=dp_dir DUMPFILE=backup.dmp LOGFILE=expdp.log SCHEMAS=scott"); channel.setPty(true); channel.connect(10000);
Directory 对象权限与文件路径必须由 DBA 预先配置，Java 无法动态创建
expdp 的 DIRECTORY 参数不是任意路径，而是数据库中已存在的 DIRECTORY 对象（如 SELECT * FROM dba_directories;）。Java 传入的 dp_dir 必须已在目标库中创建，且执行用户（如 system）被显式授予 READ、WRITE 权限：
CREATE OR REPLACE DIRECTORY dp_dir AS '/u01/app/oracle/dpdump'; GRANT READ, WRITE ON DIRECTORY dp_dir TO system;
常见陷阱：
- 误以为传入绝对路径（如
/u01/app/oracle/dpdump/backup.dmp）就能绕过 DIRECTORY ——expdp会直接报错ORA-39001: invalid argument value - 目录物理路径在数据库服务器上不存在，或 Oracle 用户（如
oracle）无写权限，导致expdp写日志失败，进程退出码为 0 但实际没生成 dump 文件 - Windows 路径用反斜杠（
）定义 DIRECTORY，但 Oracle 内部可能解析异常；统一用正斜杠（/）或双反斜杠（\）
日志解析与状态判断比启动命令更难，别依赖 exitCode 做成功判定
expdp 进程退出码（process.exitValue()）只有 0（正常结束）、1（警告）、2（严重错误）、3（致命错误）四档，但实际业务中，“警告”（exitCode == 1）可能意味着部分对象未导出（如权限不足的表），而“正常结束”（0）也可能伴随 ORA-31684: Object type ... already exists 这类非致命提示 —— Java 应用无法仅靠 exitCode 区分“可接受的警告”和“需人工介入的故障”。
- 必须实时读取 stdout 输出流，逐行匹配关键字：
Processing object type（开始）、Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed（成功）、ORA-（错误）、Completed %（进度） - 建议将完整日志落盘（通过
LOGFILE=xxx.log参数），再由 Java 后续解析，避免流读取遗漏或乱序 - 不要忽略
expdp的异步特性：命令返回不代表任务完成。例如加了ATTACH参数后，主进程很快退出，实际 job 在后台跑 —— 此时需额外轮询dba_datapump_jobs视图
真正麻烦的从来不是怎么让 Java “敲一下回车”，而是如何确认那台远程服务器上的 Oracle 进程确实按你的预期完成了事，且中间没被磁盘满、锁表、网络抖动悄悄打断。这些细节藏在日志里，不在 exitCode 里。
