有一次跟一个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，这个误差很有可能会被放大。

一个有趣的实际例子。