必须查session_state而非仅看event，因on cpu和waiting状态才决定瓶颈类型；ash中event仅示等待内容，session_state才是cpu或等待瓶颈的判定依据。
查 SESSION_STATE 而不是只看 event
ASH里一条记录的 event 字段只告诉你“当前在等什么”，但真正决定是CPU瓶颈还是等待瓶颈的，是 session_state。它只有两个有效值：ON CPU 和 WAITING。别被 db file sequential read 这类高占比 event 带偏——如果它对应的是大量 WAITING 样本，才是真I/O瓶颈；如果同一条SQL下 ON CPU 样本数远超 WAITING，那问题在计算逻辑或解析开销，和磁盘无关。
实操建议：
- 必须加
WHERE session_state IN ('ON CPU', 'WAITING')，否则统计失真 - 同一
sql_id下，ON CPU样本占比 >60% → 优先查执行计划、绑定变量、硬解析 -
WAITING样本中event集中在db file sequential read或direct path read→ 结合p1/p2看是否局部文件热点 - 避免把
SQL*Net message from client归为I/O类——它是网络响应等待，应归入客户端链路问题
用 time_waited 区分“真等待”和“假等待”
time_waited 字段单位是微秒，但它只对 WAITING 状态有效，ON CPU 的记录里这个值为0或NULL。很多人直接对所有样本求 AVG(time_waited)，结果被大量短等待（比如几微秒的 cursor: pin S）拉低均值，掩盖了真正拖慢系统的长等待。
实操建议：
- 过滤时加
AND time_waited > 10000（即 >10ms），排除噪声 - 重点看
MAX(time_waited)：单次等待超 500ms 基本可判定为异常，比如enq: TX - row lock contention出现 2s 等待，说明锁已卡死 - 对
ON CPU样本，不要看time_waited，改看样本数密度——1分钟内某sql_id占据 300+ 条ON CPU记录，就是实打实的CPU燃烧 - RAC环境下必须用
gv$active_session_history，否则time_waited只反映本节点，看不出跨节点倾斜
识别伪装成等待的CPU消耗
有些等待事件本质是CPU密集型操作的副产品，比如 latch: cache buffers chains 或 cursor: pin S wait on X。它们看起来是 latch 等待，但根源常是高频逻辑读引发的 CPU 争抢，而非 latch 本身配置不足。
实操建议：
- 查到高频
latch: cache buffers chains时，先关联current_obj#和p1（file#），确认是不是某个热对象（如索引根块）被反复访问 - 若该对象
buffer_gets极高但disk_reads极低，且ON CPU样本同步飙升 → 是CPU在处理缓存访问逻辑，不是I/O慢 -
cursor: pin S wait on X大量出现，配合in_hard_parse = 'Y'→ 根本问题是硬解析风暴，得从应用端绑定变量入手，不是调大shared_pool_size - 别依赖AWR报告里的“Top Events”排序——它按总等待时间算，会把大量短等待累加后压过单次长CPU燃烧，ASH按样本数统计才更贴近真实压力分布
为什么 RAC 下容易误判瓶颈类型
RAC节点间数据块传输（global cache cr/current block receive）会产生 gc cr block busy 或 gc current block 2-way 等等待事件。这些事件名义上是“等待”，但背后可能是远程节点CPU满载导致响应延迟，也可能是私网带宽打满，还可能是本地节点在反复重试获取block——三者对策完全不同。
实操建议：
- 查
gv$active_session_history时必须带上inst_id，对比同一sql_id在不同节点的ON CPU样本分布 - 若节点1的
gc cr block busy等待集中在节点2返回的block上，且节点2此时ON CPU样本暴增 → 是节点2 CPU瓶颈拖慢GC响应 - 若所有节点都出现大量
gc buffer busy，且time_waited普遍 >100ms，同时私网流量监控显示饱和 → 是interconnect带宽不足，不是数据库参数问题 - 用
SELECT * FROM gv$sysstat WHERE name LIKE '%gcs%'看全局缓存统计，比单纯看ASH事件更早发现GC压力拐点
实际排查时，最易被跳过的动作是：没确认 statistics_level 是否为 TYPICAL 或 ALL，BASIC 会导致 ASH 完全不采样；也没检查实例是否刚重启——v$active_session_history 是内存视图，重启即清空，历史只能靠 dba_hist_active_sess_history，但它的采样粒度是10秒，对瞬时抖动几乎无感。
