--从上可知,整个系统还是比较空闲
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负载情况)
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。
案例如下图: