data file int write和db file sequential read個人想法

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=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= ela= 1360 files=3 block#=275 requests=3 obj#=1 tim=28805579832

WAIT #2: nam='' 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@]