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

学习动态性能表

第十一篇-(1)-V$LATCH  2007.6.7

 

　　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 poo         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  2007.6.6

 

　　数据库中有些类别的latches拥有多个。V$LATCH中提供了每一个类别的总计信息。若是想看到单个latch，你能够经过查询本视图。

 

例如：

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

 

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