学习动态性能表(11)--v$latch$v$latch_children

学习动态性能表(一)--v$sysstat
http://junsansi.itpub.net/post/29894/291051

学习动态性能表(二)--v$sesstat
http://junsansi.itpub.net/post/29894/291243

学习动态性能表(三)--v$sql&v$sql_plan
1.http://junsansi.itpub.net/post/29894/291651
2.http://junsansi.itpub.net/post/29894/291652

学习动态性能表(四)--v$sqltext&v$sqlarea
1.http://junsansi.itpub.net/post/29894/291654
2.http://junsansi.itpub.net/post/29894/291656

学习动态性能表(五)--v$session
http://junsansi.itpub.net/post/29894/292372

学习动态性能表(六)--v$session_wait&v$session_event
1.http://junsansi.itpub.net/post/29894/292373
2.http://junsansi.itpub.net/post/29894/292375

学习动态性能表(七)--v$process
http://junsansi.itpub.net/post/29894/292558

学习动态性能表(八)--v$lock&v$locked_object
1.http://junsansi.itpub.net/post/29894/292816
2.http://junsansi.itpub.net/post/29894/292819
3.http://junsansi.itpub.net/post/29894/292825

学习动态性能表(九)--V$FILESTAT
http://junsansi.itpub.net/post/29894/293209

学习动态性能表(十)--V$SESSION_LONGOPS
http://junsansi.itpub.net/post/29894/293212

学习动态性能表第十一篇-(1)-V$LATCH

　　Oracle Rdbms应用了各种不同类型的锁定机制，latch即是其中的一种。Latch是用于保护SGA区中共享数据结构的一种串行化锁定机制。Latch的实现是与操作系统相关的，尤其和一个进程是否需要等待一个latch、需要等待多长时间有关。Latch是一种能够极快地被获取和释放的锁，它通常用于保护描述buffer cache中block的数据结构。与每个latch相联系的还有一个清除过程，当持有latch的进程成为死进程时，该清除过程就会被调用。Latch还具有相关级别，用于防止死锁，一旦一个进程在某个级别上得到一个latch，它就不可能再获得等同或低于该级别的latch。

　　本视图保存自实例启动各类栓锁的统计信息。常用于当v$session_wait中发现栓锁竞争时鉴别SGA区中问题所在区域。

　　v$latch表的每一行包括了对不同类型latch的统计，每一列反映了不同类型的latch请求的活动情况。不同类型的latch请求之间的区别在于，当latch不可立即获得时，请求进程是否继续进行。按此分类，latch请求的类型可分为两类：willing-to-wait和immediate。

　　Willing-to-wait：是指如果所请求的latch不能立即得到，请求进程将等待一很短的时间后再次发出请求。进程一直重复此过程直到得到latch。
　　Immediate：是指如果所请求的latch不能立即得到，请求进程就不再等待，而是继续执行下去。

V$LATCH中的常用列：
NAME：latch名称
IMMEDIATE_GETS：以Immediate模式latch请求数
IMMEDIATE_MISSES：请求失败数
GETS：以Willing to wait请求模式latch的请求数
MISSES：初次尝试请求不成功次数
SPIN_GETS：第一次尝试失败，但在以后的轮次中成功
SLEEP[x]：成功获取前sleeping次数
WAIT_TIME：花费在等待latch的时间

V$LATCH中的连接列
Column View Joined Column(s)
--------------------- ------------------------------ ------------------------
NAME/LATCH# V$LATCH_CHILDREN NAME/LATCH#
NAME V$LATCHHOLDER NAME
NAME/LATCH# V$LATCHNAME NAME/LATCH#
NAME V$LATCH_MISSES PARENT_NAME

示例：下列的示例中，创建一个表存储查询自v$latch的数据：
CREATE TABLE snap_latch as SELECT 0 snap_id, sysdate snap_date, a.* FROM V$LATCH a;
ALTER TABLE snap_latch add (constraint snap_filestat primary key (snap_id, name));

最初，snap_id被置为0，稍后，snap_latch表的snap_id列被更新为1：
INSERT INTO snap_latch SELECT 1, sysdate, a.* FROM V$LATCH a;
注意你通过sql语句插入记录时必须增加snap_id的值。

