statspack报告数据结果解释

一、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、版本号及主机等信息


   Quote:
STATSPACK report for

DB Name          DB Id     Instance      Inst Num Release      Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
PORMALS        3874352951 pormals              1 9.2.0.4.0    NO       NJLT-SERVER1

             Snap Id      Snap Time       Sessions Curs/Sess Comment
             ------- ------------------ -------- --------- -------------------
Begin Snap:      36   18-7月 -04 20:41:02       29       19.2

   End Snap:      37   19-7月 -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:每秒产生的硬解析次数
Sorts:每秒产生的排序次数
Executes:每秒执行次数
Transactions:每秒产生的事务数，反映数据库任务繁重与否

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


   Quote:
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的未等待比率
Redo NoWait %:在Redo缓冲区获取Buffer的未等待比率
Buffer   Hit %:数据块在数据缓冲区中得命中率，通常应在90%以上，否则，需要调整
In-memory Sort %:在内存中的排序率
Library Hit    %:主要代表sql在共享区的命中率，通常在95%以上，否，需要要考虑加
大共享池，绑定变量，修改cursor_sharing等参数。
Soft Parse %:近似看作sql在共享区的命中率，小于<95%,需要考虑到绑定，如果低于80%，
那么就可能sql基本没有被重用
Execute to Parse %:sql语句解析后被重复执行的次数，如果过低，可以考虑设置
session_cached_cursors参数
Parse CPU to Parse Elapsd %:解析实际运行事件/(解析实际运行时间+解析中等待资源时间)
越高越好
% Non-Parse CPU:查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过多。


   Quote:
Shared Pool Statistics         Begin    End
                                ------   ------
              Memory Usage %:    33.79    57.02
     % SQL with executions>1:    62.62    73.24
   % Memory for SQL w/exec>1:    64.55    78.72



Shared Pool相关统计数据

Memory Usage %:共享池内存使用率，应该稳定在75%-90%间，太小浪费内存，太大则内存不足。

% SQL with executions>1:执行次数大于1的sql比率，若太小可能是没有使用bind variables。

% Memory for SQL w/exec>1:也即是memory for sql with execution > 1:执行次数大于1的sql
消耗内存/所有sql消耗的内存

4、首要等待事件

常见等待事件说明:
oracle等待事件是衡量oracle运行状况的重要依据及指示，主要有空闲等待事件和非空闲等待事件
；空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，
非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。
比较影响性能常见等待事件
db file scattered read
     该事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，
通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。该指数的数量过大说明
缺少索引或者限制使用索引。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。
当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。可以尝试将较小的表放入
缓存keep中，避免反复读取它们。
db file sequential read
    该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕，或者使用了非选
择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确
保索引扫描是必须的，并确保多表连接的连接顺序来调整
buffer busy wait
     当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待.该值不应该大于1%,确认
是不是由于热点块造成(如果是可以用反转索引,或者用更小块大小)
latch free
     闩锁是底层的队列机制(更加准确的名称应该是互斥机制)，用于保护系统全局区(SGA)共享内存结构
。闩锁用于防止对内存结构的并行访问。如果闩锁不可用，就会记录一次闩锁丢失。绝大多数得闩锁问题
都与使用绑定变量失败(库缓存闩锁)、生成重作问题(重执行分配闩锁)、缓存的争用问题(缓存LRU链) 以
及缓存的热数据宽块(缓存链)有关。当闩锁丢失率高于0.5%时，需要调整这个问题。
log buffer space
     日志缓冲区写的速度快于LGWR写REDOFILE的速度,可以增大日志文件大小，增加日志缓冲区的大小，或
者使用更快的磁盘来写数据。
logfile switch
     通常是因为归档速度不够快,需要增大重做日志
log file sync
     当一个用户提交或回滚数据时，LGWR将会话得重做操作从日志缓冲区填充到日志文件中，用户的进程
必须等待这个填充工作完成。为减少这个等待事件，须一次提交更多记录，或者将重做日志REDO LOG 文件
访在不同的物理磁盘上。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16875294/viewspace-526858/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16875294/viewspace-526858/