根本原因是跨节点数据传输和资源争用拖累性能；rac中px进程跨节点访问非本地缓存块会触发高延迟gc请求，导致gc current block 2-way等等待事件占比超15%，同时shared pool latch争用、自适应计划抖动及缺乏数据局部性进一步恶化性能。
Oracle 12c RAC 中并行查询（Parallel Query）性能上不去，根本原因往往不是并行度设低了，而是跨节点数据传输和资源争用在拖后腿。 单实例调高 PARALLEL_THREADS_PER_CPU 可能有效，但在 RAC 环境下盲目加并行进程数，反而会放大 Cache Fusion 开销、触发大量 Global Cache（GC）等待，甚至让查询变慢。
为什么RAC里并行查询容易变慢
RAC 的并行执行单元（PX 进程）可能被调度到不同节点，而它们要访问的数据块不一定本地缓存。一旦发生跨节点读取，就会触发 GC CR/Current block 请求，走网络+全局队列+锁协调——这部分延迟远高于本地内存访问。实测中，gc current block 2-way 或 gc cr block busy 等待事件占比超过 15%，基本可判定是并行 + RAC 协同出了问题。
- 并行查询默认不保证数据局部性，即使表做了分区，若未绑定实例组或未启用
PARALLEL_INSTANCE_GROUP，PX 进程仍可能跨节点拉数据 - RAC 下的
Shared Pool是全局共享的，大量并行子游标（child cursor）争用library cache lock，尤其在绑定变量未复用或 ACS（Adaptive Cursor Sharing）开启时更明显 - 默认从
Shared Pool分配 PX 消息缓冲区，高并发并行查询会加剧 shared pool latch 争用；而_PX_use_large_pool=TRUE才能切到 Large Pool 隔离内存
必须改的几个关键参数（RAC专属）
这些不是“建议”，而是 RAC 并行场景下绕不开的底层约束。不调整，其他优化效果有限。
- 强制 PX 进程只在本节点执行：
ALTER SYSTEM SET PARALLEL_INSTANCE_GROUP = 'rac_node1' SCOPE=BOTH;（每个实例设为对应实例名，如rac_node1/rac_node2），再配合应用层按业务路由到固定节点 - 关闭自适应特性减少计划抖动：
ALTER SYSTEM SET "_optimizer_adaptive_plans" = FALSE;、ALTER SYSTEM SET "_optimizer_use_feedback" = FALSE;—— RAC 中 adaptive plan 切换易引发节点间统计信息不一致 - 切换 PX 内存分配池：
ALTER SYSTEM SET "_PX_use_large_pool" = TRUE SCOPE=SPFILE;（需重启），避免 shared pool 被 PX 消息撑爆 - 限制单个查询最大并行进程数：
ALTER SYSTEM SET PARALLEL_MAX_SERVERS = 64;（根据节点 CPU 数×2 合理设定），防止突发并行压垮某节点
SQL级控制：别只靠 /*+ PARALLEL(n) */
硬编码并行度在 RAC 里风险很高。同一 SQL 在不同节点跑，n 值相同但实际资源水位不同，容易导致节点负载失衡。更稳妥的方式是结合对象属性与 hint 控制：
- 对大表启用并行 DML/DDL 时，显式指定
PARALLEL (DEGREE 4 INSTANCES 1)，强制限定只在本实例内并行 - 用
/*+ PQ_DISTRIBUTE(t HASH, HASH) */替代默认 broadcast，减少跨节点数据分发量（尤其在 JOIN 场景） - 避免在 RAC 环境对索引组织表（IOT）或 LOB 字段频繁使用并行查询——GC 开销会指数级上升
- 确认统计信息是最新的：
EXEC DBMS_STATS.GATHER_TABLE_STATS('SCHEMA','TABLE', DEGREE=>4);，否则 CBO 可能低估并行收益而拒绝启用 PX
监控时盯死这三个视图和指标
光看 v$px_session 不够，RAC 下必须关联实例维度和 GC 行为：
-
v$pq_tqstat：查每个 TQ（Table Queue）的发送/接收行数，若server_type为QC的行中num_rows极低但buffer_gets很高，说明 QC 在等远程数据 -
v$sysstat中过滤gc%相关统计项，重点关注gc cr blocks received和gc current blocks served的比值，>3 表示严重跨节点拉块 -
v$session_event中查当前并行会话的 top 等待事件，若出现DFS lock handle或enq: PS - contention，说明并行服务器资源已争用到瓶颈
真正卡点不在并行度数字本身，而在数据是否“就地”。RAC 的并行优化，本质是让计算尽量靠近数据，而不是让数据追着计算跑。没做表分区 + 实例绑定 + GC 监控，光调 PARALLEL_THREADS_PER_CPU 就像给自行车装涡轮——听着响，跑不远。