在你连续插入记录之后，使用下列的select语句列出统计。注意0不能成为被除数。

SELECT SUBSTR(a.name,1,20) NAME, (a.gets-b.gets)/1000 "Gets(K)",
(a.gets-b.gets)/(86400*(a.snap_date-b.snap_date)) "Get/s",
DECODE ((a.gets-b.gets), 0, 0, (100*(a.misses-b.misses)/(a.gets-b.gets))) MISS,
DECODE ((a.misses-b.misses), 0, 0,
(100*(a.spin_gets-b.spin_gets)/(a.misses-b.misses))) SPIN,
(a.immediate_gets-b.immediate_gets)/1000 "Iget(K)",
(a.immediate_gets-b.immediate_gets)/ (86400*(a.snap_date-b.snap_date)) "IGet/s",
DECODE ((a.immediate_gets-b.immediate_gets), 0, 0,
(100*(a.immediate_misses-b.immediate_misses)/ (a.immediate_gets-b.immediate_gets)))

IMISS
FROM snap_latch a, snap_latch b
WHERE a.name = b.name
AND a.snap_id = b.snap_id + 1
AND ( (a.misses-b.misses) > 0.001*(a.gets-b.gets)
or (a.immediate_misses-b.immediate_misses) >
0.001*(a.immediate_gets-b.immediate_gets))
ORDER BY 2 DESC;

下例列出latch统计项，miss列小于0.1%的记录已经被过滤。
NAME Gets(K) Get/s MISS SPIN IGets(K) IGet/s IMISS
------------------ -------- ------- ----- ------ -------- ------- -----
cache buffers chai 255,272 69,938 0.4 99.9 3,902 1,069 0.0
library cache 229,405 62,851 9.1 96.9 51,653 14,151 3.7
shared pool 24,206 6,632 14.1 72.1 0 0 0.0
latch wait list 1,828 501 0.4 99.9 1,836 503 0.5
row cache objects 1,703 467 0.7 98.9 1,509 413 0.2
redo allocation 984 270 0.2 99.7 0 0 0.0
messages 116 32 0.2 100.0 0 0 0.0
cache buffers lru 91 25 0.3 99.0 7,214 1,976 0.3
modify parameter v 2 0 0.1 100.0 0 0 0.0
redo copy 0 0 92.3 99.3 1,460 400 0.0

什么时候需要检查latch统计呢？看下列项：

misses/gets的比率是多少
获自spinning的misses的百分比是多少
latch请求了多少次
latch休眠了多少次

　　Redo copy latch看起来有很高的的失误率，高达92.3%。不过，我们再仔细看的话，Redo copy latches是获自immediate模式。immediate模式的数值看起来还不错，并且immediate模式只有个别数大于willing to wait模式。所以Redo copy latch其实并不存在竞争。不过，看起来shared pool和library cache latches可能存在竞争。考虑执行一条查询检查latches的sleeps以确认是否确实存在问题。

latch有40余种，但作为DBA关心的主要应有以下几种：
Cache buffers chains latch：当用户进程搜索SGA寻找database cache buffers时需要使用此latch。
Cache buffers LRU chain latch：当用户进程要搜索buffer cache中包括所有 dirty blocks的LRU (least recently used) 链时使用该种latch。
Redo log buffer latch：这种latch控制redo log buffer中每条redo entries的空间分配。
Row cache objects latch：当用户进程访问缓存的数据字典数值时，将使用Row cache objects latch。

Latches调优

不要调整latches。如果你发现latch存在竞争，它可能是部分SGA资源使用反常的征兆。要修正问题所在，你更多的是去检查那部分SGA资源使用的竞争情况。仅仅从v$latch是无法定位问题所在的。

关于latches的更多信息可以浏览Oracle Database Concepts。

第十一篇-(2)-V$LATCH_CHILDREN

　　数据库中有些类别的latches拥有多个。V$LATCH中提供了每个类别的总计信息。如果想看到单个latch，你可以通过查询本视图。

例如：
select name,count(*) ct from v$Latch_children group by name order by ct desc;

与v$latch相比，除多child#列外，其余列与之同，不详述~~