AWR的Latch Statistics仅显示争用现象，不能定位根因；需结合v$latch_children查热点子latch地址，再通过v$active_session_history关联SQL与等待上下文才能诊断真实原因。
AWR里的Latch Statistics不能直接定位争用根因，它只告诉你“谁在抢”，不告诉你“为什么抢”或“抢什么”。真要诊断，得结合v$latch_children和v$active_session_history交叉验证。
为什么AWR的Latch Activity页只能当线索，不能当结论
AWR报告中“Latch Activity”部分列出的是所有latch类型的聚合统计，比如cache buffers chains、shared pool、library cache等。它只给两个关键数字：Pct Get Miss和Avg Slps/Miss。这两个值高，说明有争用，但无法回答：
- 是哪几个具体子latch在被高频争抢？（AWR不展示
CHILD#或ADDR） - 争抢发生在哪个SQL执行期间？（AWR里没有SQL与latch的关联字段）
- 是硬解析导致
library cachelatch争用，还是热块导致cache buffers chains争用？（AWR不提供上下文）
换句话说，AWR的Latch Statistics是个“报警器”，不是“诊断仪”。它提示你该往哪挖，但挖坑的铲子得自己拿。
从AWR出发，快速定位热点子latch的实操路径
拿到AWR报告后，若发现cache buffers chains的Pct Get Miss > 0.5% 或 Avg Slps/Miss > 1，立刻执行以下查询（需SYS权限）：
SELECT CHILD#, ADDR, GETS, MISSES, SLEEPS FROM v$latch_children WHERE name = 'cache buffers chains' AND MISSES > 0 ORDER BY SLEEPS DESC, MISSES DESC FETCH FIRST 5 ROWS ONLY;
这个结果里的ADDR就是真正被争抢的子latch地址。下一步用它去查ASH里正在等它的会话：
SELECT sql_id, event, p1, p2, p3, COUNT(*) FROM v$active_session_history WHERE event = 'latch: cache buffers chains' AND p1 = '&addr_from_above' GROUP BY sql_id, event, p1, p2, p3 ORDER BY COUNT(*) DESC;
注意：p1在latch: cache buffers chains等待中就是子latch地址，和上一步的ADDR可直接比对。
- 若返回多个
sql_id，说明不同SQL共用同一热块链 - 若只有一个
sql_id但COUNT(*)极高，说明该SQL反复访问同一块（如主键更新、序列取值） - 若
p2值高度离散，说明争用分散在多个不同块上，可能是全表扫描+高并发
library cache latch争用：别急着调shared_pool_size
如果AWR里library cache latch的Pct Get Miss异常，常见误区是立刻加shared_pool_size。实际上更大概率是应用层问题：
- 大量硬解析：检查
Load Profile里的Hard Parses (s)是否 > 20/s；再查v$sqlarea中executions低但parse_calls高的SQL - SQL文本不一致：ORM生成SQL时带随机空格、换行或注释，触发
TRANSLATION_MISMATCH，查v$sql_shared_cursor确认 - 绑定变量未显式指定长度：JDBC用
setString(1, "abc")没配setCharacterStream或长度，Oracle推断出不同VARCHAR2长度，强制新子游标
此时v$sqlarea.version_count > 10 + v$sql_shared_cursor.BIND_MISMATCH = 'Y'才是真实证据链，AWR里看不到这些。
容易被忽略的关键点
Oracle 11g中，v$latch_children的GETS统计包含“愿意等待”和“无等待”两种请求，而AWR的Pct Get Miss只基于前者计算。这意味着：如果应用大量使用NO WAIT方式获取latch（比如某些PL/SQL包），AWR会低估实际争用强度。必须看v$latch_children原始视图里的IMMEDIATE_GETS和IMMEDIATE_MISSES才能补全拼图。
