何時會發生db file sequential read等待事件？

很多網友對系統內頻繁發生的db file sequential read等待事件存有疑問，那麼到底在那些場景中會觸發該單塊讀等待事件呢?

在我之前寫的一篇博文中總結了db file sequential read等待事件可能發生的場景，在這裡再share以下:

”db file sequential read”單塊讀等待是一種最為常見的物理IO等待事件，這裡的sequential指的是將資料塊讀入到相連的記憶體空間中(contiguous memory space)，而不是指所讀取的資料塊是連續的。該wait event可能在以下情景中發生:

1. 最為常見的是執行計劃中包含了INDEX FULL SCAN/UNIQUE SCAN,此時出現”db file sequential read”等待是預料之中的，一般不需要我們去特別關注
2. 當執行計劃包含了INDEX RANGE SCAN-(“TABLE ACCESS BY INDEX ROWID”/”DELETE”/”UPDATE”)， 服務程式將按照”訪問索引->找到rowid->訪問rowid指定的表資料塊並執行必要的操作”順序訪問index和table，每次物理 讀取都會進入”db file sequential read”等待，且每次讀取的都是一個資料塊；這種情況下clustering_factor將發揮其作用，需要我們特別去關注，本例中提及的解決方法對 這種情景也有效
3. Extent boundary,假設一個Extent區間中有33個資料塊，而一次”db file scattered read”多塊讀所讀取的塊數為8，那麼在讀取這個區間時經過4次多塊讀取後，還剩下一個資料塊，但是請記住多塊讀scattered read是不能跨越一個區間的(span an extent)，此時就會單塊讀取並出現”db file sequential read”。這是一種正常現象，一般不需要額外關注
4. 假設某個區間內有8個資料塊，它們可以是塊a,b,c,d,e,f,g,h，恰好當前系統中除了d塊外的其他資料塊都已經被快取在buffer cache中了，而這時候恰好要訪問這個區間中的資料，那麼此時就會單塊讀取d這個資料塊，並出現”db file sequential read”等待。注意這種情況不僅於表，也可能發生在索引上。這是一種正常現象，一般不需要額外關注
5. chained/migrated rows即鏈式或遷移行，這裡我們不介紹鏈式行的形成原因，chained/migrated rows會造成服務程式在fetch一行記錄時需要額外地單塊讀取，從而出現”db file sequential read”。這種現象需要我們特別去關注，因為大量的鏈式/遷移行將導致如FULL SCAN等操作極度惡化(以往的經驗是一張本來全表掃描只需要30分鐘的表，在出現大量鏈式行後，全表掃描需要數個小時)，同時也會對其他操作造成不那麼 明顯的效能影響。可以透過監控v$sysstat檢視中的”table fetch continued row”操作統計來了解系統中鏈式/遷移行訪問的情況，還可以透過DBA_TBALES檢視中的CHAIN_CNT來了解表上的鏈式/遷移行情況，當然這 要求定期收集表上的統計資訊；如果沒有定期收集的習慣，那麼可以配合@?/rdbms/admin/utlchain指令碼和analyze table list chained rows 命令來獲取必要的鏈式行資訊
6. 建立Index entry，顯然當對錶上執行INSERT操作插入資料時，雖然在執行計劃中你看不到過多的細節，但實際上我們需要利用索引來快速驗證表上的某些約束是否 合理，還需要在索引的葉子塊中插入相關的記錄，此時也可能出現”db file sequential read”等待事件，當然這還和具體的插入的方式有關係。這是一種正常現象，一般不需要額外關注
7. 針對表上的UPDATE/DELETE，不同於之前提到的”INDEX RANGE SCAN-UPDATE/DELETE”，如果我們使用rowid去更新或刪除資料時，服務程式會先訪問rowid指向的表塊(注意是先訪問table block)上的行資料，之後會根據該行上的具體資料去訪問索引葉子塊(注意Oracle並不知道這些leaf block在哪裡，所以這裡同樣要如range-scan/unique-scan那樣去訪問index branch block)，這些訪問都將會是單塊讀取，並會出現’db file sequential read’，完成必要的讀取後才會執行更新或刪除的實際EXEC操作，如下例:

