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