1.常見等待事件-db file scattered read
當數據塊以multiblock read的行式被
讀取到SGA中時。
– FTS(full table scan)
– IFFS(index fast full scan)
– db_file_multiblock_read_count
AWR中相對應事件：（Avg wait time應當小於20ms）
2、常見等待事件-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操作，
上面的圖表示的是出現行鏈接的情況。
通常，Avg wait time應當小於20ms。具體看上面第5點。
參考：http://www.askmaclean.com/archives/db-file-sequential-read-wait-event.html
3.解決方法:
通過查看按讀排序的sql語句，或物理讀最多的段，是否有優化的餘地。
4.常見等待事件--direct path read
在11g中，全表掃描可能使用direct path read方式，繞過buffer cache，這樣的全表掃描就是物理讀了（在11g中如果表的大小佔了大於等於sga的2%，就會採用直接讀取）。 在10g中，都是通過gc buffer來讀的，所以不存在direct path read的問題。
direct path read較高的可能原因有：
1. 大量的磁盤排序操作，order by, group by, union, distinct, rollup, 無法在PGA中完成排序，需要利用temp表空間進行排序。 當從臨時表空間中讀取排序結果時，會產生direct path read.
2. 大量的Hash Join操作，利用temp表空間保存hash區。
3. SQL語句的並行處理
4. 大表的全表掃描，在中，全表掃描的算法有新的變化，根據表的大小、高速緩存的大小等信息，決定是否繞過SGA直接從磁盤讀Oracle11g取數據。而10g則是全部通過高速緩存讀取數據，稱爲table scan(large)。11g認爲大表全表時使用直接路徑讀，可能比10g中的數據文件散列讀(db file scattered reads)速度更快，使用的latch也更少。
大量的direct path read等待時間最可能是一個應用程序問題。 direct path read事件由SQL語句驅動，這些SQL語句執行來自臨時的或常規的表空間的直接讀取操作。 當輸入的內容大於PGA中的工作區域時，帶有需要排序的函數的SQL語句將排序結果寫入到臨時表空間中，臨時表空間中的排序順序串隨後被合併，用於提供最終的結果。讀取排序結果時，Oracle會話在direct path read等待事件上等待。DB_FILE_DIRECT_IO_COUNT初始化參數可能影響direct path read的性能。
一個隱含參數/或者100949事件：
_serial_direct_read = false 禁用direct path read
_serial_direct_read = true 啓用direct path read
alter sytem set "_serial_direct_read"=never scope=both sid='*'; 可以顯着減少direct path read
也可以參考下惜分飛的博客 http://www.xifenfei.com/685.html
本文出自 “無雙城” 博客，請務必保留此出處http://929044991.blog.51cto.com/1758347/1262935