第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/,如需转载,请注明出处,否则将追究法律责任。