转个好贴:ITPUB上的BTxigua兄的http://www.itpub.net/viewthread.php?tid=875132&extra=page%3D1%26amp%3Bfilter%3Ddigest
详细解读 STATSPACK 报告
说在前面,很容易被忽略的几个点:在读报告的时候,我们首先需要看清楚,留意3个内容,这份报告所对应的数据库版本,cluster方式,以及报告的时间段。尤其需要注意的就是时间段,脱离了时间段的statspck将是毫无意义的,甚至会得出错误的结果。
STATSPACK report for
1、报表头信息
/* 报表头信息,数据库实例相关信息,包括数据库名称、ID、版本号及主机明等信息。
另外,重点还需要关注一下报告产生的时间跨度(在这里是14分钟),以及并发数(在这里是272)。
DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
ORA92 1924035339 ora92 1 9.2.0.6.0 NO jsdxh_db02
Snap Id Snap Time Sessions Curs/Sess Comment
--------- ------------------ -------- --------- -------------------
Begin Snap: 13 14-Jul-07 00:18:52 274 55,345.0
End Snap: 14 14-Jul-07 00:32:55 272 55,823.8
Elapsed: 14.05 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 5,120M Std Block Size: 8K
Shared Pool Size: 400M Log Buffer: 2,048K
2、实例负载档信息
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 422,086.46 4,706.23
Logical reads: 23,200.54 258.68
Block changes: 3,080.59 34.35
Physical reads: 31.46 0.35
Physical writes: 104.38 1.16
User calls: 409.32 4.56
Parses: 227.20 2.53
Hard parses: 7.22 0.08
Sorts: 213.87 2.38
Logons: 0.85 0.01
Executes: 1,191.32 13.28
Transactions: 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.82
Execute 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的。<
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/12778571/viewspace-511841/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/12778571/viewspace-511841/