关于latch: cache buffe…

来源：互联网发布：淘宝联盟推广没有图片编辑：程序博客网时间：2024/06/05 05:11

转自：http://czmmiao.iteye.com/blog/1766442

latch: cache buffers chains故障处理总结(原创)

一大早就接到开发商的电话，说数据库的CPU使用率为100%，应用相应迟缓。急匆匆的赶到现场发现进行了基本的检查后发现是latch:cache buffers chains作祟，处理过程还算顺利，当时忘了记录log，这里总结下处理思路，以便下次查看。

故障分析思路:

查看等待事件，判断故障起因

SQL>select * from(select sid,event,p1,p2,p3,p1text,WAIT_TIME,SECONDS_IN_WAIT fromv$session_wait where wait_class# <> 6
order by wait_time desc) where rownum <=10;

确认为latch: cache bufferschains引起的故障后，查看latch的命中率

SQL>SELECT name,gets, misses, sleeps,
     immediate_gets, immediate_misses
    FROM v$latch
   WHERE name = 'cache bufferschains';

各列名称意义如下

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

这里需要注意MISSES/GETS如果在达10%左右，则说明有比较严重的latch争用,也可以通过查询v$latch_children视图查看其他latch信息，语句如下

SQL> SELECT *
    FROM(SELECT   addr, child#, gets,misses, sleeps, immediate_gets igets,
                 immediate_misses imiss, spin_gets sgets
             FROM v$latch_children
            WHERE NAME = 'cache buffers chains'
         ORDER BY sleeps DESC)
   WHERE ROWNUM <11;

关于latch的统计信息，主要关注以下几部分

misses/gets的比率是多少

获自spinning的misses的百分比是多少

latch请求了多少次

latch休眠了多少次

查看热点对象和访问信息，TCH列表示对象被访问的次数

SQL> SELECT *
    FROM( SELECT addr,
                  ts#,
                  file#,
                  dbarfil,
                  dbablk,
                  tch
             FROM x$bh
         ORDER BY tch DESC)
   WHERE ROWNUM <11;

通过对象的文件号和块号查看具体对象信息

SQL>select owner,segment_name, partition_name,tablespace_name
from dba_extents
where relative_fno = &v_dba_rfile
and &v_dba_block between block_id and block_id + blocks -1;

也可以通过如下sql查找热点块，主要

SELECT *

FROM (SELECT O.OWNER,O.OBJECT_NAME, O.OBJECT_TYPE, SUM(TCH) TOUCHTIME

FROM X$BHB, DBA_OBJECTS O

WHERE B.OBJ= O.DATA_OBJECT_ID

AND B.TS# > 0

GROUP BYO.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE

ORDER BYSUM(TCH) DESC)

WHERE ROWNUM <=10;

查看引起latch: cache buffers chains的sql

SQL> select * from(select
   count(*),
   sql_id,
   nvl(o.object_name,ash.current_obj#) objn,
   substr(o.object_type,0,10) otype,
    3   4   5   6       CURRENT_FILE# fn,
        CURRENT_BLOCK# blockn
   from v$active_session_history ash
      , all_objects o
   where event like 'latch: cachebuffers chains'
    and o.object_id (+)= ash.CURRENT_OBJ#
   group by sql_id, current_obj#,current_file#,
                 current_block#, o.object_name,o.object_type
   order by count(*) desc )where rownum <=10;

根据上面得到的sql_id信息查看sql全文

SQL>selectsql_fulltext from v$sqlarea where sql_id='&sqlid';

查看SQL的执行计划
SQL>SELECT * FROMtable(DBMS_XPLAN.DISPLAY_CURSOR(('&sql_id',0));

在认为sql执行计划不准确的情况也可以通过sql_id查看sql的address和hash_value查看sql的实际执行计划

SQL>SELECT address, hash_value FROM v$sql
WHERE sql_id='&sql_id';
SQL>SELECT operation, options, object_name, cost FROMv$sql_plan
WHERE address = '&addr' AND hash_value = 'hash_v';

当某个会话长时间持有latch时，可以通过联合v$latchholder和v$session视图查看sql信息

SQL>SELECTs.sql_hash_value,s.sql_id,s.address, l.name
FROM V$SESSION s, V$LATCHHOLDER l
WHERE s.sid = l.sid;

故障处理思路

1、根据sql执行计划判断该执行计划是否正确，sql执行过长往往意味着过长时间的持有latch。

2、优化nested loop join，如果有可能使用hash join代替nestedloop join。也可以利用对热块索引进行hash分区，或者使用hash簇的方式减缓热块现象。

3、调整表的pctfree值，将数据尽可能的分布到多个块中

4、调整应用

关于热块，可以参阅笔者的如下文章

http://czmmiao.iteye.com/blog/1474472

参考至:https://sites.google.com/site/embtdbo/wait-event-documentation/oracle-latch-cache-buffers-chains

http://space.itpub.net/354732/viewspace-697317

http://www.toadworld.com/KNOWLEDGE/KnowledgeXpertforOracle/tabid/648/TopicID/RCBCL/Default.aspx

http://blog.163.com/wghbeyond@126/blog/static/351661812010619073376/

0 0

关于latch:&nbsp;cache&nbsp;buffe…

关于latch: cache buffe…