163 积分	0 好友	12 主题

发消息

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

1^#

发表于 2012-6-22 21:59:36 | 查看: 14254| 回复: 6

环境 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, 下载次数: 1101)
如 call dbms_stats.gather_database_stats_job_proc ( )
..

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

分享0

收藏0 回复只看该作者道具举报

Maclean Liu(刘相兵

2^#

发表于 2012-6-23 20:31:28

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，这是不是一个最简单的方法了呢？

回复只看该作者道具举报

Maclean Liu(刘相兵

3^#

发表于 2012-6-23 20:49:26

在你的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的比例越大

回复只看该作者道具举报