latch: cache buffers chains---AWR实战分析

latch: cache buffers chains---AWR实战分析

 

                 ---------转载

一：等待事件原理

    当一个数据块读入SGA区，相应的buffer header会被放置到hash列表上，我们称其是hash chains,chain在中文的意思是链表，表达的就是关连性，如果一个进程想要访问中修改hash chain上的block，它首先要获得"cache buffers chains" latch。来张原理图吧

二：等待事件产生原因

    该等待事件的主要原因通常多个session重复访问一个或多个数据块，很大程度上和逻辑读有关，所以要关注v$sql中buffer_gets/executions很大的语句，因数每一个逻辑读需要一个latch get操作及一个cpu操作，这样的sql消耗cpu资源比较严重，这也是为什么说常见的表现是CPU使用率较高的原因，原理清楚了，解决起来就简单多了。说的再直白一点，基本上可以确定是因为性能较差的SQL引起的！

三：怎么断定是"latch: cache buffers chains"等待

    方法并不唯一，最直接有效的方法是取系统异常时间的AWR报告或者ASH报告，从AWR上看，如下图所示

            

    前面我们说了该等待事件的原理，因此在这理，排在第二、四位的等待事件就好理解了，

    从ASH上看：

            

     也可以从v$session_wait上获取相关等待信息 

     select p1,p1raw from v$session_wait where event='latch: cache buffers chains';

四、怎么从AWR上去分析

    对于新手而言，拿到AWR报告会看，也能断定数据库是否负载较大，但是怎么根据等待事件去分析是难点，以本案例例说一下分析方法。

    找到逻辑读较高的SQL：  
    第一条比较显眼，但是在实际处理过程中，前三条是都需要分析的，找到对应的SQL，查看访问的都是那些表，在我的案例中访问的表分别是：t_approve_process、t_report_contract、t_report_realtime_item，那么我们就是从AWR上去找逻辑读较大的对像，如下图所示
    
    很显然，正是这几个表逻辑读比较大！好了，原因基本上定位了，下面我们来看看如何去解决

五、怎么去解决

    首先我们要明确一点，处理数据库相关问题有些是固定的方法，有些需要综合考虑分析，因此难点就在这种没有固定解决方案的问题，下面我们分析一下针对此问题的解决方案

1>. 复查应用程序，确认这些SQL多次重复查询是否有必要，尽量去减少相关查询次数，但是，在现实环境中，

    这种情况是最难做的，DBA和开发是不同的部门或公司，配合起来多少有些难度，可行性较小

2>. 查看相关SQL的执行计划，然后进行优化，有朋友可能会说了，这也要修改应用程序呀，还是比较麻烦，但

    事实并不是这样的，我们可以通过DBMS_SQLTUNE包进行优化，不修改应用程序的情况下修改SQL执行计划，

    这个技术我在前面介绍过：http://blog.sina.com.cn/s/blog_61cd89f60102edi3.html 这只是其中的一种

    方法，仅供参考！(此方法可行性较高)

3.> 首先确定是否是因为热点块问题造成的，确定方法详见参考文档

4.> 增加DBWn进程个数，10g默认是2个进程，show parameter db_writer_process

5.> 创建反向索引

6.> 减小buffer cache

    方法很多，目前为止只用到了2、3两种方法，其它方法有具体案例再和朋友们分享！

六、参考文档：

Note:1342917.1 Troubleshooting 'latch: cache buffers chains' Wait Contention

Note:163424.1 How To Identify a Hot Block Within The Database Buffer Cache.