怎么在Oracle 11g中利用AWR报告的Latch Statistics诊断争用-Oracle-PHP中文网

awr的latch statistics仅显示争用现象，不能定位根因；需结合v$latch_children查热点子latch地址，再通过v$active_session_history关联sql与等待上下文才能诊断真实原因。

怎么在oracle 11g中利用awr报告的latch statistics诊断争用

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 cache latch争用，还是热块导致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里正在等它的会话：

Market Oracle

金融事件影响分析器 — 获取突发新闻，追踪金属/石油/加密货币/股票价格，预测短中长期市场连锁反应

下载

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才能补全拼图。