Analysing Statspack 2      

命中率陷阱

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

作者：Jonathan Lewis

了解Statspack的报告的一个重要的事情是要甄别出哪些内容是不需要看的，下面就是一个例子:

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

            Buffer Nowait %:  100.00       Redo NoWait %:    100.00

            Buffer  Hit   %:  100.00    In-memory Sort %:    100.00

            Library Hit   %:   99.96        Soft Parse %:     99.00

         Execute to Parse %:   98.02         Latch Hit %:    100.00

Parse CPU to Parse Elapsd %:   92.74     % Non-Parse CPU:     98.56  

Instance Efficiency 汇总这一部分报告内容实质上是没有用的，至少是在企图通过个别的报告就希望定位到问题所在的情况下。

那么上面的汇总数据又能说明些什么呢？我们继续监控下内存中的数据，所有的排序都在内存中，大部分的解析都是软解析，继续监控下library cache中的对象，每次解析都执行了很多次，解析只占用了少量的cpu时间。

唯一可能会导致性能不佳的地方就是92.74%的数据项，数据显示在解析的时候损失了一点时间，但解析本身所占的比重也是微乎其微，这关系大吗？

事实上，这个实例已经显示出严重的响应时间，系统已超额负载。原因主要有三个主要的设计缺陷，但却不容易发现。但数据显示唯一可疑的地方是92.74%，但我们如何来减少解析的时间开销呢，一种可能恐怕只能让cpu疯狂的工作。

记住：百分比（或者命中率）会隐藏scale。如果每分钟执行一次解析，那么100%硬解析也并非就一定是坏事。但如果每分钟10,000次解析，那么100%的软解析对系统来说也会是灾难，但应当排除使用会话缓存的cursor，但系统仍然记录为一次解析调用的情形。

对于一次解析，1000次执行的具有高达99.9%命中率的情形，如果其中900次的执行都毫无意义，那又何尝是好的设计呢。

如果你确实希望观察一下实例的命中率模型数据，花费一点时间去看一下 Load Profile 部分，尤其是‘每秒’的统计，来决定你的实例是否在合理的工作状态，要时刻的记住平衡原则：如果你把头放在冰桶里，脚放在火堆了，平衡一下你应该是感到最舒服。