ASH是定位Oracle 11g中latch: cache buffers chains争用最实用手段，需结合P1RAW、CURRENT_OBJ#、SQL_ID与x$bh交叉验证；因v$session_wait仅捕获瞬时状态，而ASH每秒采样、保留1小时历史，可统计高频争用分布，并通过P1RAW→x$bh.TCH→dba_extents精准定位热点块及对象。
直接结论：ASH（v$active_session_history）是定位 Oracle 11g 中 latch: cache buffers chains 争用源头最实用的手段，但必须结合 P1RAW、CURRENT_OBJ#、SQL_ID 和 x$bh 交叉验证，否则容易误判热点对象。
为什么 v$active_session_history 比 v$session_wait 更可靠
在 11g 中，v$session_wait 只反映“当前瞬间”的等待，而 latch: cache buffers chains 争用往往是瞬时、高频、多会话轮番触发的——单次采样极可能错过。ASH 每秒采样一次（默认），保留最近 1 小时（受 _ash_size 和内存限制），能捕获争用的统计分布。
关键点：
-
EVENT列值为latch: cache buffers chains的记录，P1RAW字段是该次等待所请求的 CBC latch 地址（16 进制字符串） -
CURRENT_OBJ#在部分场景下为空（如访问 undo 块、数据字典块），不能单独依赖它定位对象 -
SQL_ID即使存在，也仅表示“当时正在执行的 SQL”，不等于“真正引发争用的 SQL”（例如嵌套循环中驱动表小、被驱动表热块）
如何从 ASH 找出真实热点块和对象
核心思路：ASH 提供 latch 地址 → x$bh 匹配高 TCH 块 → dba_extents 定位物理对象。
分步操作：
- 先查争用最集中的 latch 地址：
SELECT P1RAW, COUNT(*) cnt FROM v$active_session_history<br>WHERE EVENT = 'latch: cache buffers chains'<br>AND SAMPLE_TIME > SYSDATE - 1/24<br>GROUP BY P1RAW ORDER BY cnt DESC FETCH FIRST 5 ROWS ONLY;
- 对每个高频
P1RAW（如'000000038F1A2C98'），查对应 hash chain 上 TCH 最高的块：SELECT FILE#, DBABLK, TCH, OBJ, HLADDR FROM x$bh<br>WHERE HLADDR = '000000038F1A2C98'<br>ORDER BY TCH DESC FETCH FIRST 5 ROWS ONLY;
- 用
FILE#和DBABLK查对象：SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE<br>FROM dba_extents<br>WHERE FILE_ID = &file_num<br>AND &block_num BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1;
常见误判陷阱与绕过方法
以下情况会导致 ASH 分析结果失真：
-
CURRENT_OBJ#显示为-1或空：说明访问的是系统块（如 undo header、segment header、data dictionary root block），此时必须依赖x$bh.HLADDR+TCH，不能查dba_objects - 多个不同
SQL_ID出现在同一P1RAW下：说明是“热链（hot chain）”而非“热块（hot block）”，争用源于哈希桶过少（_db_block_hash_buckets太小），不是 SQL 问题 -
SQL_ID对应的执行计划里没有该对象：可能是递归调用（如触发器、约束检查、物化视图刷新），需查v$sql_plan中OBJECT_OWNER/OBJECT_NAME是否匹配x$bh.OBJ
11g 特定限制：AWR 快照里不存 P1RAW，只能靠 ASH
Oracle 11g 的 AWR 报告（dba_hist_active_sess_history）中，P1RAW 列被截断为 0（或不可用），因此无法用历史 AWR 分析 latch 地址。这意味着：
- 故障已过、未开启 ASH 保留扩展（如未设置
_ash_disk_filter_ratio），就基本无法回溯 - 生产环境建议确保
v$active_session_history至少保留 30 分钟以上（默认通常够），且不要禁用STATISTICS_LEVEL = TYPICAL - 若需长期归档，可定时把高频
P1RAW+x$bh结果导出到自定义表，而不是依赖 AWR
真正难的不是查出哪个块被争用，而是判断这个块为什么被争用——是索引根块？唯一索引叶块？还是某个小表被全表扫描又反复 join？这需要把 ASH 得到的块号，再反向映射回业务 SQL 的访问路径，而不是只盯着对象名。
