看AWR报告需生成按实例拆分的报告（用awrrpti.sql或OEM勾选Per Instance），再比对各节点DB CPU/ CPU Count比率，并结合ASH、GV$SQL、GV$BH等定位RAC节点CPU高根源。
怎么看AWR报告里哪个节点CPU高？
直接看 top 5 timed foreground events 和 instance activity stats 两个部分，但关键在交叉比对：同一时段下，db time 和 db cpu 指标要按节点（inst id）分开看。默认awr报告是汇总的，必须生成「按实例拆分」的报告——用 awrrpti.sql（不是 awrrpt.sql）并输入两个实例id，或在oem中选「compare periods」并勾选「per instance」。
常见错误是只看总DB CPU，结果发现RAC里节点1占70%、节点2占30%，却没注意节点1的物理CPU核数其实是节点2的两倍。所以得算 DB CPU / CPU Count 的比率，才反映真实饱和度。
- 查每个节点CPU核数：
SELECT value FROM gv$parameter WHERE name = 'cpu_count' AND inst_id = 1 - 查某时段各节点DB CPU（秒）：
SELECT inst_id, round(value/1000000, 2) cpu_sec FROM gv$sysmetric_history WHERE metric_name = 'DB CPU' AND begin_time > SYSDATE-1/24 - AWR快照间隔太长（比如1小时）会掩盖短时尖峰，建议生产环境设为15–30分钟
如何确认是不是某个SQL拖垮了特定节点？
不能只依赖 SQL ordered by CPU Time 汇总页——它把所有节点的执行堆在一起。必须进 SQL Statistics → SQL ordered by Elapsed Time 的子页面，点开每条SQL的「Instance Detail」链接，才能看到该SQL在各节点上的执行次数、CPU时间、逻辑读分布。
特别注意 px qc instance 和 px server instance 的区别：如果一条并行SQL的QC（Query Coordinator）总在节点1，而PX Server大量跑在节点2，但节点1 CPU飙升，问题很可能出在QC端的串行处理（比如大排序、PL/SQL逻辑），而不是并行本身。
- 查某SQL在各节点执行分布：
SELECT inst_id, executions, cpu_time/1000000 cpu_sec, buffer_gets FROM gv$sql WHERE sql_id = 'abc123xyz' ORDER BY inst_id - 检查是否绑定到特定节点：看
gv$session中inst_id和service_name是否存在强关联，某些应用用TNS alias硬编码了INSTANCE_NAME - 留意
LOAD_PROFILE里的Logons per Second，若某节点登录数突增，可能是连接池未启用负载均衡（如未配LOAD_BALANCE=on）
RAC特有的等待事件怎么快速识别瓶颈？
gc buffer busy acquire、gc cr block busy、enq: TX - row lock contention 这些不是单实例的IO或锁问题，而是跨节点数据块争用。它们出现在 Top 5 Timed Foreground Events 里时，说明节点间通信或缓存一致性成了瓶颈，不是CPU或磁盘慢。
重点看 Global Cache and Enqueue Services 部分的统计：如果 gc cr blocks received 远高于 gc current blocks received，说明大量查询需要从其他节点拉CR（Consistent Read）块，可能因为本地buffer cache太小，或SQL重复扫描同一张表但未分区；如果 gc current block busy 高，更可能是DML热点块（如序列主键插入、状态字段频繁更新）集中在某节点。
- 查热点块所在节点：
SELECT inst_id, file#, block# FROM gv$bh WHERE class# = 1 AND status = 'xcur' GROUP BY inst_id, file#, block# HAVING COUNT(*) > 100 - 对比两节点的
gc cr block receive time平均值，差3倍以上说明网络延迟或私网配置异常（如MTU不一致、未禁用TCP timestamp） -
enq: HW - contention出现多，往往是因为没有开启ASSM自动段管理，或高并发INSERT未用分区+序列打散
为什么用ASH数据比AWR更快定位瞬时问题？
AWR是聚合快照，最小粒度15分钟；ASH是内存采样（每秒1次），能抓到持续几十秒的毛刺。当用户说「刚才卡了20秒就恢复了」，AWR很可能根本没录到——这时候必须用 dba_hist_active_sess_history 或实时 v$active_session_history。
关键技巧是加 inst_id 和 sample_time 过滤，并用 session_state + event 组合判断：比如连续5个采样点都是 ON CPU，且 sql_id 相同，基本锁定该SQL；如果交替出现 WAITING 和 ON CPU，且 event 是 gc cr block busy，说明是RAC缓存同步卡住CPU线程。
- 查过去10分钟某节点CPU尖峰：
SELECT sample_time, sql_id, event, session_state FROM v$active_session_history WHERE inst_id = 1 AND sample_time > SYSDATE - 10/1440 AND session_state = 'ON CPU' ORDER BY sample_time - ASH默认只保留1小时（内存限制），长期问题需配合
DBA_HIST_ACTIVE_SESS_HISTORY，但要注意它每10秒采一次，精度下降 - 别忽略
blocking_session和blocking_inst_id字段——RAC里阻塞者和被阻塞者可能在不同节点，这是单实例ASH里看不到的关键链路
实际排查中最容易被跳过的，是私网质量验证和实例参数一致性。哪怕AWR/ASH都指向节点1，也得先确认 oifcfg getif 输出的集群私网接口是否真走的是专用千兆/万兆网卡，以及 gv$parameter 里 db_cache_size、shared_pool_size 在两个节点上是否完全相同——参数不一致会导致同样SQL在不同节点走不同执行计划，进而引发负载倾斜。
