awr

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的构成。

下图是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

相关阅读

1、setTimeout()基础

setTimeout函数用来指定某个函数或某段代码，在多少毫秒之后执行。它返回一个整数，表示定时器的编号，以后可以用

db文件如果用记事本或者Notepad++打开，会显示乱码，改变编码不能解决问题，如果用UltraEdit打开，可以看到进制数据，但是无意义的。正确的

STR(suspend to ram)是符合linux标准规范的standby flow

1:对于时间而言如果是dto类 中的时间的话一般写成String 比较好，若是数据库是Date 则to_date 转换一下就可以了，相对比较灵活，而实体

jdbc-mysql基础 注册驱动DriverManager.registerDriver：http://www.cnblogs.com/jizuiku/p/7843416.html

JAVA JDBC(MySQL)驱动源