在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方面是很嚴重的事故。
因為應用程序存在大量的全表查詢的語句。
