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太过于频繁,只有使用批量提交,该等待才会降低。