当前位置:首页 > 开发 > 数据库 > 正文

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

发表于: 2013-01-08   作者:czmmiao   来源:转载   浏览次数:
摘要: 一大早就接到开发商的电话,说数据库的CPU使用率为100%,应用相应迟缓。急匆匆的赶到现场发现进行了基本的检查后发现是latch: cache buffers chains 作祟,处理过程还算顺利,当时忘了记录log,这里总结下处理思路,以便下次查看。 故障分析思路 查看等待事件,判断故障起因 SQL>select * from (select sid,event,p1,p2,

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

故障分析思路

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

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

确认为latch: cache buffers chains引起的故障后,查看latch的命中率

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

 

各列名称意义如下

 

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$BH B, DBA_OBJECTS O

         WHERE B.OBJ = O.DATA_OBJECT_ID

           AND B.TS# > 0

         GROUP BY O.OWNER, O.OBJECT_NAME, O.OBJECT_TYPE

         ORDER BY SUM(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: cache buffers 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>select sql_fulltext from v$sqlarea where sql_id='&sqlid';

查看SQL的执行计划
SQL>SELECT * FROM table(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 FROM v$sql_plan
     WHERE address = '&addr' AND hash_value = 'hash_v';

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

SQL>SELECT s.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代替nested loop 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/

本文原创,转载请注明出处、作者

如有错误,欢迎指正

邮箱:czmcj@163.com

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

  • 0

    开心

    开心

  • 0

    板砖

    板砖

  • 0

    感动

    感动

  • 0

    有用

    有用

  • 0

    疑问

    疑问

  • 0

    难过

    难过

  • 0

    无聊

    无聊

  • 0

    震惊

    震惊

编辑推荐
一:硬解析造成的shared pool latch 争用: 每一个sql被执行之前,先要到library cache中根据hash_va
串行化 概述 串行化 - 数据库系统本身是一个多用户并发处理系统,在同一个时间点上,可能会有多个用
一、摘要 由于硬件问题、系统资源紧缺或者程序本身的BUG,Java服务在线上不可避免地会出现一些“系
我们团队为Ucloud云计算服务提供专家技术支持,每天都要碰到无数的用户故障,毕竟IAAS涉及比较底层的
本篇文章是对JA-SIG CAS(v3.3)的初步调研总结。 一 配置实例 应用场景: cas 服务部署在192.168.7
Xmanager连接AIX服务器 xmanager连接AIX服务器可以分为两种情况: 1、连接IBM服务器,使用远程桌面
本篇文章是对JA-SIG CAS(v3.3)的初步调研总结。 一 配置实例 应用场景: cas 服务部署在192.168.7
在dbsnake 上看到的这篇文章,转过来。 主要还是学习解决问题的一个思路。这个往往比问题的解决更重
在dbsnake 上看到的这篇文章,转过来。 主要还是学习解决问题的一个思路。这个往往比问题的解决更重
linux内核由各个不同的子系统构成,比如网络子系统、存储管理子系统等,当然这种设计是为了使内核便
版权所有 IT知识库 CopyRight © 2009-2015 IT知识库 IT610.com , All Rights Reserved. 京ICP备09083238号