 这篇文章来自于oracle中国用户组(www.oracle.com.cn)的文章，发现对自己学习性能调优很有帮助: 原文链接:http://www.cnoug.org/viewthread.php?tid=25353 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、版本号及主机等信息 quote:statspack report for db name db id instance inst num release cluster host ------------ ----------- ------------ -------- ----------- ------- ------------ pormals 3874352951 pormals 1 9.2.0.4.0 no njlt-server1 snap id snap time sessions curs/sess comment ------- ------------------ -------- --------- ------------------- begin snap: 36 18-7月 -04 20:41:02 29 19.2 end snap: 37 19-7月 -04 08:18:27 24 15.7 elapsed: 697.42 (mins) cache sizes (end) ~~~~~~~~~~~~~~~~~ buffer cache: 240m std block size: 8k shared pool size: 96m log buffer: 512k 2、负载间档 该部分提供每秒和每个事物的统计信息，是监控系统吞吐量和负载变化的重要部分 quote:load profile ~~~~~~~~~~~~ per second(秒) per transaction事物 --------------- --------------- redo size: 148.46 3,702.15 logical reads: 1,267.94 31,619.12 block changes: 1.01 25.31 physical reads: 4.04 100.66 physical writes: 4.04 100.71 user calls: 13.95 347.77 parses: 4.98 124.15 hard parses: 0.02 0.54 sorts: 1.33 33.25 logons: 0.00 0.02 executes: 2.46 61.37 transactions: 0.04 % blocks changed per read: 0.08 recursive call %: 30.38 rollback per transaction %: 0.42 rows per sort: 698.23 说明: 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:每秒产生的硬解析次数 sorts:每秒产生的排序次数 executes:每秒执行次数 transactions:每秒产生的事务数，反映数据库任务繁重和否 3、实例命中率 该部分能够提前找出oracle潜在将要发生的性能问题，很重要 quote:instance efficiency percentages (target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ buffer nowait %: 100.00 redo nowait %: 100.00 buffer hit %: 99.96 in-memory sort %: 99.14 library hit %: 99.53 soft parse %: 99.57 execute to parse %: -102.31 latch hit %: 100.00 parse cpu to parse elapsd %: 81.47 % non-parse cpu: 96.46 说明: 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解析时间)，太低表示解析消耗时间过多。 quote:shared pool statistics begin end ------ ------ memory usage %: 33.79 57.02 % sql with executions>1: 62.62 73.24 % memory for sql w/exec>1: 64.55 78.72 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%,确认 是不是由于热点块造成(假如是能够用反转索引,或用更小块大小) latch free 闩锁是底层的队列机制(更加准确的名称应该是互斥机制)，用于保护系统全局区(sga)共享内存结构 。闩锁用于防止对内存结构的并行访问。假如闩锁不可用，就会记录一次闩锁丢失。绝大多数得闩锁问题 都和使用绑定变量失败(库缓存闩锁)、生成重作问题(重执行分配闩锁)、缓存的争用问题(缓存lru链) 以 及缓存的热数据宽块(缓存链)有关。当闩锁丢失率高于0.5%时，需要调整这个问题。 log buffer space 日志缓冲区写的速度快于lgwr写redofile的速度,能够增大日志文档大小，增加日志缓冲区的大小，或 者使用更快的磁盘来写数据。 logfile switch 通常是因为归档速度不够快,需要增大重做日志 log file sync 当一个用户提交或回滚数据时，lgwr将会话得重做操作从日志缓冲区填充到日志文档中，用户的进程 必须等待这个填充工作完成。为减少这个等待事件，须一次提交更多记录，或将重做日志redo log 文档 访在不同的物理磁盘上。 |
喜欢本文，那就收藏到： |
.text:''):(d.getSelection?d.getSelection():'');void(keyit=window.open('http://my.poco.cn/fav/storeIt.php?t='+escape(d.title)+'&u='+escape(d.location.href)+'&c='+escape(t)+'&img=http://www.h-strong.com/blog/logo.gif','keyit','scrollbars=no,width=475,height=575,status=no,resizable=yes'));keyit.focus(); "添加到POCO网摘"){kind=logo}
Rss Feed
