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的构成。
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
相关阅读
1、setTimeout()基础 setTimeout函数用来指定某个函数或某段代码，在多少毫秒之后执行。它返回一个整数，表示定时器的编号，以后可以用
db文件如果用记事本或者Notepad++打开，会显示乱码，改变编码不能解决问题，如果用UltraEdit打开，可以看到进制数据，但是无意义的。正确的
STR（suspend to ram）是符合linux标准规范的standby flow
Oracle to_date to_char TIMESTAMP
1:对于时间而言如果是dto类 中的时间的话一般写成String 比较好，若是数据库是Date 则to_date 转换一下就可以了，相对比较灵活，而实体
jdbc-mysql基础 注册驱动DriverManager.registerDriver：http://www.cnblogs.com/jizuiku/p/7843416.html JAVA JDBC(MySQL)驱动源