详细解读 STATSPACK 报告

详细解读 STATSPACK 报告1、报表头信息2、实例负载档信息3、实例有效性信息4、TOP 5及其他等待事件信息5、SQL统计信息5.1 SQL统计信息－逻辑读5.2 SQL统计信息－物理读5.3 SQL统计信息－执行次数5.4 SQL统计信息－调用、解析次数5.5 SQL统计信息－共享内存占用5.6 SQL统计信息－多版本缓存6、实例的活动信息7、I/O统计信息8、Buffer Pool统计信息9、实例的恢复情况统计信息10、Buffer Pool调整的Advisory11、Buffer Pool等待情况统计12、PGA统计信息13、PGA调整的Advisory14、队列的统计信息15、回滚段统计信息16、闩锁统计信息17、共享池统计信息18、SGA内存分配19、资源限制统计信息20、初始化统计信息说在前面，很容易被忽略的几个点：在读报告的时候，我们首先需要看清楚，留意3个内容，这份报告所对应的数据库版本，cluster方式，以及报告的时间段。

尤其需要注意的就是时间段，脱离了时间段的statspck将是毫无意义的，甚至会得出错误的结果。

STATSPACK report for1、报表头信息/* 报表头信息，数据库实例相关信息，包括数据库名称、ID、版本号及主机明等信息。

另外，重点还需要关注一下报告产生的时间跨度（在这里是14分钟），以及并发数（在这里是272）。

DB Name DB Id Instance Inst Num Release Cluster Host------------ ----------- ------------ -------- ----------- ------- ------------ORA92 1924035339 ora92 19.2.0.6.0NO jsdxh_db02Snap Id Snap Time Sessions Curs/Sess Comment--------- ------------------ -------- ----------------------------Begin Snap: 13 14-Jul-07 00:18:52 274 55,345.0End Snap: 14 14-Jul-07 00:32:55 272 55,823.8Elapsed: 14.05 (mins)Cache Sizes (end)~~~~~~~~~~~~~~~~~Buffer Cache: 5,120M Std BlockSize: 8KShared Pool Size: 400M LogBuffer: 2,048K2、实例负载档信息Load Profile~~~~~~~~~~~~ Per Second Per Transaction--------------- ---------------Redosize: 422,086.46 4,706.23Logicalreads: 23,200.54 258.68Blockchanges: 3,080.59 34.35Physicalreads: 31.46 0.35Physicalwrites: 104.38 1.16Usercalls: 409.32 4.56Parses: 227.20 2 .53Hardparses: 7.22 0.08Sorts: 213.87 2 .38Logons: 0.85 0 .01Executes: 1,191.32 13 .28Transactions: 89.69/* 下面详细说明Load Profile各项含义Redo size:每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否。

Logical reads:平决每秒产生的逻辑读的block数。

Logical Reads= Consistent Gets + DB Block Gets 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，可能导致执行计划的不优。

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

Logons:每秒登陆的次数。

Executes:每秒执行次数。

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

% Blocks changed per Read: 13.28 Recursive Call %: 80.21 Rollback per transaction %: 0.03 Rows per Sort: 2.84/* Load Profile 续1) % Blocks changed per Read：在每一次逻辑读中更改的块的百分比。

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

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

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

3、实例有效性信息Instance Efficiency Percentages (Target 100%)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Buffer Nowait %: 99.98 Redo NoWait %: 100.00 Buffer Hit %: 99.87 In-memory Sort %: 100.00 Library Hit %: 99.67 Soft Parse %: 96.82Execute to Parse %: 80.93 Latch Hit %: 96.10 Parse CPU to Parse Elapsd %: 6.93 % Non-Parse CPU: 99.88/* 实例的有效性，这部分值越接近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 %：一个语句执行和分析了多少次的度量。

计算公式为：Execute to Parse =100* (1 - Parses/Executions)。

本例中，差不多每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 timecpu / parse time elapsed)。

即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。