根本不是节点多了“拖慢”，而是Cache Fusion跨节点数据块传输导致性能下降；应优先检查AWR中gc cr multi block request等GC类等待是否进入Top 5，而非直接分析执行计划。
根本不是节点多了“拖慢”，而是跨节点数据块传输（Cache Fusion）在悄悄吃掉性能——多数人第一反应查执行计划，其实该先看 gc cr multi block request 等等待事件是否进了 Top 5。
看 AWR 的 Top 5 Timed Events 是否有 GC 类等待
两个节点跑同一 SQL 耗时差异大，优先怀疑的不是 SQL 写法或统计信息，而是节点间缓存同步开销。打开 AWR 报告，直奔 “Top 5 Timed Foreground Events” 页面：
- 如果
gc cr multi block request、gc current block 2-way、gc buffer busy acquire进了前五，基本可断定是 Cache Fusion 导致的远程读/写阻塞 -
gc cr block lost高 → 不是数据库问题，是私网丢包（网卡、交换机、UDP receive buffer 设置过小） - 单次
gc cr multi block request等待超 100ms 就异常；正常应在 1–5ms 级别，别只看平均值
用 dba_hist_active_sess_history 定位具体会话的等待链
AWR 是聚合视图，掩盖了“那一秒发生了什么”。真正要还原现场，得靠 dba_hist_active_sess_history，它每 10 秒采样一次活跃会话：
- 先缩小时间范围：
SELECT MIN(sample_time), MAX(sample_time) FROM dba_hist_active_sess_history WHERE sample_time > SYSDATE - 1/24 - 再抓问题时段典型会话：
SELECT session_id, event, p1text, p2text, blocking_session FROM dba_hist_active_sess_history WHERE event LIKE 'gc%' AND sample_time BETWEEN ... - 重点看
p2text = 'file#'和p2值：如果都指向同一组数据文件（比如 file# = 5,6），说明热点块集中在某几个数据文件，且只在节点 1 缓存，节点 2 每次都要远程拉
确认 parallel_force_local 是否生效及 VIP 绑定是否稳定
RAC 下并行查询默认可能跨节点分发，哪怕参数设了 parallel_force_local=TRUE，若连接层没配合，照样无效：
- 检查当前值：
SHOW PARAMETER parallel_force_local—— 必须为TRUE，且SID='*'表示对所有实例生效 - 应用连接串中的
HOST必须是对应节点的 VIP（如172.16.1.11），不能是 SCAN 或公网 IP；否则该参数不触发 - 验证是否真走本地：
SELECT inst_id, server_name FROM gv$px_process，结果里inst_id应全等于当前实例 ID
检查数据局部性与实例组绑定
即使表做了分区，RAC 默认也不保证 PX 进程访问的数据块在本地缓存。没有显式绑定，就容易触发大量 GC：
- 设置实例组：
ALTER SYSTEM SET PARALLEL_INSTANCE_GROUP = 'rac_node1' SCOPE=BOTH;（每个实例设对应名） - 确保业务连接固定打到该节点 VIP，而非通过 SCAN 随机分配
- 避免盲目调高
PARALLEL_MAX_SERVERS：RAC 中加并行数 ≠ 线性提速，反而放大 GC 压力；建议按 CPU 数 × 2 合理设定
真正难的不是发现 gc 等待，而是区分它是“暂时性热点迁移”还是“架构级数据分布缺陷”——前者重启应用或清缓存可缓解，后者必须改分区策略或做应用路由固化。
