在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方面是很严重的事故。

因为应用程序存在大量的全表查询的语句。