ORACLE STATSPACK REPORT输出结果解释

2、负载间档该部分提供每秒和每个事物的统计信息，是监控系统吞吐量和负载变化的重要部分
Load Profile
~~~~~~~~~~~~                            Per Second       Per Transaction
                                          ---------------       ---------------
                  Redo size:              2,184.89            217,032.00
               Logical reads:                 31.99              3,178.00
              Block changes:                 10.09              1,002.33
              Physical reads:                  0.00                  0.00
             Physical writes:                  0.07                  6.67
                 User calls:                  0.06                  6.00
                    Parses:                  0.80                 79.00
                Hard parses:                  0.02                  1.67
                     Sorts:                  0.42                 42.00
                    Logons:                  0.01                 1.33
                  Executes:                  1.56                154.67
               Transactions:                  0.01
 
 % Blocks changed per Read:   31.54    Recursive Call %:                     98.11
  Rollback per transaction %:    0.00      Rows per Sort:                    73.82
 
说明:
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   %:  100.00   
In-memory Sort %:  100.00
            Library Hit   %:   99.15       
Soft Parse %:   97.89
          Execute to Parse %:   48.92        
Latch Hit %: 100.00
Parse CPU to Parse Elapsd %:             %
Non-Parse CPU:   100.00
说明:
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有关如果该值为负值或者极低,通常说明数据库性能存在问题
Execute to Parse %: 这个数字也应该是越大越好，接近100%最好。有些报告中这个值是负的，看上去很奇怪。事实上这表示一个问题，sql如

果被age out的话就可能出现这种情况，也就是sql老化，或执行alter system flush shared_pool等。

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 %
 
Shared Pool Statistics          Begin   End
                               ------ ------
       Memory Usage %:     63.65   63.75
 % SQL with executions>1:   63.73   64.12
% Memory for SQL w/exec>1:  59.93   60.33
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．首要的5个等待事件(Top 5 wait events)，是整个报告中最能反映问题的一部分
主要有两种类别的等待事件，即空闲（idle）等待事件和非空闲（non-idle）等待事件。
空闲事件指Oracle 正等待某种工作,在诊断和优化数据库的时候,我们不用过多注意这部分事件。
常见的空闲事件有:
? dispatcher timer
? lock element cleanup
? Null event
? parallel query dequeue wait
? parallel query idle wait - Slaves
? pipe get
? PL/SQL lock timer
? pmon timer- pmon
? rdbms ipc message
? slave wait
? smon timer
? SQL.Net break/reset to client
? SQL.Net message from client
? SQL.Net message to client
? SQL.Net more data to client
? virtual circuit status
? client message

非空闲等待事件专门针对Oracle 的活动,指数据库任务或应用运行过程中发生的等待，这些等待事件是我们在调整数据库的时候应该关注与研

究的。
一些常见的非空闲等待事件有:
? db file scattered read(表示可能太多全表扫描多)
? db file sequential read（表示可能太多索引多）
? buffer busy waits
? free buffer waits
? enqueue
? latch free
? log file parallel write
? log file sync

运行statspack期间必须session上设置TIMED_STATISTICS = TRUE.（推荐）
常见的等待事件以及可能的解决方法
1.      DB File Scattered Read (表示可能太多全表扫描多)–-通常与全表扫描有关，需要确认是否真的需要全表扫描，能否改用索引或者把把较小的表整个的放入内存缓冲区中，避免反复磁盘读取
被分散的放在不连续的内存块中，因为一次读进来的是多于一个block的。
通常来说我们可以认为是全表扫描类型的读，因为根据索引读表数据的话一次只读一个block，如果这个数字过大，就表明该表找不到索引，或

者只能找到有限的索引，可能是全表扫描过多，需要检查sql是否合理的利用了索引，或者是否需要建立合理的索引。
当全表扫描被限制在内存时，它们很少会进入连续的缓冲区内，而是分散于整个缓冲存储器中。尽管在特定条件下执行全表扫描可能比索引扫

描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要,是否可以通过建立合适的索引来减少对于大表全表扫描所产生的大规

模数据读取。
对于经常使用的小表，应该尽量把他们pin 在内存中，避免不必要的老化清除及重复读取。

2.       DB File Sequential Read （表示可能太多索引多）–表明有很多索引读，需要你调整代码，特别是表连接部分，适当的调整DB_CACHE_SIZE的值
DB文件连续读取。通常显示单个块的读取(通常指索引读取)，表示的是读进磁盘的block被放在连续的内存块中。
事实上大部分基本代表着单个block的读入，可以说象征着 IO 或者说通过索引读入的比较多。因为一次IO若读进多个的block，放入连续的内

存块的几率是很小的，分布在不同block的大量记录被读入就会遇到此事件。因为根据索引读数据的话，假设100条记录，根据索引，不算索引

本身的读，而根据索引每个值去读一下表数据，理论上最多可能产生100 buffer gets，而如果是full table scan，则100条数据完全可能在一

