Oracle RAC中并行执行默认跨节点分配，需通过parallel_instance_group控制调度范围，instance_groups仅为节点标签；设parallel_instance_group='local_node'并确保对应instance_groups包含该值，可限制并行仅在本节点执行，避免GC开销。
oracle rac 中并行执行默认会跨所有节点分配从属进程，但若未显式控制 instance_groups 或 parallel_instance_group，容易导致网络争用、gc 压力激增甚至查询变慢——这不是并行没开，而是并行“跑偏”了。
parallel_instance_group 与 instance_groups 的实际作用差异
这两个参数共同决定并行进程在哪些节点上启动，但行为完全不同：
-
instance_groups是节点“归属标签”，定义该实例属于哪个逻辑组（如'dw'、'oltp'），本身不触发任何调度逻辑 -
parallel_instance_group才是真正生效的调度开关：当它被设为某个 group 名（如'dw'），并行查询只会在所有instance_groups包含该值的节点上启动从属进程 - 若
parallel_instance_group为空（默认），则并行进程可跨集群中所有 UP 状态的节点分配——哪怕业务本不该跨节点
常见错误是只改了 instance_groups 却没设 parallel_instance_group，结果并行任务仍打散到全部节点，引发大量 gc cr block busy 等等待。
如何限制并行只在本节点执行（避免跨节点 GC 开销）
当某类报表或 ETL 作业对延迟敏感、且数据已本地化（比如按节点做了分区路由），应强制并行不出本节点：
- 在会话级设置：
ALTER SESSION SET parallel_instance_group = 'local_node'; - 同时确保当前节点的
instance_groups包含'local_node'（如ALTER SYSTEM SET instance_groups='local_node' SCOPE=SPFILE SID='rac1';） - SQL 中仍需保留 hint，如：
SELECT /*+ PARALLEL(t, 16) */ COUNT(*) FROM big_table t;，否则优化器可能退化为串行 - 验证是否生效：查
GV$PX_SESSION，INST_ID列应全部等于当前节点 ID
注意：不要依赖 PARALLEL_FORCE_LOCAL=TRUE（12c+ 已废弃），该参数在 RAC 下不可靠，且无法控制 coordinator 行为。
_PX_use_large_pool=TRUE 对并行内存分配的实际影响
并行进程默认从 Shared Pool 分配消息缓冲区（如 PX message pool），高并发下极易引发 library cache lock 或 shared pool latch 争用：
- 设
_PX_use_large_pool=TRUE后，并行消息缓冲区改从 Large Pool 分配，彻底隔离 Shared Pool 压力 - 必须同步增大
LARGE_POOL_SIZE（建议 ≥ 2GB），否则首次并行执行会报ORA-04031: unable to allocate ... bytes of shared memory - 该参数需重启生效（
SCOPE=SPFILE），且对所有并行操作全局生效，不能按 session 控制 - 实测显示：在 4 节点 RAC 上开启后，
gc buffer busy acquire等等待下降约 35%，尤其在大表 HASH JOIN 场景下效果明显
为什么 _gc_policy_time=0 和 _gc_undo_affinity=FALSE 必须配合并行调优
这两个隐含参数关闭 DRM（Dynamic Remastering），看似和并行无关，实则关键：
- DRM 会在并行扫描期间频繁重映射数据块 master 节点，导致正在传输的块被强制中断，引发大量
gc current/cr block lost - 并行任务越长、扫描范围越大，DRM 触发概率越高；一旦发生，整个并行协调器可能 hang 住数秒甚至分钟
-
_gc_policy_time=0禁用 DRM 定时检查，_gc_undo_affinity=FALSE阻止 undo 段自动绑定到访问节点——两者必须同时设置才有效 - 这是生产环境 RAC 并行作业稳定性的底线配置，漏掉任意一个都可能在高负载时突然出现不可解释的长延时
真正难的不是知道要设哪些参数，而是理解它们之间如何连锁反应：一个并行 SQL 的执行路径，会同时穿过 instance_group 调度层、PX 内存分配层、GC 资源管理层。改其中一环，不补全其他环节，大概率让问题从一个地方转移到另一个更隐蔽的地方。
