PARALLEL参数在RAC中起作用，但默认不跨节点；Data Pump的Worker进程仅在发起作业的实例上运行，是否跨节点取决于PARALLEL_INSTANCE_GROUP、CLUSTER设置、分区属性及GCS状态，而非PARALLEL值本身。
PARALLEL参数在RAC环境里到底起不起作用
起作用，但默认不跨节点。oracle data pump的parallel参数在rac中能启动多个worker进程，但这些进程默认只在发起作业的实例上运行——哪怕其他节点cpu空闲、磁盘io压力低，也不会自动调度过去。
真正决定是否跨节点的是Master进程的资源分配策略，不是PARALLEL值本身。它只告诉Master“最多允许几个Worker”，而Worker在哪跑，要看：PARTITION属性、CLUSTER参数、实例间GCS通信状态，以及你有没有显式禁用跨节点（比如PARALLEL_INSTANCE_GROUP被设成单实例名）。
- 如果
CLUSTER=Y（默认），且目标对象是分区表并启用了PARTITION，Worker更可能分散到多个节点 - 如果
CLUSTER=N，所有Worker强制落在本地实例，哪怕RAC有4个节点也只用1个 -
PARALLEL_INSTANCE_GROUP设为'*'或未设置，才允许跨节点；设为'inst1'就锁死在inst1
为什么设置了PARALLEL=8却只看到4个Worker在跑
常见现象：命令写了PARALLEL=8，但SELECT * FROM DBA_DATAPUMP_JOBS查出CURRENT_PARALLELISM始终是4，或者v$session里只看到4个ora_p00*进程。
原因不是参数没生效，而是系统主动降级了。Oracle会根据实时资源水位动态调整实际并行度，关键约束包括：
-
PARALLEL_MAX_SERVERS值低于请求的8（查v$parameter确认） - 当前实例PGA已接近
PGA_AGGREGATE_LIMIT，每个Worker需独立PGA内存区 - ASM磁盘组延迟超过20ms，Master检测到I/O瓶颈后主动限流
- RAC环境下，若GCS心跳异常或全局锁争用高（如
gc cr block busy等待多），也会抑制Worker派发
COMPRESSION + PARALLEL组合在RAC上容易报ORA-48128和ORA-39155
这不是Bug，是设计冲突。当同时启用COMPRESSION=all和PARALLEL>1时，多个Worker进程会并发尝试解析%U通配符生成文件名，而压缩流写入又依赖原子性文件句柄——RAC节点间NFS或ACFS共享存储的缓存一致性机制，在高并发文件创建场景下无法保证顺序，导致符号链接误判或dumpfile名扩展失败。
绕过方式只有两个：
- 放弃
%U，改用固定文件名+FILESIZE分卷，例如：DUMPFILE=exp_full_%U.dmp FILESIZE=10G→ 改为DUMPFILE=exp_full_01.dmp,exp_full_02.dmp,... - 拆成两阶段：先用
CONTENT=METADATA_ONLY PARALLEL=1导出元数据，再用CONTENT=DATA_ONLY COMPRESSION=all PARALLEL=8导出数据（注意加CLUSTER=N避免元数据写冲突）
RAC下怎么确认Worker真跨节点了
不能只看DBA_DATAPUMP_JOBS.CURRENT_PARALLELISM，得查实际进程分布：
在每个RAC节点上执行：
ps -ef | grep ora_p00 | grep -v grep，对比各节点的
ora_p00*数量。如果节点1有3个、节点2有5个，说明跨了。
更准的方式是查v$px_session视图（需在对应实例上查）：
SELECT qcsid, server_group, server_set, degree FROM v$px_session WHERE qcsid IN (SELECT sid FROM v$session WHERE program LIKE '%DW%');其中
qcsid是Query Coordinator的SID，server_group非零表示该Worker属于跨节点并行组。
最容易被忽略的一点：即使Worker跨节点，如果导出目录DIRECTORY指向本地文件系统（比如/u01/backup），那么所有Worker仍只能往本节点的路径写——必须用集群文件系统（OCFS2、ASM Cluster File System）或NFSv4.1+带lease支持的共享存储，否则PARALLEL再大也白搭。
