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

  • 相关阅读:
    【转+补充】在OpenCV for Android 2.4.5中使用SURF(nonfree module)
    Delphi StarOffice Framework Beta 1.0 发布
    Angular ngIf相关问题
    angularjs文档下载
    公众号微信支付开发
    公众号第三方平台开发 教程六 代公众号使用JS SDK说明
    公众号第三方平台开发 教程五 代公众号处理消息和事件
    公众号第三方平台开发 教程四 代公众号发起网页授权说明
    公众号第三方平台开发 教程三 微信公众号授权第三方平台
    公众号第三方平台开发 教程二 component_verify_ticket和accessToken的获取
  • 原文地址:https://www.cnblogs.com/mq0036/p/4334880.html
Copyright © 2020-2023  润新知