oracle rac监控高负载节点需生成按实例拆分的awr报告，分别查看各节点db cpu与cpu核数比值、sql在各节点执行分布及绑定情况，并结合ash下钻秒级分析。
awr报告里哪些指标直接暴露cpu瓶颈
oracle的cpu压力不会只体现在db cpu这一项上，得交叉看。如果db cpu占比长期超过70%，同时sql*net message from client等待偏低、latch: shared pool或latch: library cache等待突增，基本可判定是硬解析过多引发的cpu争用。
实操建议：
- 在AWR报告的「Top 5 Timed Foreground Events」中重点盯
DB CPU和latch free的排序位置与等待时间（单位：cs，即厘秒） - 对比「SQL Statistics」→「CPU per Exec」列，找出单次执行耗CPU异常高的SQL；注意排除
EXECUTIONS为0但CPU_TIME_SEC非零的伪高负载SQL（常因统计未刷新） - 检查「Instance Activity Stats」里的
parse count (hard)是否远高于parse count (total)的10%——超过说明绑定变量使用严重不足
IO瓶颈不能只看“db file sequential read”
看到db file sequential read排在Top 5，并不等于磁盘慢。它更可能是索引扫描过深、表连接方式不当，或Buffer Cache命中率不足的间接表现。
实操建议：
- 先查「Instance Efficiency Percentages」中的
Buffer Nowait %（应>99）和Buffer Hit %（应>95）；若二者都低，优先调大db_cache_size而非换存储 - 在「I/O Profile」部分看
Av Reads per sec和Av Rd(ms)：若读次数高但平均响应毫秒值稳定在5–10ms，问题在逻辑IO路径，不是物理IO设备 - 结合「SQL Statistics」→「Physical Reads Per Exec」找单次执行读块数超10000的SQL，再用
DBMS_XPLAN.DISPLAY_AWR查其执行计划，确认是否走了全表扫描却缺索引
如何快速定位AWR报告中隐藏的锁与并发问题
锁等待往往被淹没在大量空闲事件里，enq: TX - row lock contention或enq: TM - contention可能只排第8–12位，但持续存在就足以拖垮业务。
实操建议：
- 在「Wait Events」部分手动搜索关键词
enq:和latch:，不要只依赖Top 5；尤其关注等待时间总和占DB Time比例＞1%的锁类事件 - 查看「Segment Statistics」→「Logical Reads」和「Physical Reads」排名靠前的表，再核对这些对象是否被频繁DML且缺乏合适索引（例如无主键/无唯一约束的大表update）
- 运行
SELECT * FROM DBA_HIST_ACTIVE_SESS_HISTORY WHERE EVENT LIKE 'enq:%' AND SAMPLE_TIME > SYSDATE-1/24;反查最近1小时活跃会话，比AWR汇总数据更及时
生成AWR报告时最容易忽略的三个参数
用awrrpt.sql或DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_TEXT生成报告时，错配快照ID或数据库ID，会导致分析对象完全错位。
实操建议：
- 务必确认
dbid：执行SELECT dbid FROM v$database;，别直接抄v$database.name——RAC环境多个实例共用一个name但dbid不同 - 快照范围要跨足够时间：至少覆盖一个完整业务高峰周期（如早9点–10点），避免选到两个快照都在低谷期，导致所有指标看起来“正常”
- 若分析RAC，必须指定
inst_num参数；否则默认只取instance 1，而真实瓶颈可能在instance 3上，报告里根本不会出现
AWR不是万能诊断仪，它的粒度是分钟级快照，抓不到亚秒级毛刺；真正卡顿发生在某条SQL执行中途时，得配合ASH（DBA_HIST_ACTIVE_SESS_HISTORY）下钻到秒级才看得清。别把AWR当唯一依据，尤其当用户反馈“偶尔卡一下”，那大概率不在AWR里。
