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


BLISSDB 4196236801 blissdb 1 9.2.0.4.0 NO BLISS


Snap Id Snap Time Sessions Curs/Sess Comment


Begin Snap: 4 23-6月 -05 17:43:32 10 3.3


End Snap: 5 23-6月 -05 18:01:32 12 6.1


Elapsed: 18.00 （mins）


Cache Sizes （end）


Buffer Cache: 24M Std Block Size: 8K


Shared Pool Size: 48M Log Buffer: 512K




2.负载间档


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


Load Profile


~~~~~~~~~~~~


Per Second Per Transaction


Redo size: 431,200.16 18,627,847.04z


Logical reads: 4,150.76 179,312.72


Block changes: 2,252.52 97,309.00


Physical reads: 23.93 1,033.56


Physical writes: 68.08 2,941.04


User calls: 0.96 41.36


Parses: 1.12 48.44


Hard parses: 0.04 1.92


Sorts: 0.77 33.28


Logons: 0.00 0.20


Executes: 2.36 102.12


Transactions: 0.02


Redo size：每秒产生的重做日志大小（单位字节），可标志数据变更频率， 数据库任务的繁重与否。本例中平均每秒产生了430K左右的重做，每个事务品均产生了18M


的重做。


Logical reads：平次每秒产生的逻辑读，单位是block。


block changes：每秒block变化数量，数据库事物带来改变的块数量。


Physical reads：平均每秒数据库从磁盘读取的block数。


Logical reads和Physical reads比较：大约有0.55%的逻辑读导致了物理I/O，平均每个事务执行了大约18万个逻辑读，在这个例子中，有一些大的事务被执行，因此很


高的读取数目是可以接受的。


Physical writes：平均每秒数据库写磁盘的block数。


User calls：每秒用户call次数。


Parses和Hard parses：每秒大约1.12个解析，其中有4%为硬解析，系统每25秒分析一些SQL，都还不错。对于优化好的系统，运行了好几天后，这一列应该达到0，所有


的sql在一段时间后都应该在共享池中。


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


Executes：每秒执行次数。


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


% Blocks changed per Read: 54.27 Recursive Call %: 86.94


Rollback per transaction %: 12.00 Rows per Sort: 32.59


% Blocks changed per Read：说明46%的逻辑读是用于那些只读的而不是可修改的块，该系统只更新54%的块。


Rollback per transaction %：事务回滚的百分比。计算公式为：Round（User rollbacks / （user commits + user rollbacks） ,4）* 100%。本例中每8.33个事务


导致一个回滚。如果回滚率过高，可能说明数据库经历了太多的无效操作。过多的回滚可能还会带来Undo Block的竞争。




3.实例命中率


该部分可以提前找出ORACLE潜在将要发生的性能问题，很重要。


Instance Efficiency Percentages （Target 100%）


~~~~~~~~~~~~~~~~~~~~


Buffer Nowait %: 100.00 Redo NoWait %: 100.00


Buffer Hit %: 99.42 In-memory Sort %: 100.00


Library Hit %: 98.11 Soft Parse %: 96.04


Execute to Parse %: 52.57 Latch Hit %: 100.00


Parse CPU to Parse Elapsd %: 11.40 % Non-Parse CPU: 99.55


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）。如果一个经常访问的列上的索引被删除，可能会造成buffer hit 显着下降。如果增加了索引，但是它影


响了ORACLE正确的选择表连接时的驱动顺序，那么可能会导致buffer hit 显着增高。如果命中率变化幅度很大，说明需要改变SQL模式。


In-memory Sort %：在内存中的排序率。


Library Hit %：主要代表sql在共享区的命中率，通常在95%以上，否则需要要考虑加大共享池，绑定变量，修改cursor_sharing等参数。


Soft Parse %：近似看作sql在共享区的命中率，小于<95%,需要考虑到绑定，如果低于80%，那么就可能sql基本没有被重用。


Execute to Parse %：一个语句执行和分析了多少次的度量。在一个分析，然后执行语句，且再也不在同一个会话中执行它的系统中，这个比值为0。计算公式为：


Execute to Parse =100 * （1 - Parses/Executions）。所以如果系统Parses > Executions，就可能出现该比率小于0的情况。本例中，对于每个分析来说大约执行了


2.1次。该值<0通常说明shared pool设置或效率存在问题，造成反复解析，reparse可能较严重，或者可是同snapshot有关，如果该值为负值或者极低，通常说明数据库


性能存在问题。


Latch Hit %：要确保>99%，否则存在严重的性能问题，比如绑定等会影响该参数。


Parse CPU to Parse Elapsd %：计算公式为：Parse CPU to Parse Elapsd %= 100*（parse time cpu / parse time elapsed）。即：解析实际运行时间/（解析实际


运行时间+解析中等待资源时间）。此处为11.4%，非常低，用于解析花费的每个CPU秒花费了大约8.77秒的wall clock时间，这说明花了很多时间等待一个资源。如果该


比率为100%，意味着CPU时间等于经过的时间，没有任何等待。


% Non-Parse CPU：计算公式为：% Non-Parse CPU =round（100*1-PARSE_CPU/TOT_CPU），2）。太低表示解析消耗时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这


