注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

常在心

淡泊明志,人生自在

 
 
 

日志

 
 

动态性能视图-v$latch  

2011-03-28 14:01:53|  分类: 常用动态性能视图 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

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


 

  评论这张
 
阅读(130)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017