个block里面，则几乎一次就读过这个block了，就会产生这么大的差异。
这种等待的数目很多时，可能显示表的连接顺序不佳，或者不加选择地进行索引。
对于高级事务处理（high-transaction）、调整良好（welltuned）的系统，这一数值很大是很正常的，但在某些情况下，它可能暗示着系统中

存在问题。
你应当将这一等待统计量与Statspack 报告中的已知问题（如效率较低的SQL）联系起来。检查索引扫描，以保证每个扫描都是必要的，并检查

多表连接的连接顺序。

3.       Free Buffer –没有可用的内存缓冲区而等待，增大DB_CACHE_SIZE,加速检查点和调整代码
4.       Buffer Busy Wait -–段头出现问题，增加freelists或者freelist maxtrans
--数据块问题，分离‘热点’数据，采用反向关键字索引，采用小的数据块，增大initrans和maxtrans
--undo header问题，增加回滚段
--undo block问题，增加提交频率，增大回滚段
5.       Latch Free
--library Cache问题，使用绑定变量，调整shared_pool_size
--shared pool问题，使用绑定变量，调整shared_pool_size
--redo Allocation,,最小化redo生成并避免不必要的提交
--redo Copy, 增大_log_simultaneous_copies
--Row Cache Object,增大共享池
--Cache Buffers Chain,_Db_block_Hash_Buckers应被增大或变为质数
--Cache Buffers LRU Chain,设置DB_BLOCK_LRU_LACHES或者使用多个缓冲区池
6.        Enqueue –ST --使用本地表空间或者预先分配大扩展
7.        Enqueue –HW 预先分配扩展与高水位线之上
8.        Enqueue –TX4 增大表或者索引的initrans和maxtrans
9.        Enqueue –TM 为外键建立索引，查看应用程序的表锁
10.     Log Buffer Space 增大日志缓冲区，重做日志放在快速磁盘上
11.     Log File Switch    归档设备太慢或者太满，增加或者扩大重做日志
12.     Log File Sync     每次提交更多记录，更快的存放重做日志的磁盘，裸设备
13.     idle event     其他的一些等待事件可以忽略
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~                                                   % Total
Event                                               Waits    Time (s)   Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time                                                            0    52.79
control file parallel write                                  97           0    26.72
control file sequential read                                52           0    11.55
log file parallel write                                     113           0     6.99
log file sync                                              1           0      .96
          -------------------------------------------------------------
 
5．等待事件(Wait events)的具体数据
Wait Events for DB: COLM Instance: colm Snaps: 3 -4
-> 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)
           -------------------------------------------------------------
6.SQL语句
SQL ordered by Gets for DB: COLM Instance: colm Snaps: 3 -4
-> End Buffer Gets Threshold:   10000
-> Note that resources reported for PL/SQL includes the resources used by
   all SQL statements called within the PL/SQL code. As individual SQL
   statements are also reported, it is possible and valid for the summed
   total % to exceed 100
 
7.实例活动(Instance activity)
Instance Activity Stats for DB: COLM Instance: colm Snaps: 3 -4
 
Statistic                                      Total     per Second    per Trans
0.0          1.0
workarea executions - optimal                     89            0.3         29.7
          -------------------------------------------------------------
 
7.表空间IO
Tablespace IO Stats for DB: COLM Instance: colm Snaps: 3 -4
->ordered by IOs (Reads + Writes) desc
 
8．文件I/O(File I/O)
File IO Stats for DB: COLM Instance: colm Snaps: 3 -4
->ordered by Tablespace, File
 
--其余的一些收集信息
9. Buffer Pool Statistics for DB
10. Instance Recovery Stats for DB
11. Buffer Pool Advisory for DB
12. PGA Aggr Target Stats for DB
13. Rollback Segment Stats for DB
14. Rollback Segment Storage for DB
15. Latch Activity for DB --比较重要的信息
16.Dictionary Cache Stats for DB
17.Shared Pool Advisory for DB
Shared Pool Advisory for DB: COLM Instance: colm End Snap: 4
-> Note there is often a 1:Many correlation between a single logical object
   in the Library Cache, and the physical number of memory objects associated
   with it. Therefore comparing the number of Lib Cache objects (e.g. in
   v$librarycache), with the number of Lib Cache Memory Objects is invalid
 
                                                          Estd
Shared Pool    SP       Estd         Estd     Estd Lib LC Time
   Size for Size Lib Cache    Lib Cache   Cache Time   Saved Estd Lib Cache
 Estim (M) Factr   Size (M)      Mem Obj    Saved (s)   Factr    Mem Obj Hits
18. SGA Memory Summary for DB
SGA Memory Summary for DB: COLM Instance: colm Snaps: 3 -4 
SGA regions                       Size in Bytes
------------------------------ ----------------
Database Buffers                     92,274,688
Fixed Size                              453,352
Redo Buffers                            667,648
Variable Size                       117,440,512
sum                                 210,836,200