AWR中latch free是泛型等待事件，真实含义是进程获取latch失败后自旋或休眠，并非直接等同锁争用严重；需结合Latch Activity表的% Get Miss（>5%确认争用）、Avg Slps/Miss（>2表重争用）及具体子事件（如latch: cache buffers chains）定位根因。
看懂 AWR 里 latch free 的真实含义
awr 报告中出现 latch free 等待，并不等于“锁争用严重”，它只是说明有进程在尝试获取某个 latch 时失败了，被迫等待或自旋。关键要看是哪个 latch、在什么上下文、持续多久。
常见误区是直接盯 v$system_event 里 latch free 的总等待时间（比如 65549 cs），但这个数字本身没意义——它可能是几十个不同 latch 的等待叠加，也可能是单个 latch 上千次低开销自旋的结果。
-
latch free是泛型事件，真正要定位的是具体子事件，比如latch: cache buffers chains、latch: library cache、latch: shared pool - 在 AWR 的「Top 5 Timed Foreground Events」里，优先找带冒号的 latch 子事件，而不是只看
latch free - 若子事件未上榜，但
latch free排名靠前，说明争用分散——这时应查「Latch Activity」部分，看哪些 latch 的SLEEPS或SPIN_GETS/GETS比例异常高
从 AWR 的 Latch Activity 表定位热点 latch
「Instance Efficiency Percentages」下面的「Latch Activity」表才是分析起点，它按 latch name 分组统计了获取行为。重点关注三列：Get Requests（总请求）、% Get Miss（未命中率）、Avg Slps/Miss（平均休眠次数）。
-
% Get Miss> 1% 就值得怀疑；> 5% 基本确认存在争用压力 -
Avg Slps/Miss> 2 表示未命中后不是立刻重试，而是休眠再抢，已进入较重争用状态 - 特别注意
cache buffers chains：它的GETS通常远高于其他 latch，但只要% Get Miss低于 0.1%，就属正常；一旦跳到 0.5% 以上，就要结合逻辑读和执行计划排查 - 若
library cache或shared pool的% Get Miss明显升高，且 AWR 中parse count (hard)占parse count (total)超过 10%，基本可断定是绑定变量缺失导致硬解析风暴
区分 CBC latch 争用是真热块还是执行计划恶化
latch: cache buffers chains 高企时，不能直接下结论说“某张表被疯狂访问”。大量案例显示，加索引后 CBC 反而更忙，根源其实是执行路径变差。
- 先查 AWR 的「SQL Statistics」→「Buffer Gets per Exec」，找出逻辑读/执行比异常高的 SQL；这些语句大概率在反复扫描同一组 block
- 用
DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE和DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK解析v$active_session_history中的P1，再查DBA_EXTENTS确认对象——很多所谓“热块”其实是OBJ$、IND$这类字典表，说明是 row cache latch 误报 - 如果反查结果是业务表的索引叶块，再检查该字段的选择性：低基数字段建索引 + 大量
INDEX RANGE SCAN+ 回表，会导致所有会话集中在堆表头部几个 block，表现为 CBC latch 争用，但本质是执行计划低效 - 验证方式：临时禁用该索引（
ALTER INDEX xxx INVISIBLE），观察 AWR 中 CBC 等待是否下降、逻辑读是否转移至全表扫描——若下降明显，就是索引引发的伪热点
Result Cache 引起的 latch free 容易被忽略
Oracle 11g+ 默认启用 result_cache，它把 SQL 结果集缓存在 Shared Pool 中，但其 latch 机制（result cache latch）在 AWR 中不会单独列为子事件，而是归入 latch free 总计，容易被当成“杂项等待”忽略。
- 检查参数：
SHOW PARAMETER result_cache_max_size；若非零，且 AWR 中latch free时间突增、同时DB CPU并不高，就要怀疑它 - 确认方式：查
v$latch，找 name =result cache的行，看MISSES和SLEEPS是否显著上升 - 临时关闭：执行
ALTER SYSTEM SET result_cache_max_size = 0 SCOPE=BOTH，再跑一轮业务对比 AWR；注意这会影响依赖结果缓存的报表类应用 - 不建议盲目加大
result_cache_max_size，因为过大会挤占 Shared Pool，反而加剧library cachelatch 争用
Latch 争用从来不是孤立现象——它要么暴露 SQL 写法缺陷（如硬解析、低效索引），要么反映内存结构配置失衡（如 _db_block_hash_buckets 过小），要么是新特性（如 Result Cache）与现有负载不兼容。AWR 报告里每一行 latch 统计背后，都连着具体的执行路径或内存访问模式，跳过 P1 解析、绕开对象反查、只盯总等待时间，诊断就只剩猜测。
