根本原因是oracle数据泵仅识别数据库中注册的directory对象，不解析物理路径字符串；必须通过directory对象名前缀（如dumpfile=dpump_dir:scott.dmp）或参数文件指定directory+dumpfile，且directory须由sys等高权限用户创建、指向服务器本地路径、授予执行impdp的数据库用户read/write权限，并确保oracle操作系统用户对该路径有读写权限。
impdp报ora-39002或ora-39070：根本不是目录“不存在”，而是没走directory对象
oracle数据泵不认物理路径，只认数据库里注册过的directory对象。你传dumpfile=/u01/backup/scott.dmp，哪怕路径真实存在、权限也对，照样报错——因为expdp/impdp压根不会去解析这个字符串里的路径部分。
必须用DIRECTORY对象名作前缀：DUMPFILE=dpump_dir:scott.dmp，或者在参数文件里写directory=dpump_dir + dumpfile=scott.dmp。两者缺一不可。
-
CREATE OR REPLACE DIRECTORY必须由SYS或有CREATE ANY DIRECTORY权限的用户执行，普通用户无权创建 - 路径必须是数据库服务器本地路径，不是你本地电脑或客户端机器上的路径
- Oracle进程（通常是
oracle用户）必须对操作系统目录有读写权限：chown oracle:oinstall /u01/app/oracle/dpdump+chmod 755
GRANT READ,WRITE ON DIRECTORY失败：权限没给对人
授权语句GRANT READ, WRITE ON DIRECTORY dpump_dir TO scott看似正确，但容易踩两个坑：
- 目标用户
scott必须已存在；如果还没建用户，这条授权会静默失败（不报错但无效） - 权限要授给实际运行
impdp命令的数据库用户，不是操作系统用户。比如你用sqlplus scott/tiger@orcl连上再跑impdp，那scott就是执行用户，就得给他授目录权限 - 若用
SYSTEM或SYS账号执行impdp，权限就得授给SYSTEM或SYS，而不是scott
查不到刚建的DIRECTORY：dba_directories视图权限或容器问题
执行SELECT * FROM dba_directories看不到自己建的dpump_dir，常见原因：
- 没用
SYSDBA或DBA角色登录查询，普通用户默认查不到dba_*视图 - 在CDB环境（如19c默认安装）下，
dba_directories只返回CDB$ROOT中的目录对象；如果你在PDB里建的目录，得切到对应PDB里查，或改用cdb_directories（需相应权限） - 建目录时拼错了名字，比如
CREATE OR REPLACE DIRECTORY DPUMP_DIR，但后面用的是dpump_dir（大小写敏感且未加引号），Oracle会转成大写，但若你之前建的是小写带引号的"dpump_dir"，那就完全不匹配
ORA-39171卡在resumable wait：别只盯着目录，先看磁盘和表空间
这个错误看起来像目录问题，其实跟目录权限或存在性无关。它表示Data Pump作业被挂起，典型原因是资源不足：
-
DIRECTORY指向的文件系统满了（df -h确认） - 数据库临时表空间或目标表空间不足（
SELECT tablespace_name, used_space, max_size FROM dba_tablespace_usage_metrics） - 导入时指定的
REMAP_TABLESPACE目标表空间不存在或没配自动扩展
日志里不会直接写“磁盘满了”，只会停在Job is experiencing a resumable wait。这时候翻LOGFILE没用，得立刻检查系统级磁盘和数据库空间。
