Statspack Report Read Info

Statspack Report Read Info[@more@]

一、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)

2、负载间档
该部分提供每秒和每个事务的统计信息,是监控系统吞吐量和负载变化的重要部分
说明:
Redo size:每秒产生的日志大小(单位字节),可标志数据库任务的繁重与否
Logical reads:平决每秒产生的逻辑读,单位是block
block changes:每秒block变化数量,数据库事务带来改变的块数量
Physical reads:平均每秒数据库从磁盘读取的block数
Physical writes:平均每秒数据库写磁盘的block数
User calls:每秒用户call次数
Parses:每秒解析次数,近似反应每秒语句的执行次数
软解析每秒超过300次意味着你的"应用程序"效
率不高,调整session_cursor_cache
Hard parses:每秒产生的硬解析次数
Sorts:每秒产生的排序次数
Executes:每秒执行次数
Transactions:每秒产生的事务数,反映数据库任务繁重与否

3、实例命中率
该部分可以提前找出ORACLE潜在将要发生的性能问题,很重要
说明:
Buffer Nowait %:在缓冲区中获取Buffer的未等待比率
Redo NoWait %:在Redo缓冲区获取Buffer的未等待比率
Buffer Hit %:数据块在数据缓冲区中得命中率,通常应在90%以上,否则,需要调整
In-memory Sort %:在内存中的排序率
Library Hit %:主要代表sql在共享区的命中率,通常在95%以上,否,需要要考虑加大共享池,绑定变量,修改cursor_sharing等参数。
Soft Parse %:近似看作sql在共享区的命中率,小于<95%,需要考虑到绑定,如果低于80%,那么就可能sql基本没有被重用
Execute to Parse %:sql语句解析后被重复执行的次数,如果过低,可以考虑设置session_cached_cursors参数
Parse CPU to Parse Elapsd %:解析实际运行事件/(解析实际运行时间+解析中等待资源时间) 越高越好
% Non-Parse CPU:查询实际运行时间/(查询实际运行时间+sql解析时间),太低表示解析消耗时间过多。

Shared Pool相关统计数据
Memory Usage %:共享池内存使用率,应该稳定在75%-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、首要等待事件
常见等待事件说明:
oracle等待事件是衡量oracle运行状况的重要依据及指示,主要有空闲等待事件和非空闲等待事件;空闲等待事件是oracle正等待某种工作,在诊断和优化数据库时候,不用过多注意这部分事件,非空闲等待事件专门针对oracle的活动,指数据库任务或应用程序运行过程中发生的等待,这些等待事件是我们在调整数据库应该关注的。

db file scattered read
该事件通常与全表扫描有关。因为全表扫描是被放入内存中执行的,通常情况下它不可能被放入连续的缓冲区中,所以就散布在缓冲区的缓存中。该值的数量过大说明缺少索引或者限制使用索引。这种情况也可能是正常的,因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时,需要通过检查来确定全表扫描是否必需调整。可以尝试将较小的表放入缓存keep中,避免反复读取它们。

db file sequential read
该事件说明在单个数据块上大量等待,该值过高通常是由于表间连接顺序很糟糕,或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的,并确保多表连接的连接顺序来调整。

buffer busy wait
当缓冲区以一种非共享方式或者正在被读入到缓冲时,就会出现该等待.该值不应该大于1%,确认是不是由于热点块造成(如果是可以用反转索引,或者用更小的blocksize)

latch free
闩锁是底层的队列机制(更加准确的名称应该是互斥机制),用于保护系统全局区(SGA)共享内存结构。闩锁用于防止对内存结构的并行访问。如果闩锁不可用,就会记录一次闩锁丢失。绝大多数闩锁问题都与使用绑定变量失败(库缓存闩锁)、生成redo问题(redo分配闩锁)、缓存的争用问题(缓存LRU链)以及缓存的热数据宽块(缓存链)有关。当闩锁丢失率高于0.5%时,需要调整这个问题。

log buffer space
日志缓冲区写的速度快于LGWR写logfile的速度,可以增大日志文件大小,增加日志缓冲区的大小,或者使用更快的磁盘来写数据。

logfile switch
通常是因为归档速度不够快,需要增大重做日志

log file sync
当一个用户提交或回滚数据时,LGWR将会话的重做操作从日志缓冲区写到日志文件中,用户的进程必须等待这个写操作完成。为减少这个等待事件,须一次提交更多记录,或者将重做日志REDO LOG 文件访在不同的物理磁盘上.

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/21102096/viewspace-1019105/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/21102096/viewspace-1019105/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值