statspack report分析

一、statspack 输出结果中必须查看的十项内容

1、负载间档(Load profile)
2、实例效率点击率(Instance efficiency hit ratios)
3、首要的5个等待事件(Top 5 wait events)
4、等待事件(Wait events)
5、闩锁等待
6、首要的SQL(Top sql)
7、实例活动(Instance activity)
8、文件I/O(File I/O)
9、内存分配(Memory allocation)
10、缓冲区等待(Buffer waits)

二、输出结果解释

1、报表头信息
数据库实例相关信息，包括数据库名称、ID、版本号及主机等信息

 
STATSPACK report for
DB Name    DB Id    Instance   Inst Num  Release     Cluster   Host
------------  ---------  ----------   ---------   ---------   -------  ----------
Allen       3874352951   allen      1    9.2.0.4.0      NO   ALLEN_WANG
            Snap Id     Snap Time      Sessions Curs/Sess Comment
            ------- ------------------ -------- --------- -------------------
Begin Snap:     36  18-11月 -04  20:41:02      29      19.2

  End Snap:     37  18-11月 -04 08:18:27      24      15.7
   Elapsed:                              697.42 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
               Buffer Cache:       240M      Std Block Size:        8K
           Shared Pool Size:        96M          Log Buffer:      512K

2、负载间档
该部分提供每秒和每个事物的统计信息，是监控系统吞吐量和负载变化的重要部分

  Quote:

 
Load Profile
~~~~~~~~~~~~                            Per Second(秒)      Per Transaction事物
                                   ---------------       ---------------
                  Redo size:                148.46              3,702.15
              Logical reads:              1,267.94             31,619.12
              Block changes:                  1.01                 25.31
             Physical reads:                  4.04                100.66
            Physical writes:                  4.04                100.71
                 User calls:                 13.95                347.77
                     Parses:                  4.98                124.15
                Hard parses:                  0.02                  0.54
                      Sorts:                  1.33                 33.25
                     Logons:                  0.00                  0.02
                   Executes:                  2.46                 61.37
               Transactions:                  0.04
  % Blocks changed per Read:    0.08    Recursive Call %:                30.38
Rollback per transaction %:    0.42       Rows per Sort:               698.23
 

说明:
Redo size:每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否
Logical reads:平决每秒产生的逻辑读，单位是block
block changes:每秒block变化数量，数据库事物带来改变的块数量
Physical reads:平均每秒数据库从磁盘读取的block数
Physical writes:平均每秒数据库写磁盘的block数
User calls:每秒用户call次数
Parses: 每秒解析次数，近似反应每秒语句的执行次数, 软解析每秒超过300次意味着你的"应  用程序"效率不高，没有使用soft soft parse，调整session_cursor_cache
Hard parses:每秒产生的硬解析次数, 每秒超过100次，就可能说明你绑定使用的不好
Sorts:每秒产生的排序次数
Executes:每秒执行次数
Transactions:每秒产生的事务数，反映数据库任务繁重与否
Recursive Call %: 如果有很多PLSQL，那么他就会比较高

Rollback per transaction %:看回滚率是不是很高，因为回滚很耗资源

如果回滚率过高，可能说明你的数据库经历了太多的无效操作

过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下:

Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%

 

3、实例命中率
该部分可以提前找出ORACLE潜在将要发生的性能问题，很重要  

 
Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            Buffer Nowait %:  100.00       Redo NoWait %:              100.00
            Buffer  Hit   %:   99.96    In-memory Sort %:               99.14
            Library Hit   %:   99.53        Soft Parse %:               99.57
         Execute to Parse %: -102.31         Latch Hit %:              100.00
Parse CPU to Parse Elapsd %:   81.47     % Non-Parse CPU:               96.46

说明:
Buffer Nowait %:在缓冲区中获取Buffer的未等待比率, Buffer Nowait<99%说明，有可能是有热,   块(查找x$bh的 tch和v$latch_children的cache buffers chains)  
Redo NoWait %:在Redo缓冲区获取Buffer的未等待比率
Buffer  Hit %:数据块在数据缓冲区中得命中率，通常应在90%以上，否则，需要调整, 小于                              95%,重要的参数,小于90%可能是要加db_cache_size,但是大量的非选择的索引也会造成该值很高（大量的db file sequential read）
In-memory Sort %:在内存中的排序率
Library Hit %:主要代表sql在共享区的命中率，通常在95%以上，否，需要要考虑加
               大共享池，绑定变量，修改cursor_sharing等参数。
Soft Parse %:近似看作sql在共享区的命中率，小于<95%,需要考虑到绑定，如果低于80%，
              那么就可能sql基本没有被重用
Execute to Parse %:sql语句解析后被重复执行的次数，如果过低，可以考虑设置
                   session_cached_cursors参数, 公式为100 * (1 - Parses/Executions)       = Execute to Parse所以如果系统Parses > Executions,就可能出现该比率小于0的情况, 该值<0通常说明shared pool设置或效率存在问题造成反复解析，reparse可能较严重,或者可是同snapshot有关如果该值为负值或者极低,通常说明数据库性能存在问题

Latch Hit %: Latch Hit<99%,要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数
Parse CPU to Parse Elapsd %:解析实际运行事件/(解析实际运行时间