AWR 中的DB Time实验及性能诊断思路

         AWR 中的DB Time表示用户操作花费的时间，包括CPU时间和等待事件。它指的是用户操作的时间，而不包含数据库后台进程花费的时间。

         如何证明上面的话呢？打算开10个PL/SQL窗口，for update一张表，此时就有9个窗口在等待，然后分析AWR报告的DB Time的值。为了试验方便，将AWR快照生成时间调整为10分钟，如何调整见http://blog.csdn.net/guogang83/article/details/8596653   

	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	690	20-2月 -13 17:50:27	17	2.5
End Snap:	691	20-2月 -13 18:00:51	25	1.9
Elapsed:		10.40 (mins)
DB Time:		57.41 (mins)

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
enq: TX - row lock contention	1,150	3,450	3,000	100.2	Application
db file sequential read	692	4	5	.1	User I/O
CPU time		2		.0
control file sequential read	928	0	1	.0	System I/O
control file parallel write	208	0	2	.0	System I/O

         本地的机器是双核的，数据库上除了测试没有其他的操作，可以看到DB Time和等待事件时间差不多。

         总结：DB Time 还有一点要注意的是，CPU消耗的时间为 核数*快照的间隔时间。上面的实验，如果DB Time超过20min，则可以判断出必定有等待事件。在生产环境，DB Time比平常的大很多，都会造成性能问题。两种情况：

          1. CPU消耗大，说明系统负载大，此时可能有低效的SQL语句。

          2. 等待事件长，如果是SQL语句引起的等待事件 ，而SQL语句是请求触发的，在高并发的情况下，会造成中间件的堵塞，从而引发性能问题。