ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 第5 章、解释常见的与I/O 有关的等待事件

第5 章、解释常见的与I/O 有关的等待事件

原创 Linux操作系统 作者:红叶DBA 时间:2011-02-28 09:12:45 0 删除 编辑

章、解释常见的与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)      例如一个区中有个块,MBRC=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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2010-08-19

  • 博文量
    54
  • 访问量
    69619