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语句是请求触发的，在高并发的情况下，会造成中间件的堵塞，从而引发性能问题。