应查询DBA_HIST_SYSTEM_EVENT按INSTANCE_NUMBER分组分析等待事件分布，因其反映跨快照的持续负载模式，比单实例AWR报告更准确识别全局瓶颈。
怎么看 RAC 集群各节点的等待事件分布？
直接查 dba_hist_system_event 按 instance_number 分组，比看单个 awr 报告里的“top 5 timed events”更准——后者默认只展示当前实例，容易误判全局瓶颈。
关键点是：必须用 DBA_HIST_SYSTEM_EVENT 而非 V$SYSTEM_EVENT，因为后者只反映当前时刻，而负载不均往往是持续数分钟以上的模式，需要跨快照对比。
- 执行时加
WHERE SNAP_ID BETWEEN X AND Y限定分析窗口（比如业务高峰期的连续 3 个快照） - 聚合时务必包含
EVENT、INSTANCE_NUMBER、SUM(TIME_WAITED_MICRO)/1000000（转为秒），避免只看等待次数 - 特别注意
gc cr block busy、gc buffer busy acquire、enq: TX - row lock contention这类跨实例争用事件，它们在某节点上显著偏高，基本就是负载倾斜的根因
为什么 gc cr block busy 在节点1远高于节点2？
这不是网络延迟问题，大概率是节点1承担了过多的“一致性读请求”，根源常出在应用连接没打散或 SQL 执行计划不稳定。
典型场景：应用使用单一 service_name 连接，且未配置 LOAD_BALANCE=ON；或某个大表全表扫描 SQL 在节点1上反复执行，触发大量远程块获取。
- 检查
DBA_SERVICES中该 service 的FAILOVER_METHOD和LOAD_BALANCE是否均为YES - 用
DBA_HIST_SQLSTAT查找INSTANCE_NUMBER = 1且EXECUTIONS_DELTA > 0的高逻辑读 SQL，重点关注SQL_ID在节点2是否几乎不执行 -
gc cr block busy时间高但gc cr blocks received不高？说明不是传输慢，而是本地 buffer cache 没命中、又等不到远程块——可能该节点 shared pool 或 db_cache_size 设置偏低
AWR 报告里 “Global Cache Load Profile” 数值怎么看？
这里每秒 GC 请求量（gc cr blocks received + gc current blocks received）本身没意义，要看它和本节点逻辑读的比值。比值 > 0.3 就值得警惕，> 0.5 基本确认存在严重跨节点访问放大。
更关键的是看差值：节点1的 gc cr blocks received 是节点2的 3 倍，但节点1的 logical reads 只比节点2高 20% ——这说明节点1在替节点2干活，负载分配机制已失效。
- 别只盯着“Global Cache Efficiency”那个百分比，它掩盖了节点间差异
- 导出 AWR 数据时，用
awrrpti.sql（而非awrrpt.sql）指定INSTANCE_NUMBER单独生成各节点报告，再横向对比 - 如果
gc current block pin等待也同步升高，说明热点块集中在某节点 buffer cache，需结合DBA_HIST_SEG_STAT查具体对象
调整 service 后负载还是不均？下一步查什么？
service 层负载均衡只是第一道关，真正卡住的常是底层资源绑定——比如某个节点的 CPU 被后台进程长期占满，导致无法及时响应 GC 请求。
此时要跳过 SQL 和等待事件，直奔操作系统级指标：用 DBA_HIST_OSSTAT 查各节点的 BUSY_TIME、IDLE_TIME、PHYSICAL_MEMORY_BYTES，再关联 DBA_HIST_SYSMETRIC_SUMMARY 中的 CPU Usage Per Sec 和 Host CPU Utilization (%)。
- 节点1的
HOST_CPU_UTILIZATION长期 > 90%，但DB CPU只占 40%？说明有非 Oracle 进程（如备份脚本、监控 agent）在抢资源 - 节点2的
PHYSICAL_MEMORY_BYTES明显低于节点1？可能是MEMORY_TARGET没对齐，或启动时被 OS OOM killer 干掉过进程 - 检查
CRSCTL STATUS RESOURCE -T | GREP ora.输出中各节点的ora.asm、ora.cssd状态是否完全一致，状态不同步会导致 OCR 访问异常，间接引发 GC 延迟
真实环境里，RAC 负载不均很少是单点原因。AWR 只告诉你“哪里疼”，但止痛得一层层剥开：从 service 分发 → SQL 执行路径 → buffer cache 局部性 → OS 资源竞争 → 集群基础设施状态。漏掉任意一层，调参都像蒙眼贴图。
