db file sequential read事件的發生

”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操作

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/22990797/viewspace-1395332/，如需轉載，請註明出處，否則將追究法律責任。