DB CPU 是一个用于衡量 CPU 的使用率的重要指标。假设系统有N个 CPU，那么如果 CPU全部处于繁忙状态的话，一秒钟内的 DB CPU 就是N秒。
如何去表征一个系统的繁忙程度呢？
除了利用 CPU 进行计算外，数据库还会利用其它计算资源，如网络、硬盘、内存等等，这些对资源的利用同样可以利用时间进行度量。
假设系统有M个 Session 在运行，同一时刻，有的 Session 可能在利用 CPU，有的 Session 可能在访问硬盘，那么，在一秒钟内，所有 Session 的时间加起来就可以表征系统在这一秒内的繁忙程度，一般的，这个和的最大值应该为 M。这其实就是 Oracle 提供的另一个重要指标：DB Time，它用以衡量前端进程所消耗的总时间。
对除 CPU 以外的计算资源的访问，Oracle 用等待事件进行描述。同样地，和 CPU 可分为前台消耗 CPU 和后台消耗 CPU一样，等待事件也可以分为前台等待事件和后台等待事件。
DB Time 一般的应该等于DB CPU + 前台等待事件所消耗时间的总和。
等待时间通过 V$SYSTEM_EVENT 视图进行统计，DB Time 和 DB CPU 则是通过同一个视图，即V$SYS_TIME_MODEL 进行统计。
在 AWR 报告的 Load Profile 一节就有了对 DB Time 的描述：
这个系统的 CPU 个数是8，因此我们可以知道前台进程用了系统 CPU 的7.1/8=88.75%。
DB Time/s 为11.7，可以看出这个系统是 CPU 非常繁忙的，里面 CPU 占了7.1，则其它前台等待事件占了11.7 –7.1 = 4.6 Wait Time/s。
DB CPU 占 DB Time 的比重呢？ 7.1/11.7= 60.68%
Top 5 Timed Events，或许很多人都对它有所耳闻，按照 CPU/ 等待事件占 DB Time 的比例大小，这里列出了 Top 5。如果一个工作负载是 CPU 繁忙型的话，那么在这里应该可以看到 DB CPU 的影子。
注意到，我们刚刚已经算出了 DB CPU 的 %DB time 为60%左右。
其它的 external table read，direct path write， PX Deq: read credit， PXDeq: Slave Session Stats 这些就是占比重40%的等待事件里的 Top 4了。
回过头再研究下这个 Top 5 Timed Foreground Events，如果先不看 Load Profile，你能说出这个一个 CPU-Bound 的工作负载吗？
答案是否定的，要知道系统 CPU 的繁忙程序，还要知道这个 AWR 所基于两个 Snapshot 的时间间隔，还要知道系统 CPU 的个数。否则，系统可以是一个很 IDLE 的系统呢。记住 CPU 利用率= DB CPU/(CPU_COUNT*Elapsed TIME)。
这个 Top5 给我们的信息只是这个工作负载应该是并行查询，从外部表读取数据，并用 insert append 的方式写入磁盘，同时，主要时间耗费在 CPU 的运算上。
上面提到，DB Time 一般的应该等于 DB CPU + 前台等待事件所消耗时间的总和。在下面有对这三个值的统计：
DB CPU = 6474.65
DB TIME = 10711.2
FG Wait Time = 1182.63
明显的，DB CPU + FG Wait Time < DB Time，只占了71.5%
其它的28.5%被消耗到哪里去了呢？这里其实又隐含着一个 Oracle 如何计算 DB CPU 和 DB Time 的问题。
当 CPU 很忙时，如果系统里存在着很多进程，就会发生进程排队等待 CPU 的现象。在这样，DB TIME 是把进程排队等待 CPU 的时间算在内的，而 DB CPU 是不包括这一部分时间。这是造成 DB CPU + FG Wait Time < DB Time 的一个重要原因。如果一个系统 CPU 不忙，这两者应该就比较接近了。
不要忘了在这个例子中，这是一个 CPU 非常繁忙的系统，而71.5%就是一个信号，它提示着这个系统可能是一个 CPU-Bound 的系统。
