statspack report分析(转)

statspack report分析(转)

一、statspack 输出结果中必须查看的十项内容

　　1、负载间档(Load profile)
　　2、实例效率点击率(Instance efficiency hit ratios)
　　3、首要的5个等待事件(Top 5 wait events)
　　4、等待事件(Wait events)
　　5、闩锁等待
　　6、首要的SQL(Top sql)
　　7、实例活动(Instance activity)
　　8、文件I/O(File I/O)
　　9、内存分配(Memory allocation)
　　10、缓冲区等待(Buffer waits)

二、输出结果解释

　　1、报表头信息
　　数据库实例相关信息，包括数据库名称、ID、版本号及主机等信息

　　STATSPACK report for
　DB Name 　　DB Id 　　Instance 　Inst Num 　Release 　Cluster 　Host
---------- 　--------- ---------- --------- --------- ------- ----------
　Allen 　　3874352951 　allen 　　　1 　　　9.2.0.4.0 　NO 　　ALLEN_WANG


　　　　　　Snap Id 　　Snap Time 　　Sessions 　Curs/Sess　 　Comment
　　　　　　------- ------------------ -------- 　---------　--------------
Begin Snap: 　36 　　　18-11月 -04 　　20:41:02 　　29 　　　　　19.2

End Snap: 　　37 　　　18-11月 -04 　　08:18:27 　　24 　　　　　15.7
Elapsed: 　　　　　　　　　　　　　　　697.42 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 　　　240M　　　　　　　Std Block Size: 　　8K
Shared Pool Size: 　96M 　　　　　　　Log Buffer: 　　　　512K

　　2、负载间档
　　该部分提供每秒和每个事物的统计信息，是监控系统吞吐量和负载变化的重要部分
Quote:

Load Profile
~~~~~~~~~~~~ 　　　　Per Second(秒) 　　　　　　Per Transaction事物
　　　　　　　　　　--------------- 　　　　　　　---------------
Redo size: 　　　　　　148.46 　　　　　　　　　　　3,702.15
Logical reads: 　　　　1,267.94 　　　　　　　　　　31,619.12
Block changes: 　　　　1.01 　　　　　　　　　　　　25.31
Physical reads:　　　　4.04 　　　　　　　　　　　　100.66
Physical writes: 　　　4.04 　　　　　　　　　　　　100.71
User calls:　　　　　　13.95　　　　　　　　　　　　347.77
Parses:　　　　　　　　4.98 　　　　　　　　　　　　124.15
Hard parses: 　　　　　0.02 　　　　　　　　　　　　0.54
Sorts: 　　　　　　　　1.33 　　　　　　　　　　　　33.25
Logons:　　　　　　　　0.00 　　　　　　　　　　　　0.02
Executes:　　　　　　　2.46 　　　　　　　　　　　　61.37
Transactions:　　　　　0.04
% Blocks changed per Read:　　0.08 　　　　　　Recursive Call %: 　30.38
Rollback per transaction %: 　0.42 　　　　　　Rows per Sort:　　　698.23

说明:
Redo size:每秒产生的日志大小(单位字节)，可标志数据变更频率, 数据库任务的繁重与否
Logical reads:平决每秒产生的逻辑读，单位是block
block changes:每秒block变化数量，数据库事物带来改变的块数量
Physical reads:平均每秒数据库从磁盘读取的block数
Physical writes:平均每秒数据库写磁盘的block数
User calls:每秒用户call次数
Parses: 每秒解析次数，近似反应每秒语句的执行次数, 软解析每秒超过300次意味着你的"应 用程序"效率不高，没有使用soft soft parse，调整session_cursor_cache
Hard parses:每秒产生的硬解析次数, 每秒超过100次，就可能说明你绑定使用的不好
Sorts:每秒产生的排序次数
Executes:每秒执行次数
Transactions:每秒产生的事务数，反映数据库任务繁重与否
Recursive Call %: 如果有很多PLSQL，那么他就会比较高
Rollback per transaction %:看回滚率是不是很高，因为回滚很耗资源

