Oracle CPU负载

一、DB Time和Elapsed time

     Snap Id      Snap Time      Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap:     21787 21-Feb-13 20:00:22        50      19.5
End Snap:     21798 22-Feb-13 07:00:47        44      20.0
Elapsed:              660.42 (mins)
DB Time:              928.06 (mins)
--Elapsed < DB Time
--Elapsed Time=(20130222 07:00:00 - 20130221 20:00:00)≈ 660
--DB Time=928.06 ,运行环境为16核CPU, 660*16=10560, cpu花费了928.06分钟在处理Oralce非空闲等待和运算上
--从上可知，整个系统还是比较空闲

CPU负载= db time/(Elapsed time * cpu个数)*100%

DB TIME= 所有前台session花费在database调用上的总和时间

•注意是前台进程foreground sessions

•包括CPU时间、IO Time、和其他一系列非空闲等待时间，别忘了cpu on queue time

Average Active Session AAS= DB time/Elapsed Time

DB Time =60 min ， Elapsed Time =60 min AAS=60/60=1 负载一般

DB Time= 1min , Elapsed Time= 60 min AAS= 1/60 负载很轻

DB Time= 60000 min，Elapsed Time= 60 min AAS=1000  系统hang了

DB TIME= DB CPU + Non-Idle Wait + Wait on CPU queue

如果仅有2个逻辑CPU，而2个session在60分钟都没等待事件，一直跑在CPU上，那么：

DB CPU= 2 * 60 mins ， DB Time = 2* 60 + 0 + 0 =120

AAS = 120/60=2 正好等于OS load 2。

如果有3个session都100%仅消耗CPU，那么总有一个要wait on queue

DB CPU = 2* 60 mins ，wait on CPU queue= 60 mins

AAS= (120+ 60)/60=3  主机load 亦为3，此时vmstat 看waiting for run time

CPU是指核数，在Oracle查看他探测到的CPU COUNT。

所以上面的看到总Elapsed time*16，在对比下db time也是可以大概感受到系统是否繁忙的。

SQL> show parameter cpu_count

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------

cpu_count                            integer     16

二.Host Cpu（整个主机的CPU负载情况）

“Load Average” begin/end值代表CPU的大致运行队列大小。

上图中快照开始到结束，平均 CPU负载增加了。

%User+%System=> 总的CPU使用率，在这里是29.0%。空闲的CPU使用率为71%。

三.Instance CPU(数据库实例消耗的CPU)

1.%Total CPU,该实例所使用的CPU占总CPU的比例―>% of total CPU for Instance

2.%Busy CPU，该实例所使用的Cpu占总的被使用CPU的比例―> % of busy CPU for Instance

3.例如共4个逻辑CPU，其中3个被完全使用，3个中的1个完全被该实例使用，则%Total CPU= ¼ =25%，而%Busy CPU= 1/3= 33%

4.当CPU高时一般看%Busy CPU可以确定CPU到底是否是本实例消耗的，还是主机上其他程序.

5.%DB time waiting for CPU (Resource Manager)是指当使用了resource manager限制某个用户和会话使用CPU，而产生的等待。会产生resmgr:cpu quantum等待事件，如果产生该等待事件需要和RSRC_MGR的值结合起来判断。解决方法是需要修改资源限制的plan。

案例如下图：