论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2008-03-24 10:30 |只看该作者 |倒序浏览

刚刚看了《oracle高效设计》书中，TOM有关如何分析statspack报告的文章，颇有体会，记录在此，以备记忆。

TOM在这里提高他关注的几个部分，

“我最感兴趣的是statspack采集所占用的时间，我希望大得有意义，而小得相当。我偏爱15-30之间的数目。。。。。。”，这里指出了一个令人寻味的话题，如何确定statspack执行数据采集所用的时间，一般在高峰期控制在15-30分钟采集一次。

“硬分析（希望最少）、执行（每秒/事务执行多少语句）、事务处理（每秒处理多少事务），这些提供了对服务器装载的总评价”，这句话点明了我们应该重点关注哪几个指标。这些指标对系统的影响程度多高，以及如何通过这些指标去发现系统中存在的问题。

Load Profile                         Per Second    Per Transaction
~~~~~~~~~~~~                      ---------------    ---------------
               Redo size:             1,113.79          217,932.29
            Logical reads:                14.55             2,847.84
            Block changes:                2.72             532.17
         Physical reads:                0.05                10.42
         Physical writes:                0.39                77.12
               User calls:                0.01                2.41
                  Parses:                0.84             164.10
            Hard parses:                0.06                11.77
                  Sorts:                0.75             145.99
                  Logons:                0.00                0.80
               Executes:                2.11             412.06
            Transactions:                0.01

红色数字标出的是TOM提到的重要指标，应该最先分析，本例中硬分析每秒0.06个，非常少，不是因为业务量少，就是因为应用调整的不错。

Instance Efficiency Percentages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         Buffer Nowait %:  100.00    Redo NoWait %: 99.99
         Buffer  Hit %: 99.64 In-memory Sort %:  100.00
          Library Hit %: 92.71       Soft Parse %: 92.83
      Execute to Parse %: 60.18       Latch Hit %: 99.98
Parse CPU to Parse Elapsd %: 68.30    % Non-Parse CPU: 81.28

  以上这些红色的实例效率指标，都与共享池的利用程度有关。

  如果Library hit太小，表现出共享池太小，或者系统未正确在应用中使用绑定变

量。

  soft parse% 计算公式如下：  round(100*(1-:hprs/:prse),2) ，即1减去硬分析占用总分析的比例。尽量降低硬分析的比例，提高软

分析比例，这是性能调整的重要目标。

  Execute to Parse 计算公式如下：  round（100*(1-prse/:exe),2) ，即1减去分析次数占执行次数的比例。

  分析和执行是两种概念，不能武断地认为执行次数少就好，或者分析次数少就好，应该客观地根据应用系统的业务使用量来确定，如果是一

个白天业务量非常大的系统，那么执行次数可能比较多，这个比率应该较小，在晚上只进行数据归档或者备份，那么执行次数就会少，这个比

率相对就高。

  Top 5 Timed Events

  Tom如是说：“这些指标是整个报告里面最重要的部分，可以发现那些事件（等待事件）耗费最多的时间。”

  Top 5 Timed Events                                                 Avg %Total
~~~~~~~~~~~~~~~~~~                                                 wait Call
Event                                           Waits Time (s) (ms) Time
----------------------------------------- ------------ ----------- ------ ------
CPU time                                                       25       71.2
db file sequential read                         475          3    7 9.2
control file parallel write                   4,524          2    1 6.8
log file parallel write                         1,232          2    1 5.2
db file scattered read                            56          1    19 3.2

cpu time  在15分钟的采集过程中，总的cpu处理时间71.2秒，占用15×60=900秒时间的10分之1，是可行的。

概述：

通过使用以上这些指标，结合系统的应用程序，已经应用程序的使用环境来确定系统的瓶颈之所在，然后参考剩余部分来找出问题发生的

原因，如：低效的sql，没有使用绑定变量的proc，大量进行了全表扫描的SQL等等。