如果回滚率过高，可能说明你的数据库经历了太多的无效操作，过多的回滚可能还会带来Undo Block的竞争 该参数计算公式如下:

　　Round(User rollbacks / (user commits + user rollbacks) ,4)* 100%

　　3、实例命中率
　　该部分可以提前找出ORACLE潜在将要发生的性能问题，很重要

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
　　Buffer Nowait %: 　　　　　　100.00　　 Redo NoWait %:　　　100.00
　　Buffer Hit %:　　　　　　　　99.96　　　In-memory Sort %: 　99.14
　　Library Hit %: 　　　　　　　99.53　　　Soft Parse %: 　　　99.57
　　Execute to Parse %:　　　　　-102.31　　Latch Hit %:　　　　100.00
　　Parse CPU to Parse Elapsd %: 81.47　　　% Non-Parse CPU:　　96.46

说明:
　　Buffer Nowait %:在缓冲区中获取Buffer的未等待比率, Buffer Nowait<99%说明，有可能是有热, 块(查找x$bh的 tch和v$latch_children的cache buffers chains)
　　Redo NoWait %:在Redo缓冲区获取Buffer的未等待比率
　　Buffer Hit %:数据块在数据缓冲区中得命中率，通常应在90%以上，否则，需要调整, 小于 95%,重要的参数,小于90%可能是要加db_cache_size,但是大量的非选择的索引也会造成该值很高（大量的db file sequential read）
　　In-memory Sort %:在内存中的排序率
　　Library Hit %:主要代表sql在共享区的命中率，通常在95%以上，否，需要要考虑加大共享池，绑定变量，修改cursor_sharing等参数。
　　Soft Parse %:近似看作sql在共享区的命中率，小于<95%,需要考虑到绑定，如果低于80%，
那么就可能sql基本没有被重用
　　Execute to Parse %:sql语句解析后被重复执行的次数，如果过低，可以考虑设置
session_cached_cursors参数, 公式为100 * (1 - Parses/Executions) = Execute to Parse所以如果系统Parses > Executions,就可能出现该比率小于0的情况, 该值<0通常说明shared pool设置或效率存在问题造成反复解析，reparse可能较严重,或者可是同snapshot有关如果该值为负值或者极低,通常说明数据库性能存在问题
　　 Latch Hit %: Latch Hit<99%,要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数
　　Parse CPU to Parse Elapsd %:解析实际运行事件/(解析实际运行时间+解析中等待资源时间)越高越好
　　% Non-Parse CPU:查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过多。100*（parse time cpu / parse time elapsed）= Parse CPU to Parse Elapsd %

　　如果一个经常访问的列上的索引被删除，可能会造成buffer hit 显著的下降
　　如果增加了索引，但是他影响了ORACLE正确的选择表连接时的驱动顺序，那么可能会导致buffer hit 显 著增高
　　如果你的命中率变化幅度很大，说明你要改变SQL模式
Quote:

Shared Pool Statistics 　　　　　Begin 　　　　　End
　　　　　　　　　　　　　　　　------ 　　　　------
Memory Usage %:　　　　　　　　　33.79 　　　　57.02
% SQL with executions>1: 　　　　62.62 　　　　73.24
% Memory for SQL w/exec>1: 　　　64.55 　　　　78.72

　　Shared Pool相关统计数据
　　Memory Usage %:共享池内存使用率，应该稳定在70%-90%间，太小浪费内存，太大则内存不足。
　　% SQL with executions>1:执行次数大于1的sql比率，若太小可能是没有使用bind variables。
　　% Memory for SQL w/exec>1:也即是memory for sql with execution > 1:执行次数大于1的sql消耗内存/所有sql消耗的内存

　　4、首要等待事件

