latch free等待本身不是问题而是信号，需定位具体子事件；优先查AWR中Latch Activity表的% Get Miss（>5%需介入）、Avg Slps/Miss（>2表重争用），重点关注latch: cache buffers chains等带冒号的子事件。
latch free 等待本身不是问题，而是信号——它告诉你：有进程在争抢某个内存保护结构（latch），但没抢到。直接盯着 latch free 总等待时间或次数看，90% 会误判。真正要动手的，是定位背后那个具体的 latch 子事件。
怎么看AWR里真正的热点latch？
别只扫 Top 5 Timed Events 里的 latch free 行。它只是个“总称”，就像报警器响了，但你得去查是哪个房间冒烟。
- 优先翻到 AWR 报告末尾的「Latch Activity」表格，按
% Get Miss降序排——>5% 就值得介入，>10% 基本确认争用严重 - 再看
Avg Slps/Miss：>2 表示进程不是自旋重试，而是主动休眠，说明竞争已进入较重阶段 - 重点关注带冒号的子事件名，比如
latch: cache buffers chains、latch: library cache、latch: shared pool，这些才是真凶线索 - 如果
latch free排名高，但所有子事件都没上榜，说明争用分散——这时要查v$latch的sleeps列，找非零值最多的 latch
cache buffers chains 高了，一定是热块吗？
不一定。大量案例显示，加索引后 latch: cache buffers chains 反而更忙，根源常是执行计划退化，导致逻辑读暴增、反复扫描同一组 buffer chain。
- 先查 AWR 「SQL Statistics」→「Buffer Gets per Exec」，找出逻辑读/执行比异常高的 SQL
- 对这些 SQL 跑
DBMS_XPLAN.DISPLAY_CURSOR，看是否走了全表扫描、索引全扫描，或访问路径突然变宽 - 用
DBMS_UTILITY.DATA_BLOCK_ADDRESS_FILE和DBMS_UTILITY.DATA_BLOCK_ADDRESS_BLOCK解析 ASH 中的 P1，定位具体热 block；但别急着加索引——先确认是不是 SQL 本身写法或统计信息偏差导致 - 注意：CBC 的
% Get Miss正常阈值极低（
library cache 或 shared pool latch 高，大概率是硬解析问题
这两个 latch 争用，80% 以上指向 SQL 复用不足。不是共享池大小不够，而是语句没绑定变量，或者频繁 DDL 导致对象版本爆炸。
- 查 AWR 的「Parse Statistics」：如果
parse count (hard)/parse count (total)>10%，基本可断定硬解析风暴 - 查
v$sql中sql_text相似但address不同的语句（如 WHERE 条件拼接数字字面量），就是未绑定变量的典型痕迹 -
shared poollatch 高还可能伴随ORA-04031，此时要查v$sgastat的 free memory 是否持续低于 100MB - Oracle 12c+ 还要警惕自动动态采样（ADS）触发 result cache，即使设了
RESULT_CACHE_MODE = MANUAL，也可能因_optimizer_ads_use_result_cache = TRUE导致Result Cache: RC Latch争用
别忽略平台和隐含参数带来的假性争用
某些 latch 在特定平台表现异常，不是业务问题，而是 Oracle 底层适配缺陷。
- HPUX 上出现
cas latch（latch# = 163），本质是 Compare-and-Swap 指令不被 OS 支持，关掉db_cache_advice即可缓解 - 12.1+ 版本中
latch: Result Cache: RC Latch高企，大概率是自动动态采样强行启用 result cache，需设_optimizer_ads_use_result_cache = FALSE - 查
v$session_wait的 P2 值，用SELECT name FROM v$latchname WHERE latch# = &P2确认 latch 名称——别靠记忆猜，不同版本 latch# 映射可能变化
真正难的不是发现 latch free，而是判断它是症状还是病因。一个 latch: cache buffers chains 等待背后，可能是 SQL 走错执行路径，也可能是 buffer cache 太小，还可能是底层存储延迟升高导致单次 buffer 访问变慢——必须结合逻辑读、物理读、CPU 使用率、ASH 样本分布一起看，漏掉任意一环，优化就容易打偏。
