原文：http://jonathanlewis.wordpress.com/2006/12/27/analysing-statspack-7/

作者：Jonathan Lewis

这是一段Oracle Database 10g Performance Tuning Tips and Techniques书中的关于Oracle 9i statspack的片段。书中没有给出快照的时间间隔，cpu的个数，平均的active 会话，所以下面的评论完全具有投机性。

但是，作为一个纯理论上的实验，这里将给出一个关于statpack的合理的解释：

Top 5 Timed Events

~~~~~~~~~~~~~~~~~~                                                  % Total

Event                            Waits    Time (s) Ela Time

---------------------------               ------------ ----------- --------

db file sequential read                    399,394,399   2,562,115    52.26

CPU time                                       960,825                19.60

buffer busy waits                           122,302,412  540,757      11.03

PL/SQL lock timer                            4,077       243,056      4.96

log file switch (checkpoint incomplete)      188,701     187,648      3.83

这里的问题是,五个top 数据，哪一个会对用户感知到的系统性能有最大影响。

重述一下，这里仅仅是单纯的猜测，拓展下思路。有可能对于用户来说的性能问题恰巧是报告中占用时间最短的。

我不知道快照的持续时间是多少，也不知道有多少个会话。我能确定的是，如果系统仅仅只有一个cpu，那么快照至少要267个小时（cpu time/3,600）, 如果是16颗cpu，那么就是17个小时，所以可能是16颗cpu，24个小时， 或者64颗cpu，6个小时，我们就假设是后者。

你应该意识到，当有大量的单块读的时候，buffer busy wait也就没有那么的重要了。

当然，如果你在做大量的读的话，buffer busy waits是会有所增加，因为一个会话要等待另一个会话来完成这个块的读，cpu也会因为要锁住cache buffers chains和LRU chains会增大开销，所以，这样的活动应该仔细review一下，以避免发生。(10g中把这个读相关的等待重命名为“read by other session”)；

仔细看一下时间：平均的读时间是6.41毫秒（时间除以读的次数）， 平均的buffer busy wait时间是4.42毫秒，log file switch checkpoint completion的平均等待时间是0.994秒。

这里有两个重要的点，首先，是终端的用户的会话在等待log file switch（checkpoint incomplete），其次是在这个等待上，超时的时间是1S，（这就意味着肯能有不少的长的等待被分割成了1s的时间片）。

现在，我们不知道有多少用户会有checkpoint的问题，或者说是每个用户都等待了多长时间，但是log file switches不应该一直都在发生，一般情况下，大量的以查询为主的活动并不产生redo，所以也不会遇到这个问题。

如果，假设是在6小时的间隔里，大约有188,000次会话活动等待了1s，还有其它的等待。与log switch wait相关的等待又有多少等待时间。在buffer busy wait的2.9s中，单块读的13.6s，全部的16.5s，（这仅仅是使用其它的时间来除以188,000次活动）。

这意味着如果你有15.5活动会话，每一个都在dml操作时会有log switch 等待，log switch wait占用了jammed 会话等待时间的一大部分。我们假设这个是一个大的系统，所以查询和dml活动的比例按照15.5:1来算。

现在已经分析了这些数据，但有一个争论是很明显的，它是可能发生的。这是一个大的系统（或者一大段时间的小系统）完成了大量的工作，这里有明显的标示，资源的浪费和buffer busy waits的争用，但是对于终端用户来说，所能观察到的性能问题可能是checkpoint not complete。

最小的statpack 等待可能是用户最明显的问题所在，平均值会隐藏细节。

Footnote: log file switch（checkpoint not complete）的等待可以很容易的消除，可以使用更多，等大的log文件来解决，有些时候，可以使dbwr写更少的脏块或者让写的数据更快（这个可以通过调整fast_start_mttr_target或者增加dbwr的个数），最合适的方法是仔细的check了log file 大小， log file switch的时间， 两个log_checkpoint参数的设置和一些提前的统计的前提下，做出的决定。

*** Specifically Chapter 14 Using Statspack and the AWR Report to Tune Waits and Latches,  available as a pdf download from McGrawHill.