Statspack分析报告详解
(1) 调整的先后次序 
1. Tune the design. -- Application designers 
2. Tune the application. -- Application developers 
3. Tune memory. 
4. Tune I/O. 
5. Tune contention. 
6. Tune the operating system. 

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%以上，否则需要要