oracle 11G direct path read 很美也很傷人

標籤：style   blog   http   color   使用   os   io   檔案   

direct path read

在11g中，全表掃描可能使用direct path read方式，繞過buffer cache，這樣的全表掃描就是物理讀了。

在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的效能。

　　一個隱含參數：

　　_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

看起來很美 當是它帶來另外個等待事件，那就是要把緩衝中的髒資料刷回資料檔案中。激發check point 事件，DBWR寫的任務很頻繁。

大量的讀IO導致IO緩慢，緩慢的IO又讓DBWR寫得更慢，同時check point事件會阻塞 DML。 在OLTP方面是很嚴重的事故。

因為應用程式存在大量的全表查詢的語句。

oracle 11G direct path read 很美也很傷人