如何读懂 STATSPACK 报告 amp;Toad 结合

Answer 1

　　说在前面，很容易被忽略的几个点：在读报告的时候，我们首先需要看清楚，留意3个内容，这份报告所对应的数据库版本，cluster方式，以及报告的时间段。尤其需要注意的就是时间段，脱离了时间段的statspck将是毫无意义的，甚至会得出错误的结果。 STATSPACK report for

　　1、报表头信息
　　
　　/* 报表头信息，数据库实例相关信息，包括数据库名称、ID、版本号及主机明等信息。 另外，重点还需要关注一下报告产生的时间跨度, 以及并发数.
　　

　　2、实例负载档信息
　　

　　下面详细说明Load Profile各项含义

　　Redo size:每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否。通常在很繁忙的系统中日志生成量可能达到上百k，甚至几百k

　　Logical reads:平决每秒产生的逻辑读的block数。Logical Reads= Consistent Gets + DB Block Gets, block在内存中，我们每一次读一块内存，就相当于一次逻辑读

　　Block changes:每秒block变化数量，数据库事物带来改变的块数量。

　　Physical reads:平均每秒数据库从磁盘读取的block数。

　　Physical writes:平均每秒数据库写磁盘的block数。

　　User calls:每秒用户调用次数。

　　Parses:每秒解析次数，包括fast parse，soft parse和hard parse三种数量的综合。软解析每秒超过300次意味着你的"应用程序"效率不高，调整session_cursor_cache。在这里，fast parse指的是直接在PGA中命中的情况（设置了session_cached_cursors=n）；soft parse是指在shared pool中命中的情形；hard parse则是指都不命中的情况。 Hard parses:每秒产生的硬解析次数, 每秒超过100次，就可能说明你绑定使用的不好，也可能是共享池设置不合理。这时候可以启用参数cursor_sharing=similar|force，该参数默认值为exact。但该参数设置为similar时，存在bug，可能导致执行计划的不优。 80%的系统的慢都是由于这个原因所导致的, 而hard parse的根源，基本都是由于不使用bind var所导致的, 还有就是为了维护internal structure，需要使用latch，latch是一种Oracle低级结构,用于保护内存资源，是一种内部生命周期很短的lock，大量使用latch将消耗大量的cpu资源。

　　Sorts:每秒产生的排序次数。

　　Logons:每秒登陆的次数。

　　Executes:每秒执行次数。

　　Transactions:每秒产生的事务数，反映数据库任务繁重与否。

　　Blocks changed per Read: 13.28 %

　　Recursive Call %: 80.21

　　Rollback per transaction %: 0.03

　　说明如下:
　　
　　1) Blocks changed per Read：在每一次逻辑读中更改的块的百分比。

　　2) Rollback per transaction %:看回滚率是不是很高，因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。通常应该小于10%为好

　　3) Recursive Call %:递归调用的百分比，如果有很多PL/SQL，那么这个值就会比较高。

　　4) Rows per Sort:平均每次排序操作的行数。

　　3、实例有效性信息
　　

　　实例的有效性，这部分值越接近100越好，分项内容详细说明如下：

　　1) Buffer Nowait %：在缓冲区中获取Buffer的未等待比率。Buffer Nowait的这个值一般需要大于99%。否则可能存在争用，可以在后面的等待事件中进一步确认。

　　2) Redo NoWait %：在Redo缓冲区获取Buffer空间的未等待比率。当redo buffer达到1M时，就需要写到redo log文件，所以一般当redo buffer设置超过1M，不太可能存在等待buffer空间分配的情况。当前，一般设置为2M的redo buffer，对于内存总量来说，应该不是一个太大的值。

　　3) Buffer Hit %：数据块在数据缓冲区中的命中率，通常应在95%以上。否则，小于95%，需要调整重要的参数，小于90%可能是要加db_cache_size。一个高的命中率，不一定代表这个系统的性能是最优的，比如大量的非选择性的索引被频繁访问，就会造成命中率很高的假相（大量的db file sequential read），但是一个比较低的命中率，一般就会对这个系统的性能产生影响，需要调整。命中率的突变，往往是一个不好的信息。如果命中率突然增大，可以检查top buffer get SQL，查看导致大量逻辑读的语句和索引，如果命中率突然减小，可以检查top physical reads SQL，检查产生大量物理读的语句，主要是那些没有使用索引或者索引被删除的。

　　4) In-memory Sort %：在内存中的排序率。如果低于95%，可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决，注意这两个参数设置作用的范围时不同的，SORT_AREA_SIZE是针对每个session设置的，PGA_AGGREGATE_TARGET则时针对所有的sesion的。

　　5) Library Hit %：STATEMENT在共享区的命中率，通常应该保持在95%以上，否则需要要考虑：加大共享池；使用绑定变量；修改cursor_sharing等参数。

　　6) Soft Parse %：sql在共享区的命中率，小于<95%,需要考虑绑定，如果低于80%，那么就可以认为sql基本没有被重用。

　　7) Execute to Parse %：一个语句执行和分析了多少次的度量。这个数字也应该是越大越好，接近100%最好, 本例中，差不多每execution 5次需要一次parse。所以如果系统Parses > Executions，就可能出现该比率小于0的情况。该值<0通常说明shared pool设置或者语句效率存在问题，造成反复解析，reparse可能较严重,或者是可能同snapshot有关，通常说明数据库性能存在问题。

　　8) Latch Hit %：要确保>99%，否则存在严重的性能问题。当该值出现问题的时候，我们可以借助后面的等待时间和latch分析来查找解决问题。

　　9) Parse CPU to Parse Elapsd %：计算公式为：Parse CPU to Parse Elapsd %= 100*(parse time cpu / parse time elapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。

　　10) % Non-Parse CPU：计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这个值比较小，表示解析消耗的CPU时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。

　　(上图中的下半部分)
　　
　　1) Memory Usage %：正在使用的共享池的百分率。这个数字应该长时间稳定在75%～90%。如果这个百分比太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内。

　　2) % SQL with executions>1：这是在共享池中有多少个执行次数大于一次的SQL语句的度量。也应该大为好，小则表示很多sql只被执行了一次，说明没有使用绑定变量, 在一个趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。在共享池中，在观察期间将有一组未被执行过的SQL语句，这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组，这个数字才会接近100%。这里显示，在这个共享池中几乎有80%的SQL语句在14分钟的观察窗口中运行次数多于一次。剩下的20%的语句可能已经在那里了--系统只是没有去执行。

　　3) % Memory for SQL w/exec>1：这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。这个数字将在总体上与% SQL with executions>1非常接近，除非有某些查询任务消耗的内存没有规律。在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期，执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。 小结：通过ORACLE的实例有效性统计数据，我们可以获得大概的一个整体印象，然而我们并不能由此来确定数据运行的性能。当前性能问题的确定，我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容，hit统计帮助我们发现和预测一些系统将要产生的性能问题，由此我们可以做到未雨绸缪。而wait事件，就是表明当前数据库已经出现了性能问题需要解决，所以是亡羊补牢的性质。 接下来，开始查看wait事件。