学习statspack中，向各位大师请教statspack的标准

Question

如题，小弟最近在学习如何分析statspack的报告，可是发现生成的报告有一堆的值出来，可是如何去判断这些值是正常的，有没有低于或者高于标准值，如果高于或者低于这个标准值，有什么方法来改进呢？麻烦各位大师把statspack报告中相关的标准值给小弟指出来。多谢了！

    我看过Eygle写的关于statspack的安装及简单使用手册，可是没有指出相关的标准是怎么样的。麻烦再次指教，多谢！
标准, 如何, 安装, 手册

Answer 1

如果楼主看了Eygle的文章，那么Eygle有没有告诉你Statspack是根时间段有密切关系的，没有这个时间段，无从谈起。拿出一个片段出来就向讨论不是做技术的作风，首先思维要严谨。你现在的问题不是看不看书的问题，是认没认真看的问题，可能我的口气不好，你不用理我。

Answer 2

这好像都是概念的东西。对实际TURNING没有特别的用处。还是多看看在线文档

Answer 3

没有必然联系

Answer 4

学习了，感觉有所进步。

Answer 5

Load Profile

~~~~~~~~~~~~                            Per Second       Per Transaction

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

                  Redo size:              9,440.32              8,524.17

              Logical reads:              5,812.37              5,248.30

              Block changes:                 90.40                 81.63

             Physical reads:              3,771.23              3,405.25

            Physical writes:                  3.90                  3.52

                 User calls:                141.11                127.42

                     Parses:                 49.29                 44.50

                Hard parses:                  1.72                  1.55

                      Sorts:                  5.10                  4.60

                     Logons:                  1.10                  0.99

                   Executes:                 57.21                 51.66

               Transactions:                  1.11

我只上传了load profile部分，

这里的 redo size 跟 block changes 两个数值之间有什么关系吗

Answer 6

说的还不错啊

Answer 7

标准只是相对的，跟具体的应用也有关系

所以要充分了解你的应用

Answer 8

这些都是给已经懂得人看的，你还是该看看书。

OCP的tuning,和Oracle 的Doc比较适合你。

Answer 9

小弟刚才从网上找到了一篇文章，可是里面讲的比较粗，没有提到各种标准。请各位大师补充，多谢！

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

statspack报告数据结果解释

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

2005-4-29 未知

这篇文章来自于oracle中国用户组(********************)的文章，发现对自己学习性能调优很有帮助:

原文链接:http://www.*****.org/viewthread.php?tid=25353

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 文件

访在不同的物理磁盘上。