个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。




4.Shared Pool相关统计数据


Shared Pool Statistics Begin End


------ ------


Memory Usage %: 60.45 62.42


% SQL with executions>1: 81.38 78.64


% Memory for SQL w/exec>1: 70.36 68.02


Memory Usage %：正在使用的共享池的百分率。这个数字应该长时间稳定在75%～90%。如果这个百分率太低，就浪费内存。如果这个百分率太高，会使共享池外部的组


件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内。


% SQL with executions>1：这是在共享池中有多少个执行次数大于一次的SQL语句的度量。在一个趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统


中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。在共享池中，在观察期间将有一组未被执行过的SQL语句，这仅仅是因为要执行它们的语句


在观察期间没有运行。只有系统连续运行相同的SQL语句组，这个数字才会接近100%。这里显示，在这个共享池中几乎有80%的SQL语句在18分钟的观察窗口中运行次数多


于一次。剩下的20%的语句可能已经在那里了--系统只是没有理由去执行它。


% Memory for SQL w/exec>1：这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多少的一个度量。这个数字将在总体上与% SQL with executions>1非常


接近，除非有某些查询任务消耗的内存没有规律。


在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。如果Statspack报表的时间窗口足够大到覆盖所有的周期，执行次数大于一次的SQL语句


的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。




5.首要等待事件


常见等待事件说明：


oracle等待事件是衡量oracle运行状况的重要依据及指示，主要有空闲等待事件和非空闲等待事件。


TIMED_STATISTICS：=TRUE，等待事件按等待的时间排序，= FALSE，等待事件按等待的数量排序。


运行statspack期间必须session上设置TIMED_STATISTICS = TRUE。


空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行


过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。


Top 5 Timed Events


~~~~~~~~~~~~~~~~~~ % Total


Event Waits Time （s） Ela Time


-------------------------------------------- ------------ ----------- --------


db file sequential read 22,154 259 62.14


CPU time 49 11.67


log file parallel write 2,439 26 6.30


db file parallel write 400 22 5.32


SQL*Net message from dblink 4,575 15 3.71


-------------------------------------------------------------


这里是比其他任何事件都能使速度减慢的事件。比较影响性能的常见等待事件：


db file scattered read：该事件通常与全表扫描有关。因为全表扫描是被放入内存中进行的进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散布在缓冲


区的缓存中。该指数的数量过大说明缺少索引或者限制了索引的使用（也可以调整optimizer_index_cost_adj）。这种情况也可能是正常的，因为执行全表扫描可能比


索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。如果经常必须进行全表扫描，而且表比较小，把该表存人keep池。如果


是大表经常进行全表扫描，那么应该是OLAP系统，而不是OLTP的。


db file sequential read：该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺序很糟糕，或者使用了非选择性索引。通过将这种等待与statspack


报表中已知其它问题联系起来（如效率不高的sql），通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整， DB_CACHE_SIZE可以决定该事件出现的频率


。


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文件访在不同的


物理磁盘上。


Wait time: 等待时间包括日志缓冲的写入和发送操作。




6.数据库用户程序发生的所有等待事件


Wait Events for DB: BLISSDB Instance: blissdb Snaps: 4 -5


-> s - second


-> cs - centisecond - 100th of a second


-> ms - millisecond - 1000th of a second


-> us - microsecond - 1000000th of a second


-> ordered by wait time desc, waits desc （idle events last）


Avg


Total Wait wait Waits


Event Waits Timeouts Time （s） （ms） /txn


---------------------------- ------------ ---------- ---------- ------ --------


db file sequential read 22,154 0 259 12 886.2


log file parallel write 2,439 2,012 26 11 97.6


db file parallel write 400 0 22 55 16.0


SQL*Net message from dblink 4,575 0 15 3 183.0


SQL*Net more data from dblin 64,490 0 13 0 2,579.6


control file parallel write 416 0 5 13 16.6


db file scattered read 456 0 5 11 18.2


write complete waits 9 0 5 568 0.4


control file sequential read 370 0 5 13 14.8


log buffer space 126 0 4 34 5.0


free buffer waits 11 1 3 313 0.4


log file switch completion 13 0 2 188 0.5


log file sync 90 0 1 8 3.6


log file sequential read 10 0 0 16 0.4


latch free 17 6 0 8 0.7


direct path read 56 0 0 1 2.2


direct path write 56 0 0 1 2.2


SQL*Net more data to client 173 0 0 0 6.9


SQL*Net message to dblink 4,575 0 0 0 183.0


LGWR wait for redo copy 8 0 0 1 0.3


log file single write 10 0 0 1 0.4


db file single write 5 0 0 0 0.2


SQL*Net break/reset to clien 5 0 0 0 0.2


async disk IO 15 0 0 0 0.6


SQL*Net message from client 789 0 3,290 4170 31.6


virtual circuit status 36 36 1,082 30069 1.4


wakeup time manager 34 34 1,034 30403 1.4


SQL*Net message to client 791 0 0 0 31.6


SQL*Net more data from clien 30 0 0 0 1.2


-------------------------------------------------------------


oracle视频教程请关注:http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html