以下trace中，obj#=1307547為sample表，而obj#=1307549為sample表上的唯一一個索引 

PARSING IN CURSOR #10 len=58 dep=0 uid=64 oct=6 lid=64 tim=1275805024007795 hv=505118268 ad='d387e470'
update sample set t2=t2+1 where rowid='AAE/OzAAEAAANUEAAQ'
END OF STMT
PARSE #10:c=1999,e=3016,p=1,cr=1,cu=0,mis=1,r=0,dep=0,og=1,tim=1275805024007787
WAIT #10: nam='db file sequential read' ela= 314 file#=4 block#=54532 blocks=1 obj#=1307547 tim=1275805024008308
WAIT #10: nam='db file sequential read' ela= 206 file#=6 block#=20 blocks=1 obj#=1307549 tim=1275805024009235
WAIT #10: nam='db file sequential read' ela= 206 file#=6 block#=742 blocks=1 obj#=1307549 tim=1275805024009496
WAIT #10: nam='db file sequential read' ela= 207 file#=6 block#=24 blocks=1 obj#=1307549 tim=1275805024009750
EXEC #10:c=2000,e=2297,p=6,cr=2,cu=8,mis=0,r=1,dep=0,og=1,tim=1275805024010210   --實際的UPDATE發生在這裡

當大量執行這類UPDATE/DELETE操作時將需要頻繁地交叉訪問表和索引，如果恰好表上的某個索引有較高的 clustering_factor的話，那麼就會形成本例中的這種效能問題了。實際上當表上有較多索引時，使用rowid來批次 update/delete資料這種方式是不被推薦的，僅當表上沒有索引時才可能十分高效。如果你堅持要這樣做，那麼可以參照上面提到的建議。

 

8.BUG!BUG!已知在9i RAC及10g中使用ASM的情況下，存在引發在適用情況下不使用”scattered read”多塊讀而去使用”sequential read”的BUG。如果你的問題和上述情景都不匹配，但又有大量的”db file sequential read”等待事件，那麼你有可能遇到bug了。在這裡列出部分已知bug:

Bug#	Version Affected
Bug 7243560 – High “db file sequential read” IO times when using ASM	10.2.0.4/11.1.0.7
Bug 7243560: RAPID INCREASE IN DB FILE SEQUENTIAL READ AFTER MOVING TO ASM	10.2.0.3
Bug 9711810: EXCESSIVE DB FILE SEQUENTIAL READS WITH NON COMPLIANT BUFFER CACHE ON RAC	9.2.0.8
Bug 9276739: INSERT STATEMENT HAS SLOW PERFORMANCE WITH DB FILE SEQUENTIAL READ	10.2.0.4
Bug 8625100: EXCESSIVE DB FILE SEQUENTIAL READ ON UNDO	10.2.0.4
Bug 8669544: HIGH DB FILE SEQUENTIAL READ AND GC CR DISK READ WAIT EVENTS DURING FULL SCAN	10.2.0.4
Bug 7427133: AN INSERT CAUSES LOTS OF ‘DB FILE SEQUENTIAL READ’ WAITS FOR THE INDEX BLOCKS	9.2.0.8
Bug 8493139: INCREASE IN DB FILE SEQUENTIAL READ WAITEVENT AFTER MIGRATING TO 10 RAC/ASM	10.2.0.4
Bug 5882268: PERFORMANCE ISSUE WITH ‘DB FILE SEQUENTIAL READ’	10.2.0.2
Bug 7415702: LOTS OF ‘DB FILE SEQUENTIAL READ’ ON UNDO	10.2.0.3
Bug 5607724: 10202 DB FILE SEQUENTIAL READ THRICE AFTER UPGRADE FROM 9I	10.2.0.2