AWR报告关于DB Time的解读

 

    oracle DB Time是从时间角度剖析数据库性能的指标。将性能问题定位在耗费时间最多的事件或SQL语句上。优化的目的便是：减少用户花在数据库上的时间，或减少DB Time。

1. oracle DB Time

    

    oracle DB Time是时间模型统计中最重要的信息。指的是花费在数据库调用上的总时间，是数据库负载的指示灯。   

    DB Time=DB Wait Time（用户会话的非空闲等待）+DB CPU Time（前台session调用）

    DB CPU Time=active user session * Elapsed 时间

    下图是AWR报告的头部信息：

    

    其中，Elapsed是两个快照之间持续的时间。DB Time是前台session调用以及非空闲等待的时间。

    当前服务器，逻辑CPU的数量是32，每个CPU平均服务时间为1792.7/32=56分钟，远大于Elapsed，数据库处于繁忙状态，CPU使用率特别高，一度在90%以上。

    根据公式： DB Time=DB Wait Time（用户会话的非空闲等待）+DB CPU Time（前台session调用），我们需要进一步确定这56分钟的DB Time的构成。

2.Load Profile

下图是load profile部分：

    DB Time（Per Second）=DB Time/Elapsed=93.5

    DB CPU （Per Second）=DB CPU/Elapsed=26.8

    DB CPU占DB Time的比例为：（26.8/93.5）*100%=28.7%，即DB Time中，只有28.7%的时间为DB CPU Time，其余为非空闲等待时间。非空闲等待占用了大量的资源。

3.时间统计模型

下图是AWR报告中的Time Model Statistics部分：

这部分时间是以秒计算的，DB Time=107561.79/60=1792.7min，与头部信息完全相同。

至于这里，为啥占用DB Time的比例超过100%，以及sql execute elapsed time的具体含义就不是很清楚了。

4.前台进程等待事件

    下图是AWR报告中的：Top 10 Foreground Events by Total Wait Time

    

    前台进程的主要等待事件是direct path read和resmgr:cpu quantum，共占用DB Time的60.9%。

   当数据库使用了resource manager限制某个用户和会话使用CPU，而产生的等待。会产生resmgr:cpu quantum等待事件，如果产生该等待事件需要和RSRC_MGR的值结合起来判断。解决方法是需要修改资源限制的plan。 

5.小结

    下面应该可以向等待事件方向进行查询了，直至对数据库做出优化。

    另外，本文参考博客：http://blog.csdn.net/leshami/article/details/73554856

    还有一篇不错的博客：http://blog.csdn.net/lqx0405/article/details/44777659