如何分析AWR (5)
Kaya 发表于 os2ora.com
有一次跟一个QQ上的朋友一起探讨了另一个对系统CPU进行度量的指标: CPU used by this session。
他刚好有一份AWR报告，在这份报告里，出现了严重的CPU used by this session和DB CPU不一致的现象。
下面是这份报告的一些片断
再做进一步的归纳：
OS Busy% = 1821080/(1821080+5384293) = 25%
Inst CPU% (using DB CPU) = 8934.22*100/(1821080+5384293)=12%
Inst CPU% (using CPU used by this session) = 418035/(1821080+5384293) = 6%
用CPU used by this session计算出的CPU利用率竟然只是用DB CPU计算出来的利用通率的一半！
我的第一个反应是在Jonathan lewis网站看到的一篇相关文章，里面提到了DB CPU和CPU used by this session计算时的不同之处:
“prior to 10g Oracle usually updated time figures at the end of each database call; but from 10g there are some views where time is updated more regularly.
The “DB CPU” from v$sess_time_model increases every six seconds, while the “CPU used by this session” from v$sesstat changes only at the end of the test.”
如何验证这一点呢？
在浏览这份报告的TOP SQL时，我们发现了下面的现象：
这是从SQL ordered by Elapsed Time截取出来的Top 3 SQL。TOP 1的SQL用了DB Time的30.10%，用了2517s 的CPU Time。但请注意它的Executions的值却为0。也就是说，这里的CPU Time是还没有被计算入CPU used by this session这个指标里面的。
我们再把2517s加回来，看出误差缩小多少:(251700+418035)/(1821080+5384293) = 9%
这时和用DB CPU计算出来的12%还是有1/4的差距。
从这个例子可以看出，用DB CPU度量还是比用CPU used by this session来得准确的。特别在有大查询在跑的过程中抓的AWR，这个误差很有可能会被放大。
一个有趣的实际例子。
[...] 如何分析AWR (5) http://www.os2ora.com/how-to-analyze-awr-report-5/ [...]
CPU used by this session是纯粹CPU花的时间，用CPU used by this session衡量OS CPU 利用率应该跟准确。
DB CPU包括session等待资源的时间，等待的时候应该并不消耗CPU
不过因为If a user call completes within 10 milliseconds, the start- and end-user call times are the same for purposes of this statistic, and 0 milliseconds are added， CPU used by this session会低估OS cpu time,如果使用db time则会高估。