AWR实战分析之

    今天早上在巡检数据库时，发现报表数据库DBTime有些异常，获取当时AWR报告，发现一个新的等待事件bufferbusy waits，记录一下排查分析过程，详细信息如下：

从数据库负载和会话数量上看，数据库没什么问题，但是从TOP 5上我们看到了一个新的等待事件

   该等待事所点时间百分比不高，这也是为什么从数据库负载和会话数量上没有体现出来的原因，但是作为DBA我们需要做的是做异常杀死在摇篮里，DBA救火是必备技能，但是做好消防监控也是必备能力，回到该等等事件上来，先说说该等待事件原理：当一个会话获取数fuffercache中一个数据块时，因为buffer是繁忙的，无法获取，官方给出了两个常见产生该等等事件的原因：

    1.其它会话正在将数据块读入buffer

    2.其它会话以排它模式持有buffer

有点不太好理解，说的简单的，后来经过自己的理解，我给出一种解释，可以简单理解为热块问题，通常发生在频率插入或更新的情况，因为插入时数据可以多次往同一块写入，特别是索引，插入引起块的分裂，产生热块，是不是这样的呢？我们做一下查询我后和AWR中的TOPSQL进行验证。

--查询快照期间发生该等待事件的SQL和BLOCKING SQL

SELECT sql_id,
      blocking_session,
      blocking_session_serial#,
      blocking_session_status,
      p1                      "File",
      p2                      "Block",
      p3                      "Reason"
  FROM dba_hist_active_sess_history
 WHERE event = 'buffer busy waits'
   and snap_id in (5283,5284)

产生该等待事件的SQL_ID为：cw6a7w8u5awwf，然后跟据BLOCKING_SESSION信息查询SQL_ID

select distinct sql_id
  from dba_hist_active_sess_history
 where session_id = '1494'
   and session_serial# ='6076'
   and snap_id in (5283,5284)

结果显示SQL_ID为：404qaurwrsnva

看来我们只需要找到cw6a7w8u5awwf、404qaurwrsnva两个SQL到底在做什么就可以了，现在我们来看AWR报告中TOPSQL部分

很显然，两条都在多次进行插入操作，验证了我们前面的分析，另外，此类等待事件我们需要关注AWR中的如下模块：

综合分析来看，两条SQL执行的操作刚好就是这部分中的表，和该表上的两个索引，至此问题就分析出来了，难点是怎么去解决掉它？

因为我这个案例是逻辑DG，受到操作限制，那么我想避免该类等待事件的操作有两种方法

第一：将普通表做成分区表

第二：将定期将索引删除并重建

第三：调整表和索引pctfree参数，减少同一块中数据记录行数

引起该等待事件的原因可能有多种，详细分类分析请参考DAVE博客：

http://blog.csdn.net/cymm_liu/article/details/7968537