oracle 19c rac中expdp跨节点调度worker导致导出失败，根源在于directory路径未在所有节点一致可写；必须使用共享存储（如acfs/nfs）、验证各节点oracle用户读写权限、禁用负载均衡service，并优先以parallel=1验证基础环境。
expdp 在 oracle 19c rac 中默认可能跨节点调度 worker 进程，但这不等于“跨节点导出”——而是跨节点写 dump 文件失败的根源。真正能跑通的配置，必须确保所有节点对 directory 路径一致可写、服务绑定明确、并行控制得当。
确认 DIRECTORY 路径是否全节点可写
这是最常被跳过的前提。RAC 下 expdp 的 worker 进程可能被调度到任意存活实例，若 DIRECTORY 指向本地文件系统（如 /u01/dpdump），其他节点无该路径或无权限，立刻报 ORA-39087 或 ORA-39070。
- 查路径：运行
SELECT directory_path FROM dba_directories WHERE directory_name = 'DPUMP_DIR'; - 登录每个 RAC 节点，执行
ls -ld /u01/dpdump，确认属主是oracle，权限至少为755 - 路径必须是共享存储：ACFS、NFS 或集群文件系统；不能是单机
/home/oracle这类本地路径 - Oracle 进程需有写权限：仅
chown oracle:oinstall不够，还要验证su - oracle -c "touch /u01/dpdump/test.$$ && rm /u01/dpdump/test.$$"在每个节点都成功
使用 CLUSTER=N 参数的正确姿势
CLUSTER=N 命令行参数在 19c 中**已被废弃且无效**；真正起作用的是会话级隐含参数 _CLUSTER=FALSE，但它只影响 PL/SQL API 调用（如 DBMS_DATAPUMP），对 expdp 命令本身无直接作用。
- 别在 expdp 命令里写
CLUSTER=N—— 它会被忽略，还可能触发UDE-12541（TNS 错误） - 如果要用
_CLUSTER=FALSE，必须先连进 SQL*Plus：sqlplus / as sysdba，再执行ALTER SESSION SET "_CLUSTER" = FALSE;，然后调用DBMS_DATAPUMP启动作业 - 日常运维中更可靠的做法是：显式连接到单个实例（如
expdp user/pass@db1），并配合INSTANCES=(db1)（注意：它只限制元数据读取范围，不约束 worker 落点） - 真正管用的约束方式是改 service：用
srvctl modify service -s mysvc -n -j SHORT -b NONE -e SESSION关闭负载均衡和故障转移，再让expdp连这个 service
PARALLEL=1 是验证路径通不通的黄金开关
加 PARALLEL 后出错（如 ORA-48128、ORA-39155）往往不是并发本身的问题，而是暴露了底层路径或权限隐患。先关掉并行，才能分清问题归属。
- 导出时强制加
PARALLEL=1：expdp ... PARALLEL=1 DUMPFILE=dpump_dir:full.dmp - 如果
PARALLEL=1成功，说明目录路径、权限、service 配置基本 OK；失败则一定是基础环境问题 - 再试
PARALLEL=2，观察是否仍失败 —— 若失败且错误指向文件名冲突（ORA-39155），说明用了%U但没配足够多的DUMPFILE模板，或压缩 + 并行引发内部竞争 - 生产环境慎用
COMPRESSION=ALL PARALLEL>1：19c 已知在 RAC 下易触发ORA-48128（符号链接校验失败），建议拆成CONTENT=METADATA_ONLY和CONTENT=DATA_ONLY两阶段导出
验证导出作业是否真在单节点运行
光看命令行不保险。RAC 下 job 可能启动在 node1，但 worker 分配到 node2 —— 这种“伪单节点”行为最容易误导排查。
- 导出开始后，立即查
SELECT inst_id, sid, serial#, program FROM gv$session WHERE program LIKE '%DW%';，确认所有 DW 进程都在同一inst_id - 查
SELECT * FROM dba_datapump_jobs;，看STATE是否为EXECUTING，OWNER_NAME和JOB_NAME是否匹配你发起的作业 - 在目标节点上实时监控：
ps -ef | grep -i "dw[0-9]" | grep -v grep，确认进程实际运行在哪台物理机 - 如果发现多节点出现 DW 进程，说明 service 或实例绑定失效，此时
_CLUSTER=FALSE也救不了 —— 必须回归到共享路径 + 禁用负载均衡 service 的组合方案
RAC 数据泵导出最脆弱的环节从来不是命令语法，而是目录路径的“一致性幻觉”：你以为挂了 NFS 就万事大吉，结果忘了某节点 /etc/fstab 里没 auto-mount，或者 ACFS 卷没在所有节点 asmcmd mount。验证必须落到每个节点的 shell 和每个实例的 gv$ 视图里，而不是只看 expdp 是否返回 success。
