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