详细解读 STATSPACK 报告

详细解读 STATSPACK 报告 1
1、报表头信息 2
2、实例负载档信息 2
3、实例有效性信息 3
4、TOP 5及其他等待事件信息 5
5、SQL统计信息 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
7、I/O统计信息 18
8、Buffer Pool统计信息 20
9、实例的恢复情况统计信息 21
10、Buffer Pool调整的Advisory 21
11、Buffer Pool等待情况统计 22
12、PGA统计信息 22
13、PGA调整的Advisory 23
14、队列的统计信息 24
15、回滚段统计信息 24
16、闩锁统计信息 26
17、共享池统计信息 31
18、SGA内存分配 32
19、资源限制统计信息 33
20、初始化统计信息 34



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

1)redo size:每秒产生的日志大小(单位字节),可标志数据变更频率,数据库任务的繁重与否.
2)logical reads:每秒产生它的block数.logical reads=consistent gets+db block gets ---对这些概念不太理解
3)block changes:每秒产生block变化数量,事务引起改变的块数量
4)physical reads:每秒数据库从磁盘读取的blocks数
5)physical writes:每秒数据库写到磁盘的blocks数
6)user calls:每秒用户调用次数
7)parses:每秒解析次数,including fast parse,soft parse and hard parse.soft parse如果多于300次,表示你的
         应用程序效率不高,没有使用绑定变量.可以调整session_cursor_cache
8)hard parseser second hard parses numbers,default exact,但如果为similar,可能导致执行计划不优.
9)sortser second sort numbers genarated
10) logonser second logon numbers
11)executeser second execute numbers
12)transactions;per second transactions genarated ,indicate task load


% Blocks changed per Read:   13.28    Recursive Call %:     80.21
Rollback per transaction %:    0.03       Rows per Sort:      2.84
1)% blocks changed per read   :在每一次logical read更改块的百分比
2)rollback per transaction %  :看rollback rate 是不是很高,因为rollback quite take resource.如果rollback over high,
                               说明你的数据库经历太多无效操作.过多的rollback 会导致undo block contention.
                               round(user rollbacks/(user commits+user rollbacks),4)*100%
3)recursive call %ercentage of recursive call,if have more plsql,its value may be high
4)rows per sort: 每次排序操作行数







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的未等待rate.buffer nowait这个值一般要大于99%,否则可能存在contention,
                  可以在后面的等待事件进一步确认
2)redo nowait %:在redo buffer中获取buffer空间的未等待rate,当redo buffer>=1m,就需要写到redo log文件,所以一般
                 当redo buffer超过1m,不太可能存在等待buffer 空间分配的情况.当前,一般设置为2m的redo buffer.
3)buffer hit %:数据块在数据缓冲区中的hit rate,通常应在95%,否则,需要调整重要的参数,小于90%,加大db_cache_size.
                当然,一个高hit rate,不一定就表示这个系统最优,比如大量非选择性的索引被频繁访问,
                就会形成假相:大量的db file sequential read,leading to high hit rate.
                but very 低的hit rate,一定要影响,要tuning,
                如果hit rate突然增大,可以检查top buffer get sql,查看导致大量logical read (sql and index)
                if hit rate suddenly decrease,check top physical reads sql,check 产生大量物理读的语句,
                主要是没有使用索引或者索引被删除.
4)in_memory sort %:在内存的排序rate,如果低于95%,可以调大pga_aggregate_target或者sort_area_size,这二个参数适用范围
                 不同,sort_area_size是针对每个session,pga_aggregate_target针对所有session.
5)library hit %:statement 在share area的hit rate,commonly remain great than 95%,否则需要注意:加大共享池,使用绑定变量,
                  修改cursor_sharing.
6)soft parse %:sql在共享区的hit rate,小于<95%,需要注意绑定,如果低于80%,可以认为sql没有被重用.
7)execute to parse %:一个语句执行和分析了多少次的度量,公式:execute to parse=100*(1-parses/executions).
                     本例中,差不多每execution 5次就要一次parse,所以如果系统parses>executions,就可能出现rate小于0,  
                     说明shared pool 有问题或语句存在问题,形成反复parse,reparse可能较严重,或者可能同snapshot有关,说明数据库
                     性能存在问题.
8)latch hit%:要确保>99%,否则存在严重的性能问题,如出现问题,可以借助后面的等待时间和latch来分析查找解决问题.
9)parse cpu to parse elapsed %:公式为arse cpu to parse elapsed %=100*(parse time cpu/parse time elapsed).
                             也就是:解析实际运行时间/(解析实际运行时间+解析中等待资源时间),如果100%,表示没有任何等待.
10)%non-parse cpu:公式为: round(100*1-parse_cpu/total_cpu,2).如果这个值较小,表示解析消耗CPU时间过多.与
                          parse_cpu相比,如果total_cpu很高,这个比值将接近100%,这很好,说明计算机执行的大部分工作是执行查询工作,
                          而不是分析查询工作.





Shared Pool Statistics        Begin   End
                               ------  ------
             Memory Usage %:   32.87   33.12
    % SQL with executions>1:   80.00   82.69
  % Memory for SQL w/exec>1:   77.62   80.70
1)memory usage %:正在使用的共享池的percentage. 这个数字应长时间稳定在75%-90%,如果百分比太低,表明共享池设置过大,形成额外的管理
                  负担.从而导致某些条件下的性能slowdown.如果百分比太高,会使共享池外部的组件老化,如果SQL被再次执行,将使得
                  sql be hard parse.
2)% sql with executions >1:这是在共享池中有多少个执行次数大于一次的SQL 语句的度量,在一个趋于稳定的系统中,必须要注意这个
                           数字.在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。
                           在共享池中，在观察期间将有一组未被执行过的SQL语句，
                           这仅仅是因为要执行它们的语句在观察期间没有运行。
                           只有系统连续运行相同的SQL语句组，这个数字才会接近100%。
                           这里显示，在这个共享池中几乎有80%的SQL语句在14分钟的观察窗口中运行次数多于一次。
                           剩下的20%的语句可能已经在那里了--系统只是没有去执行
3)% memory for sql w/exec>1:这是与频繁使用的sql语句相比,频繁使用的sql语句消耗内存多少的一个度量,这个数字将在总体上与上面非
                             常接近,除非有某些查询任务消耗的内存没有规律,在稳定状态下,总体上会看到随着时间的推移大约有
                            75%-85%的共享池被使用,如果statspack报表的时间窗口足够大到cover所有的周期,执行次数大于一次
                            的sql语句的percentage应接近于100%,这是一个受观察之间 持续时间影响的统计数字.可以期望它随着
                             观察之间的时间长度增大而增大.

小结:通过oracle的实例有效性统计数据,我们可以获得大概的一个整体概念,然而我们并不能由此确定数据库运行的性能,当前性能问题,
     我们主要是依靠下面的等待事件来确认,我们可以这样理解两部分的内容，hit统计帮助我们发现和预测一些系统将要产生的性能问题，
     由此我们可以做到未雨绸缪。而wait事件，就是表明当前数据库已经出现了性能问题需要解决，所以是亡羊补牢的性质。
     接下来，开始查看wait事件。