必须结合p3（class#）定位争用类型：p3=1为数据块、p3=4为段头、p3=17/18为undo相关、p3=130/220多见于老版本，误判p3将导致优化方向完全错误。
Buffer Busy Waits 高，不能只盯着等待次数或平均等待时间——必须结合 class#（P3参数）定位争用类型，否则优化方向完全可能跑偏。
怎么看 class# 对应的真实争用位置
AWR 报告里 Top 5 Timed Events 只显示 buffer busy waits 总等待，但真正关键的是它的第三个参数 class#。这个值直接决定你该查索引、查段头，还是查 UNDO 块。
- 查当前活跃会话的实时
class#：SELECT event, p1 AS file#, p2 AS block#, p3 AS class# FROM v$session_wait WHERE event = 'buffer busy waits';
- 查历史 AWR 中的分布（需有
dba_hist_active_sess_history）：SELECT p3 AS class#, COUNT(*) cnt FROM dba_hist_active_sess_history WHERE event = 'buffer busy waits' AND snap_id BETWEEN &start_snap AND &end_snap GROUP BY p3 ORDER BY cnt DESC;
- 对照标准值快速判断：
1是 data block（普通表/索引块），4是 segment header（段头），17和18是 UNDO 相关，130和220是老版本归类，现在更推荐用V$WAITSTAT的class列比对
Segments by Buffer Busy Waits 里哪些对象真要优先处理
AWR 的 “Segments by Buffer Busy Waits” 表格列出的是累计等待次数最多的段，但**次数多 ≠ 问题核心**——得看访问模式和对象类型。
- 如果高排位是小配置表（比如
sys_config）的主键索引叶块：大概率是reverse key index或hash partition能解，不是加 buffer cache 就能压下去的 - 如果是大事务表的
SEGMENT HEADER（类型为TABLE或INDEX，且class# = 4）：说明 FREELIST 管理压力大，优先考虑迁到 ASSM 表空间，而不是调大initrans - 如果高排位对象是
UNDO$或UNDOTBS1：说明 UNDO 段头或回滚块争用严重，此时查V$UNDOSTAT的UNXPSTEALCNT和SSOLDERRCNT比看 AWR 更直接
为什么 V$WAITSTAT 的 class 统计比 AWR 更准
V$WAITSTAT 记录的是每个缓冲区类别的累计等待次数，它不依赖采样周期，也不受 ASH 采样频率影响，对瞬时热块问题更敏感。
- 执行：
SELECT class, count, time FROM v$waitstat WHERE count > 0 ORDER BY count DESC;
- 重点盯：
data block（对应class# = 1）、segment header（class# = 4）、undo header（class# = 17）、undo block（class# = 18） - 注意陷阱：
V$WAITSTAT不重置，重启实例才清零；所以对比必须在同一实例生命周期内做趋势分析，不能跨天直接比绝对值
容易被忽略的关联信号
单独看 buffer busy waits 容易误判，必须同步检查几个“配套指标”：
- 如果
buffer busy waits高的同时latch: cache buffers chains也高：说明 hash chain 过长或热点块 PIN 时间太长，不是对象设计问题，而是 latch 争用已成瓶颈 - 如果
db file sequential read平均延迟突然升高（比如从 8ms → 25ms），而buffer busy waits也同步上涨：很可能是磁盘 IO 响应变慢导致块加载慢，其他会话在等它进缓存，本质是 IO 层问题 - 如果
enq: TX - row lock和buffer busy waits同时高，且class# = 220：说明是并发 DML 修改同一块内不同行，这时查V$SEGMENT_STATISTICS的logical reads和physical reads比查 SQL 更快定位热块
真实场景里，class# 的解读偏差一档，后续所有优化动作就全在打偏靶——比如把 class# = 18（UNDO 块）当成数据块去加 freelist，只会让问题更隐蔽。
