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

一个有趣的实际例子。

上一篇文章提到的那些个工具，主要侧重点在于实时监控，而在我看来，实时监控只是一个监控工具的一个职责而已。就如Linux上的collectl或者nmon一样，我们还需要对这些历史性能数据进行保存，以便于过后进行分析。而且，这也是一个不可或缺的功能，毕竟，DBA不会也不可能24小时盯着屏幕，DBA做的主要事情应该是对历史数据进行分析，从而更好的认识数据库的工作状态。

监控工具方面，也有很多实现这方面需求的软件。记得anySQL.net上面就有一个类似的监控工具。通过收集v$sysstat和v$session的数据，再利用图表的方式进行分析。这应该是这类软件的共性。

但有一个”工具”值得大提特提，那就是Oracle自身的AWR。AWR默认一个小时对系统做一次快照，这些快照其实就是难得的历史性能数据，Oracle自带的AWR报告，主要是基于两个快照间的分析，因此只能得到一些孤立的数值。如果我们能够更进一步，实现对所有快照数据的分析，我们就能清晰地了解系统过去一段时间（默认AWR保留7天）的工作负载的特征曲线，各种重要指标的变化曲线。我想，这些曲线对于DBA或者决策层而言都是极其有价值的。

对这些曲线进行部分展示的，就是Enterprise Manager了。在Performance这个Tab里面，可以选择按Historical浏览的方式。这其实就是对AWR Repository里的数据进行查询。不过EM只提供对一天时间跨度的drill down，所提供的曲线也比较有限，归纳起来，11g里EM提供的主要曲线有：

1. Average Active Sessions – 7 Day View
2. Host: Runnable Processes  – 1 Day
3. Average Active Sessions – 1 Day
4. Logon/Transaction Rate – 1 Day
5. Physical Reads/Redo Size Rate – 1 Day
6. Latency For Synchronous Single Block Reads – 1 Day
7. I/O Megabytes per Second by I/O Function – 1 Day
8. I/O Request per Second by I/O Function – 1 Day
9. Sessions of Parallel Execution – 1 Day
10. Active Sessions of Services – 1 Day

网络上实现类似功能的软件好象不多(知道的朋友请多comment一下)，不过，碰巧也找到了一个，叫做ONDATAPERF。通过用户上传一系列的Statspack或者AWR报告，最后据说会产生一个类似这个链接的ONDATAPERF report。这个报告里面的图表看起来还是很酷的，随便抓一个ASH的例子。

当然，唯一的缺点是这是一个付费服务。

其实，要自己实现类似的功能或者更全面的图表也不是很难的一件事情。可以考虑参考nmon的Analyser，做一个专门针对AWR Repository的Analayser出来。这应该是挺有意义，挺有先驱性的一件事情。要真有这个工具，说不定可以和这个ONDATAPERF 竞争一番呢!