Data file init write等待事件主要是用于数据文件内部扩展,增加数据文件出现的等待事件,该等待事件的三个参数分别是count,intr,timeout,oracle 10g推出的
SQL> alter session set events '10046 trace name context forever,level 8';
Session altered
SQL> alter database datafile 5 resize 100M;
Database altered
SQL> alter session set events '10046 trace name context off';
Session altered
---------
WAIT #2: nam='Data file init write' ela= 15163 count=1 intr=256 timeout=-1 obj#=1 tim=28805256609
WAIT #2: nam='Data file init write' ela= 6606 count=1 intr=256 timeout=-1 obj#=1 tim=28805263320
WAIT #2: nam='Data file init write' ela= 17 count=-1 intr=32 timeout=2147483647 obj#=1 tim=28805263425
WAIT #2: nam='control file sequential read' ela= 13871 file#=0 block#=1 blocks=1 obj#=1 tim=28805530331
WAIT #2: nam='control file sequential read' ela= 378 file#=0 block#=18 blocks=1 obj#=1 tim=28805562796
WAIT #2: nam='control file sequential read' ela= 10897 file#=0 block#=276 blocks=1 obj#=1 tim=28805573810
WAIT #2: nam='flashback buf free by RVWR' ela= 731 p1=0 p2=0 p3=0 obj#=1 tim=28805574738
WAIT #2: nam='control file sequential read' ela= 390 file#=0 block#=1 blocks=1 obj#=1 tim=28805575271
WAIT #2: nam='control file parallel write' ela= 1360 files=3 block#=275 requests=3 obj#=1 tim=28805579832
WAIT #2: nam='db file sequential read' ela= 19415 file#=5 block#=1 blocks=1 obj#=1 tim=28805606687
WAIT #2: nam='db file single write' ela= 8049 file#=5 block#=1 blocks=1 obj#=1 tim=28805614942
跟踪文件中的事件描述中:
Data file init write是数据文件扩展引起
Control file sequential read和control file parallel write是由于对控制文件读取和写入
db file sequential read看来resize datafile也有可能出现顺序读,是对数据文件5的block 1顺序读,这个顺序读应该是和下面的单块读取相关,需要读取数据文件头部。
db file single write 对数据文件头的写入操作,也是对数据文件5的文件头的block 1单块写入。
Eygle提高了此时应该有个文件级别的ckpt,不过在测试中没有发现,版本是oracle 10.2.0.0。
Db file sequential read等待事件
根据该等待事件的描述,是数据文件顺序读取的等待事件,该数据文件的三个参数分别是file#,first block#,block count在oracle 10g中被归于user I/O wait class,正如应用所说,db file sequential read等待事件出现并不一定是坏事,特别在cbo下很大程度代表了系统高效利用索引,但是也并不一定是性能优越的表现。
最近碰到的一个db file sequential read等待事件在早上7:00-9:00业务高峰期非常频繁,可以说已经影响到了系统的性能,通过awr报表top event也是由于此等待事件大概占用95%以上,而且开发反应这段时间数据采集很慢,看来此等待事件已经引起了系统性能的瓶颈,处理此等待事件个人也没有什么很好的经验。
首先想到的肯定是减少逻辑读(这个也是最应该注意的),如果从buffer获取索引扫描所需的block,肯定很快,不会引起大幅度的db file sequential read,可能是大量的sql并发导致扫描所需buffer过多,而sga中又无法存储充足的buffer,进而通过disk来获取,而disk由于做的raid 5,读取和写入有一定的下降,特别是写入,这也是不推荐将log放置在raid5上面的最重要原因,而避开硬件方面,发现其实逻辑读方面已经算是很合理了,根据sga_target_advice发现oracle给出的建议是继续增加sga物理读将取得进一步显著的下降,所以个人来看这个系统如果增加少量内存sga target,那么关于db file sequential read所需的block会尽可能多的在buffer上,而disk降低了,很有可能db file sequential read就会有显著的降低。
再说说关于db file sequential read的对象,当然扫描index或者根据index的rowid来扫描table是最主要的引起等待事件的对象,其实还包括undo和control files 和data file headers中进行single-block read,上面的resize就能发现有些许db file sequential read等待,网上有文章提到了关于减小average_time,其实还是关于增加减少物理读。
减少db file sequential read等待事件影响的方法是减少AVERAGE_WAIT ,AVERAGE_WAIT是一个session等待single block被从硬盘获取的平均等待时间
This is the average time a session has to wait for a single block fetch from disk(英文原句).
1 减少逻辑读,避免使用不合理的索引(cbo下已经很少,hint除外)
2 增加sga减少disk read
[@more@]
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25362835/viewspace-1058104/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/25362835/viewspace-1058104/