常见等待事件说明:
oracle等待事件是衡量oracle运行状况的重要依据及指示，主要有空闲等待事件和非空闲等待事件, TIMED_STATISTICS = TRUE 那么等待事件按等待的时间排序= FALSE那么事件按等待的数量排序.运行statspack期间必须session上设置TIMED_STATISTICS = TRUE.
　　空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。

　　比较影响性能常见等待事件

　　＊db file scattered read

　　该事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲区的缓存中。该指数的数量过大说明缺少索引或者限制了索引的使用(也可以调整optimizer_index_cost_adj) 。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。如果经常必须进行全表扫描,而且表比较小, 把该表存人keep池.如果是大表经常进行全表扫描,那么应该是olap系统,而不是oltp的.

　　＊db file sequential read

　　该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕，或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整, DB_CACHE_SIZE可以决定该事件出现的频率.

　　＊buffer busy wait

　　当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待.该值不应该大于1%,确认是不是由于热点块造成(如果是可以用反转索引,或者用更小块大小)

　　＊latch free

　　常跟应用没有很好的应用绑定有关. 闩锁是底层的队列机制(更加准确的名称应该是互斥机制)，用于保护系统全局区(SGA)共享内存结构闩锁用于防止对内存结构的并行访问。如果闩锁不可用，就会记录一次闩锁丢失。绝大多数得闩锁问题都与使用绑定变量失败(库缓存闩锁)、生成重作问题(重执行分配闩锁)、缓存的争用问题(缓存LRU链) 以及缓存的热数据宽块(缓存链)有关。当闩锁丢失率高于0.5%时，需要调整这个问题。

　　＊log buffer space

　　日志缓冲区写的速度快于LGWR写REDOFILE的速度,可以增大日志文件大小，增加日志缓冲区的大小，或者使用更快的磁盘来写数据。

　　＊logfile switch

　　通常是因为归档速度不够快,需要增大重做日志.

　　＊log file sync

　　当一个用户提交或回滚数据时，LGWR将会话得重做操作从日志缓冲区填充到日志文件中，用户的进程必须等待这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率, 为减少这个等待事件，须一次提交更多记录，或者将重做日志REDO LOG 文件访在不同的物理磁盘上。

　　Enqueue 最有可能是多个用户同时修改同一个块,如果没有空闲的ITL空间,就会出现数据库块级锁.

　　TOP SQL
　　调整首要的25个缓冲区读操作和首要的25个磁盘读操作做的查询,将可对系统性能产生5%到5000%的增益.

Instance Activity Stats for DB: CRMTEMP Instance: crmtemp Snaps: 3 -11

Statistic 　　　　　　　　　　　　　Total 　　per Second 　per
Trans
--------------------------------- ---------- ------------ --------
CPU used by this session 　　　　　291,318　　　98.1 　　　13.0
CPU used when call started 　　　　291,318　　　98.1 　　　13.0
CR blocks created　　　　　　　　　1,784　　　　0.6　　　　0.1
Cached Commit SCN referenced 　　　0　　　　　　0.0　　　　0.0

Commit SCN cached　　　　　　　　　0　　　　　　0.0　　　　0.0
DBWR buffers scanned 　　　　　　　985,112　　　331.6　　　44.0
DBWR checkpoint buffers written　　948　　　　　0.3　　　　0.0
DBWR checkpoints 　　　　　　　　　0　　　　　　0.0　　　　0.0
dirty buffers inspected　　　　　　483　　　　　0.2　　　　0.0 --脏缓冲的个数free buffer inspected　　　　　　　　　 8,154　　　　2.7　　　　0.4 --如果数量很大,说明
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 缓冲区过小
sorts (disk) 　　　　　　　　　　　0　　　　　　0.0　　　　0.0 --不应当大于1-5%
sorts (memory) 　　　　　　　　　　15,365 　　　5.2　　　　0.7
sorts (rows) 　　　　　　　　　　　1,445,018　　823.0　　　109.2
summed dirty queue length　　　　　24,667 　　　8.3　　　　1.1

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/66932/viewspace-916002/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/66932/viewspace-916002/