latch free 三板斧

性能诊断，随迟但到的一个问题

要依据latch类型进行诊断，通常是在sql未绑定变量，热块上出现

先抡几下

--正在等什么latch
SELECT name, 'Child '||child#, gets, misses, sleeps
    FROM v$latch_children
   WHERE addr='&P1RAW'
  UNION
  SELECT name, null, gets, misses, sleeps
    FROM v$latch
   WHERE addr='&P1RAW';

--这个似乎更简单
SELECT * FROM v$latchname
   WHERE latch# = &P2;

--整体情况
select * from (
SELECT latch#, name, gets, misses, sleeps
    FROM v$latch
   WHERE sleeps>0
   ORDER BY sleeps desc) where rownum<11;

-- 确定闩锁活动是否集中在集合中的一个特定闩锁上
SELECT addr, latch#, gets, misses, sleeps
    FROM v$latch_children
   WHERE sleeps>0
     and latch# = &LATCH_NUMBER_WANTED
   ORDER BY sleeps;
如果有多行，需要注意的重要一点是 SLEEPS 是否合理分布，或者是否有一个或两个子闩锁负责 80% 的 SLEEPS。如果争用集中在一个或两个子锁上，请记下子latch看到了问题 - 请注意 ADDR 列

还可以查询
V$LATCH_HOLDER --是否一直出现相同的会话
v$session_event

awr里看latch 的统计结果


关于此等待事件的专业讲解：
某些会话正在等待闩锁释放等待但无法获得闩锁。闩锁释放等待保护共享池中的缓冲区缓存或库缓存等内存结构。它们被设计为在很短的时间内举行。如果闩锁不可用，会话将进入睡眠状态并稍后重试该操作。等待闩锁可能很昂贵，因为在等待闩锁时会话可能会在 CPU 上旋转。

Shared Pool Latch
共享池闩锁的争用是由于共享池容量不足、SQL 未共享或大量使用数据字典。确保共享池对于应用程序负载足够大，并且尽可能共享 SQL 语句

Library Cache Latch
库缓存锁存器的争用可能与共享池锁存器的争用有关，因为库缓存位于共享池内。库缓存闩锁争用通常是由于高解析或共享池过小。如果原因是过度的硬解析，那么您需要查看为什么游标被解析得如此之多。由于 Oracle 尝试重用以前解析的应用程序代码，因此假设它是可共享的，则不需要重新解析它。如果库缓存中没有 sql 的已解析表示，则 Oracle 将需要对 sql 进行硬解析

Cache buffers chains
该锁存器用于保护缓冲区缓存中的缓冲区列表。首先固定的进程将获得一个锁存器，因此其他进程不会更改数据。一旦块被取消固定，第二个用户就可以使用它，依此类推。多个会话可能需要同一个块，从而导致争用。
看一看awr中SQL ordered by Gets中的sql、Segments by Logical Reads中对象