statspackreport分析.docx
《statspackreport分析.docx》由会员分享,可在线阅读,更多相关《statspackreport分析.docx(22页珍藏版)》请在冰豆网上搜索。
statspackreport分析
(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分析报告详解:
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
-------------------------------------------------------------
7.数据库后台进程发生的等待事件
Background Wait Events for DB:
BLISSDB Instance:
blissdb Snaps:
4 -5
-> ordered by wait time desc, waits desc (idle events last)
Avg
Total Wait wait Waits
Event Waits Timeouts Time (s) (ms) /txn
---------------------------- ------------ ---------- ---------- ------ --------
log file parallel write 2,439 2,012 26 11 97.6
db file parallel write 400 0 22 55 16.0
control file parallel write 406 0 5 13 16.2
control file sequential read 258 0 4 16 10.3
db file sequential read 19 0 1 51 0.8
log buffer space 24 0 0 9 1.0
log file sequential read 10 0 0 16 0.4
latch free 14 6 0 9 0.6
db file scattered read 6 0 0 14 0.2
direct path read 56 0 0 1 2.2
direct path write 56 0 0 1 2.2
LGWR wait for redo copy 8 0 0 1 0.3
log file single write 10 0 0 1 0.4
rdbms ipc message 7,339 3,337 3,172 432 293.6
pmon timer 373 373 1,083 2903 14.9
smon timer 3 3 924 ###### 0.1
-------------------------------------------------------------
8.TOP SQL
调整首要的25个缓冲区读操作和首要的25个磁盘读操作做的查询,将可对系统性能产生5%到5000%的增益。
SQL ordered by Gets for DB:
BLISSDB Instance:
blissdb Snaps