• 学习动态性能表(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#列外,其余列与之同,不详述~~

  • 相关阅读:
    常见面试题
    3*0.1 == 0.3 将会返回什么?true 还是 false?
    poj_2186 强连通分支
    强连通分量、割点、桥
    最小生成树
    poj_2349 Kruskal 最小生成树
    poj_1258 prim最小生成树
    最短路径
    poj_1125 Floyd最短路
    poj_1860 SPFA
  • 原文地址:https://www.cnblogs.com/mq0036/p/4334880.html
Copyright © 2020-2023  润新知