oracle 优化-解读statspack

今天看了《statspack_tuning_otn_new.pdf》,主要学习到了一些top event的产生原因和解决办法。

The Load Profile:
一般用户数据库主机的负载量

Instance Efficiency
不同的应用可以接受不同的实例状态,如在DSS环境中,In-memory Sort可以比较低,但是在OLTP中,In-memory Sort比较低是不可接受的。

Top 5 event:
db file scattered read/db file sequential read:
原因:scattered read由于(并发的)全表扫描引起(数据分布连续,读的块是连续的块,每次读取的块有参数db_file_multiblock_read_count决定),发生scattered read;
sequential read由于索引扫描引起(数据分布不连续,读的块是分散的块),一般是多表连接顺序不合理,发生sequential read
解决:检查表空间的读写速度,对比系统的磁盘读写速度
检查是否有消耗大量IO的SQL(ordered by Reads|ordered by Gets),建立合适的索引。
分散存储

latch free:
原因:服务要求得到latch但是没有latch可用
解决:查看Latch-specific找到最大争用的latch

enqueue:
原因:资源锁,共享资源的处理处于队列处理(FIFO,先进先出)机制
解决:查看Enqueue Statistics哪个是最高争用的enqueue。

free buffer waits:
原因:buffer cache较小,free buffer不够用;
DBWR写的速度不够快
解决:增大buffer cache
检查系统IO情况,是否存在IO瓶颈影响DBWR过慢,使用多个DBWR进程。

buffer busy wait:
原因:buffer正在装入到缓存,或者buffer已经装入到缓存但是处于不可共享的状态
解决:查看Buffer Wait Statistics,并且查看Tablespace and File IO,合并二者,观察是否有segment的争用。

write complete waits:
原因:当服务器进程要使用一个block的时候,这个block正在被DBWR写入到磁盘。
buffer cache过小
DBWR写入过慢
大量的进程用到indexed Buffer Gets
发生了checkpoint
解决:增大buffer cache
检查DBWR是否存在IO瓶颈
检查SQL section ordered by Buffer Gets是否有大量SQL 使用了非必要的索引占用了buffer cache空间。

ps:回过头来再次对比看了看eygle写的《statspack使用指南-v3[1].0.pdf》,理解更加深刻了些。呵呵,有些东西,确实要碰到了才会理解更加深刻。

相关文章

一条评论

  1. db_file_multiblock_read_count这个是否需要设置要看你系统的工作量统计信息是否收集,那么在Oracle 10g中,是CPU Cost Model那么系统非工作量的统计信息是默认存在的,这个参数会在计算IO Cost用到,但是如果你收集了workload的统计信息的话,那么系统就会找MBRC了来计算IO Cost了。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据