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》，理解更加深刻了些。呵呵，有些东西，确实要碰到了才会理解更加深刻。