转详细解读Statspack报告

转个好贴:ITPUB上的BTxigua兄的http://www.itpub.net/viewthread.php?tid=875132&extra=page%3D1%26amp%3Bfilter%3Ddigest

 

 

详细解读 STATSPACK 报告

 

 

详细解读 STATSPACK 报告... 1

1、报表头信息... 2

2、实例负载档信息... 2

3、实例有效性信息... 3

4TOP 5及其他等待事件信息... 5

5SQL统计信息... 10

5.1 SQL统计信息-逻辑读... 11

5.2 SQL统计信息-物理读... 11

5.3 SQL统计信息-执行次数... 12

5.4 SQL统计信息-调用、解析次数... 12

5.5 SQL统计信息-共享内存占用... 13

5.6 SQL统计信息-多版本缓存... 13

6、实例的活动信息... 14

7I/O统计信息... 18

8Buffer Pool统计信息... 20

9、实例的恢复情况统计信息... 21

10Buffer Pool调整的Advisory. 21

11Buffer Pool等待情况统计... 22

12PGA统计信息... 22

13PGA调整的Advisory. 23

14、队列的统计信息... 24

15、回滚段统计信息... 24

16、闩锁统计信息... 26

17、共享池统计信息... 31

18SGA内存分配... 32

19、资源限制统计信息... 33

20、初始化统计信息... 34

  

    说在前面,很容易被忽略的几个点:在读报告的时候,我们首先需要看清楚,留意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 parsesoft parsehard 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空间分配的情况。当前,一般设置为2Mredo 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/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值