statspack的分析注解

 STATSPACK report for

DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------
XXXXX 4038912792 XXXXX 1 9.2.0.5.0 NO localhost.lo
caldomain

--基本数据库信息
Snap Id Snap Time Sessions Curs/Sess Comment
------- ------------------ -------- --------- -------------------
Begin Snap: 502 14-Jul-05 10:33:12 213 #########
End Snap: 503 14-Jul-05 11:03:15 199 #########
Elapsed: 30.05 (mins)
--采样的时间跟当时的进程数量
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 512M Std Block Size: 8K
Shared Pool Size: 208M Log Buffer: 512K
--一些内存缓冲的信息
Cache Sizes (end)
~~~~~~~~~~~~~~~~~

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 96,066.23 1,712.16 --每秒数据库产生的REDO日志大小（单位字节），可以表示数据库任务的繁重程度，平均每个事务产生的日志量
Logical reads: 6,108.98 108.88 --平均每秒产生的逻辑读，单位BLOCK。每个事物产生的逻辑读。
Block changes: 529.79 9.44 --每秒BLOCK变化数量，数据库事务带来的块改变。
Physical reads: 242.22 4.32 --物理读取BLOCK
Physical writes: 25.78 0.46 --物理写BLOCK
User calls: 983.59 17.53 --用户调用次数
Parses: 514.48 9.17 --解析（硬和软）
Hard parses: 84.75 1.51 --硬解析次数
Sorts: 212.63 3.79--排序次数
Logons: 22.46 0.40
Executes: 522.29 9.31 --每秒执行次数
Transactions: 56.11 --事务数

% Blocks changed per Read: 8.67 发生变化的块数/读次数，变化的块需要从回滚段来数据
Recursive Call %: 64.57 递归操作占所有操作的比率
Rollback per transaction %: 0.00 事务回滚率（回滚开销很大）
Rows per Sort: 7.44

 

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 --在缓冲区中获取buffer 的未等待比率
Redo NoWait %: 100.00 --写日志的不等待比率,太低可调整log_buffer(增加)和 _log_io_size
Buffer Hit %: 96.04--数据块在数据缓冲区中的命中率，通常应该在90%以上，否则虑加大 db_block_buffers
In-memory Sort %: 100.00 --如果过低说明有大量的排序在临时表空间中进行，可尝试增加sort_area_size
Library Hit %: 93.95 主要代表着sql在共享区的命中率，通常在98%以上
Soft Parse %: 83.53近似当作sql在共享区的命中率，通常高代表使用了绑定变量,太低需要调整应用使用绑定变量，或者参考 cursor_sharing = force (9i 中增加了 similar )
Execute to Parse %: 1.49该值越高表示一次解析后被重复执行的次数越多，如果过低可以考虑设session_cached_cursors > 0
Latch Hit %: 98.72 内部结构维护锁命中率，高于99%,通常低是因为shared_pool_size过大和没有使用绑定变量导致硬解析过多，可参考 _spin_count 参数设置
Parse CPU to Parse Elapsd %: 70.36 解析实际所用时间/(解析实际所用时间+解析中等待资源时间),越高越好
% Non-Parse CPU: 69.19 查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过长

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 89.01 83.73
% SQL with executions>1: 18.10 9.87执行次数大于1的sql的比率（若太小可能是没有使用绑定变量）
% Memory for SQL w/exec>1: 16.63 10.44执行次数大于1的sql消耗内存/(所有sql消耗内存)

Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
CPU time 2,572 50.66
log file sync 101,599 677 13.34 --等待提交COMMIT的完成
db file sequential read 57,078 443 8.73
SQL*Net more data to client 68,846 381 7.50
latch free 150,031 319 6.28 --没有使用绑定变量，导致过多的硬解析

 

 

1、考虑把对于必须全表扫描的大表可以考虑recycle buffer ,对于频繁进行全表扫描的小表可以考虑keep buffer。

瓶颈：
系统中有大量跟日志有关的等待
LOG FILE SYNC （占系统总等待的13.34%）
LGWR wait on LNS
LGWR-LNS wait on channel
LNS wait on SENDREQ
跟业务逻辑有关，为了保证事务的成功率，所以必须每插入一条数据或者UPDATE一条数据都得COMMIT一次，这个库做了STANDBY，所以
LGWR wait on LNS
LGWR-LNS wait on channel
LNS wait on SENDREQ
等待也许跟standby有关。

及latch free （占6.28%）
LATCH FREE等待导致如下结果：
Library Hit %: 93.95 命中率比较底（一般98%以上）
Soft Parse %: 83.53
Execute to Parse %: 1.49 该值越高表示一次解析后被重复执行的次数越多，如果过低可以考虑设session_cached_cursors > 0
Latch Hit %: 98.72 内部结构维护锁命中率，高于99%,通常低是因为shared_pool_size过大和没有使用绑定变量导致硬解析过多，可参考 _spin_count 参数设置
Parse CPU to Parse Elapsd %: 70.36 解析实际所用时间/(解析实际所用时间+解析中等待资源时间),越高越好
% Non-Parse CPU: 69.19 查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过长

这些都是由于系统中没有使用绑定变量，导致SQL语句不能共享。导致过多的硬解析及LATCH的竞争。
调整：
为了减低硬解析，降低LATCH 的竞争，考虑使用CURSOR_SHARING= similar
考虑增加：session_cached_cursors > 0

考虑_spin_count 参数的使用。

对于LOG FILE SYNC等待没有太多的办法，系统中的COMMIT太过于频繁，只有使用批量提交，该等待才会降低。