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

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