oracle 11G direct path read 非常美也非常伤人

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

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