第5 章、解释常见的与I/O 有关的等待事件
1. Db file sequential read 等待事件：
1) 根据索引的顺序读取：
l optimizer_index_cost_adj 和optimizer_index_caching 参数可能导致优化器错误的选择索引扫描，相关session 的优化器设置可以在视图v$ses_optimizer_env 中查看。
l 在分析表和索引的统计信息时，如果estimate 的值比较低，那么Oracle 一般会采用单块读，这是会产生db file sequential read 等待事件。
2) 根据表的顺序读取：
通过从索引中获得的rowid 开访问表时使用单块I/O。
3) 系统级诊断：
系统级的斩断提供的统计功能非常有限，必须确保I/O 子系统中热点的问题，确保数据库安装点只有Oracle 软件，磁盘数据文件的分布情况等，可从v$filestat 查看数据文件单块读取相关的统计信息。
2. Db file scattered read 等待事件：
l 可导致优化器选择全表扫描的初始化参数：db_file_multiblock_read_count （MBRC ）、hash_area_size 、optimizer_index_cost_adj 。
l 当分析带有compute 参数时，Oracle 执行全表扫描，并添加v$session_event 和v$system_event 视图的db file scattered read 统计数据。
l Db file sequential read 出现在db_file scattered read 之后的原因：
1) 区边界：如果一个区的最后一组块中只有一个块的时候，Oracle 就使用单块读取该块。
2) 例如一个区中有9 个块，MBRC=8 ，那么第一次读取8 块，第二次是1块，以此类推。在这种情况下，需要构建较大的区大小来增加全表扫描的效率。
3) 高速缓存块：即读取时遇到某个块在高速缓存中，使用单块读，这没有问题。
4) 链接的或迁移的行：Oracle 使用单块读来寻求每个链接或迁移的行。
5) 索引条目的创建：向具有索引的表中插入数据时，可能遇到此类事件，这没有问题。
l 多块读取中读取的块数少于MBRC 的原因：
1) 受区大小影响，Oracle 每次多块读取都必须是在一个区间内，不能跨区读取。
2) 受已缓存块的影响，如果在一次多块读中的块号不能连续，即中间有块已经被缓存了，那么就分成多次多块读。
l MBRC 的设置收到多重的限制，你可以将MBRC 设置为一个巨大的值，但是永远也不会达到此值。
3. Direct path read 等待事件：
l 直接读取可能按照同步和异步的方式执行，取决于参数disk_asynch_io ，使用异步IO时的系统级direct path read 可能不准确。
l 执行并行查询的SQL 语句不会再direct path read 上等待，会在PX Deq 上等待（execute reply 等待事件），如果是由于SQL 函数的驱动，则有可能在父会话中出现direct path read 等待。
l 由于并行查询和Oracle 计数等待事件的方式等原因，不应该根据v$session_event 来估计direct path read 等待事件，而是应该从v$sesstat 中查看physical reads direct （此统计中包含了并行查询中子进程的直接读数据），但是这样的方式缺点就是没有时间元素。
l Db_file_direct_io_count 参数可能影响direct path read 的性能，该参数是一个隐藏参数，控制着直接读的I/O 缓冲区大小，直接读取的大小限制，还可以从此事件的P3 参数看出来。
4. Direct path write 等待事件：
l 基本上与直接读相同，如果直接写的时临时文件，那么降低了直接写也就是等于降低了直接读。
5. Db file parallel write 等待事件：
l 该事件只属于DBWR 进程，即使没有经db file parallel write 等待事件，也有可能受到此事件的影响，缓慢的DBWR 可能造成前台会话在write complete wait 或free buffer waits 上的等待，所以查看时，应该综合这三个事件来看待问题。
l 如果将disk_asynch_io 设为false，则有可能在实例中看不到此等待，但只是看不到而已，还是会受到影响的。
6. Log file parallel write 等待事件：
l 该事件只属于LGWR 进程，LGWR 写日志的时机有：每隔3s、提交会回滚一个事务、满足_log_io_size 值、log buffer 中有1M 的重做项时。
l 即使用户没有经历log file parallel write 事件，但是也有可能受到影响，缓慢的LGWR 可能导致log file sync 事件的出现，导致用户提交或回滚被挂起，直到LGWR 写入完成，在查看时，也需要综合这两个事件来看。
l 如果该事件的平均等待时间大于1cs （10ms ），则说明I/O 吞吐量缓慢。
l 使用nologging 方式创建的对象时不可恢复的，除非在破坏之前有备份，在nologging 时省下的I/O 将会花在备份上，以force logging 方式工作的数据库会记录所有的改变，忽略表空间和对象的设置。
7. Control file parallel write 等待事件：
l 该事件通常是高日志切换的症状，正常情况下是CKPT 在此事件上有较高的等待，但是如果LGWR 在此事件上有较高等待，那么就有可能是日志切换太频繁了。
l 如果是前台进程在此事件上有较高的等待，那么就有可能是nologging 操作的对象，nologging 操作改变数据库时，必须在RMAN 中留下不可恢复的scn 。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/24465008/viewspace-688060/，如需转载，请注明出处，否则将追究法律责任。
