PARALLEL_FORCE_LOCAL=TRUE会强制并行仅在本地节点执行，导致资源争用和性能下降；真正控制跨节点并行的是parallel_instance_group与instance_groups的配合。
parallel_force_local = true 会彻底禁用跨节点并行，不是“优化”，而是主动退化——除非你明确需要本地隔离执行，否则在 rac 中设为 true 反而拖慢大查询。
为什么 PARALLEL_FORCE_LOCAL = TRUE 让并行变慢
这个参数一开，所有并行从属进程（orap000*）只能挤在发起 SQL 的那个实例上，哪怕其他节点 CPU 空闲 80%、内存充足，也完全不参与。结果就是：
- 单节点资源迅速打满，出现大量
PX Idle Wait和latch: shared pool等待 - 原本可分散到 4 节点的 64 度并行（DOP），被迫压在 1 个节点上，CPU Ready 队列飙升
-
V$PX_SESSION中INST_ID全是同一个值，V$PQ_TQSTAT显示所有数据流都走本地P->S（Producer-Serial）路径，无任何PCWP分发
什么时候才该设 PARALLEL_FORCE_LOCAL = TRUE
只适用于极少数场景，比如：
- 某张表做了严格的节点本地化分区（如按
MOD(ID, 4)路由），且业务逻辑确保所有访问都命中本节点数据块 - 临时跑一个高优先级 ETL 任务，必须独占本节点资源，避免被其他节点的 GC 流量干扰
- 调试阶段想排除跨节点通信干扰，验证纯本地执行性能基线
注意：PARALLEL_FORCE_LOCAL 在 12c+ 已标记为废弃，RAC 下行为不可靠——它不控制 coordinator 分配逻辑，也不影响 parallel_instance_group 的实际调度，仅作为兜底限制。
真正影响跨节点并行的是 parallel_instance_group
决定并行进程能否跨节点的开关，是 parallel_instance_group 和各节点的 instance_groups 配合，不是 PARALLEL_FORCE_LOCAL：
- 若
parallel_instance_group为空（默认），且所有节点instance_groups都含相同值（如'dw'），则并行自动跨全部 UP 实例 - 若只想让某 SQL 在节点 rac1 执行并行，需：
– 在 rac1 上执行ALTER SESSION SET parallel_instance_group = 'rac1';
– 并确保 rac1 的instance_groups包含'rac1'（如ALTER SYSTEM SET instance_groups='rac1' SCOPE=SPFILE SID='rac1';） - 若
parallel_instance_group设为一个不存在于任何节点instance_groups中的值（如'xyz'），SQL 直接报ORA-12850: Could not allocate parallel slaves
19c RAC 并行效率的关键实操点
别只盯着 PARALLEL_FORCE_LOCAL，以下三点更直接影响真实吞吐：
-
_PX_use_large_pool = TRUE必须配合足够大的LARGE_POOL_SIZE（建议 ≥ 2GB），否则首次并行就触发ORA-04031；Shared Pool 争用在高并发下比 GC 延迟更致命 -
PARALLEL_DEGREE_POLICY = MANUAL比AUTO更可控：19c 的自动策略在 RAC 上容易误判全局负载，导致 DOP 过高引发gc cr block busy飙升 - 表级
PARALLEL属性必须显式设置，仅靠 hint 不足以触发跨节点：查SELECT degree, instances FROM dba_tables WHERE table_name = 'T'，degree > 1且instances > 1才算真正启用
跨节点并行不是“开了就能用”，而是调度器在 parallel_instance_group 约束下，结合实时负载、GCS 健康度、对象属性三者动态决策的结果——hint 和表属性只是申请，不是命令。
