11G AWR中%Total CPU与%Busy CPU指标的疑问

不了峰

环境 Oracle 11.2.0.1.0 windows 64位 单实例
收集了一份awr报告（时间段01~02点）中
Elapsed:         59.21 (mins)         
DB Time:         299.39 (mins)

Host CPU (CPUs: 24 Cores: 12 Sockets: 2)
Load Average Begin    Load Average End    %User    %System    %WIO    %Idle
                                                            4.2        0.0                            95.8
即%user=4.2 ,%Idle=95.8

Instance CPU
%Total CPU    %Busy CPU    %DB time waiting for CPU (Resource Manager)
21.0                   495.4                  0.0

（1）想请问 这里的%Busy CPU为何看起来感觉很大的样子。
是不是说明某个cpu非常繁忙........还是有另外的原因？

附，这个时段的逻辑读为253MB/s .其它的指标几乎都小于20..
  查看
SQL ordered by Gets  中top 3 的Buffer Gets都是一样的，

语句见附件
top_get.txt (646 Bytes, 下载次数: 1050)

2012-6-22 21:59 上传

点击文件名下载附件

如 call dbms_stats.gather_database_stats_job_proc ( )
..

另问（2）这些SQL感觉很奇怪，是在收集统计信息？

baolei

OS级的%User为75.4，%Sys为2.8，%Idle为21.2，所以%Busy应该是78.8。

   busy 为什么 不是 sys+user 而用100 - idle 算

不了峰

我怀疑是11g的自动统计任务引起的。
看awr报告，我猜他是在分析不良sql语句时，产生大量的逻辑讯之类

ora-hansey

没搞明白，这种case是怎么产生的。怎么会有这么大的值。db cpu 占用os cpu的比率很小。但是在instance层面 busy cpu却很高。这个时候，instance为什么不多占用一下os cpu呢？

不了峰

谢谢！ 回去慢慢看！

Maclean Liu(刘相兵

在你的case 中

Instance CPU %Total CPU   = 21%

OS %busy =  4.2%

则 Instance CPU %Busy CPU  =  21/4.2 * 100= 500%  约等于 495%

=>  假设 Instance cpu % total cpu不变则 %Busy 越大  ，  instance cpu %busy cpu 越小， 反应 实例占用busy cpu的比例越小
=>  假设 Instance cpu % total cpu不变则 %Busy越小，     instance cpu %busy cpu 越大， 反应实例占用bucy cpu的比例越大

Maclean Liu(刘相兵

ODM FINDING:

FROM http://www.os2ora.com/how-to-analyze-awr-report-1/  推荐  kaya 的这篇文章

引用如下：


如果关注数据库的性能，那么当拿到一份AWR报告的时候，最想知道的第一件事情可能就是系统资源的利用情况了，而首当其冲的，就是CPU。
而细分起来，CPU可能指的是

• OS级的User%, Sys%, Idle%
• DB所占OS CPU资源的Busy%
• DB CPU又可以分为前台所消耗的CPU和后台所消耗的CPU

如果数据库的版本是11g，那么很幸运的，这些信息在AWR报告中一目了然:

OS级的%User为75.4，%Sys为2.8，%Idle为21.2，所以%Busy应该是78.8。
DB占了OS CPU资源的69.1，%Busy CPU则可以通过上面的数据得到：
%Busy CPU = %Total CPU/(%Busy) * 100 = 69.1/78.8 * 100 = 87.69，和报告的87.7相吻合。
如果是10g呢，则需要手工对Report里的一些数据进行计算了。
Host CPU的结果来源于DBA_HIST_OSSTAT，AWR 报告里已经帮忙整出了这段时间内的绝对数据(这里的时间单位是centi second,也就是1/100秒)

这里，
%User = USER_TIME/(BUSY_TIME+IDLE_TIME)*100 = 146355/(152946+41230)*100 = 75.37
%Sys  = SYS_TIME/(BUSY_TIME+IDLE_TIME)*100
%Idle = IDLE_TIME/(BUSY_TIME+IDLE_TIME)*100
值得注意的，这里已经隐含着这个AWR报告所捕捉的两个snapshot之间的时间长短了。有下面的公式
BUSY_TIME + IDLE_TIME = ELAPSED_TIME * CPU_COUNT
正确的理解这个公式可以对系统CPU资源的使用及其度量的方式有更深一步的理解。
因此ELAPSED_TIME = (152946+41230)/8/100 =  242.72 seconds
当然，这正确无误。
至于DB对CPU的利用情况，这就涉及到10g新引入的一个关于时间统计的视图了， v$sys_time_model，简单而言，Oracle采用了一个统一的时间模型对一些重要的时间指标进行了记录，具体而言，这些指标包括:
1) background elapsed time    2) background cpu time          3) RMAN cpu time (backup/restore)1) DB time    2) DB CPU    2) connection management call elapsed time    2) sequence load elapsed time    2) sql execute elapsed time    2) parse time elapsed          3) hard parse elapsed time                4) hard parse (sharing criteria) elapsed time                    5) hard parse (bind mismatch) elapsed time          3) failed parse elapsed time                4) failed parse (out of shared memory) elapsed time    2) PL/SQL execution elapsed time    2) inbound PL/SQL rpc elapsed time    2) PL/SQL compilation elapsed time    2) Java execution elapsed time    2) repeated bind elapsed time我们这里关注的只有和CPU相关的两个: background cpu time 和 DB CPU。
这两个值在AWR里面也有记录:

Total DB CPU = DB CPU + background cpu time = 1305.89 + 35.91 = 1341.8 seconds
再除以总的 BUSY_TIME + IDLE_TIME
% Total CPU = 1341.8/1941.76 = 69.1%，这刚好与上面Report的值相吻合。
其实，在Load Profile部分，我们也可以看出DB对系统CPU的资源利用情况。

用DB CPU per Second除以CPU Count就可以得到DB在前台所消耗的CPU%了。
这里 5.3/8 = 66.25 %
比69.1%稍小，说明DB在后台也消耗了大约3%的CPU，这是不是一个最简单的方法了呢？