在11g中，全表扫描可能使用direct path read方式，绕过buffer cache，这样的全表扫描就是物理读了。 在10g中，都是通过gc buffer来读的，所以不存在direct path read的问题。
direct path read较高的可能原因有：
1.与直接读取相关联的等待事件。当ORACLE将数据块直接读入会话的PGA（进程全局区）中，同时绕过SGA（系统全局区）。PGA中的数据并不和其他的会话共享。即表明，读入的这部分数据该会话独自使用，不放于共享的SGA中。
2.在排序操作(order by/group by/union/distinct/rollup/合并连接)时，由于PGA中的SORT_AREA_SIZE空间不足，造成需要使用临时表空间来保存中间结果，当从临时表空间读入排序结果时，产生direct path read等待事件。
3.使用HASH连接的SQL语句，将不适合位于内存中的散列分区刷新到临时表空间中。为了查明匹配SQL谓词的行，临时表空间中的散列分区被读回到内存中(目的是为了查明匹配SQL谓词的行)，ORALCE会话在direct path read等待事件上等待。
4.使用并行扫描的SQL语句也会影响系统范围的direct path read等待事件。在并行执行过程中，direct path read等待事件与从属查询有关，而与父查询无关，运行父查询的会话基本上会在PX Deq:Execute Reply上等待，从属查询会产生direct path read等待事件。
从Oracle 9i 开始， _DB_FILE_DIRECT_IO_COUNT 这个隐含参数控制以字节(不是块)为单位的直接IO容量)，这个参数可能影响direct path read的性能。默认值是1Mb，但是如果系统的max_io_size更小，那默认值也会被缩小。
可参考：Document 47324.1 Init.ora Parameter "DB_FILE_DIRECT_IO_COUNT" Reference Note。
event 10949或者设置隐含参数_serial_direct_read,两种方式可以在session或system级别设置direct path read的开关。
ALTER session SET EVENTS '10949 TRACE NAME CONTEXT FOREVER';
ALTER session SET EVENTS '10949 TRACE NAME CONTEXT off';
参考至：http://blog.sina.com.cn/s/blog_61cd89f60102eeen.html
http://blog.chinaunix.net/uid-23622436-id-3248624.html
http://soft.chinabyte.com/database/459/12363959.shtml
http://blog.csdn.net/bisal/article/details/12417475
http://www.confio.com/logicalread/oracle-db-file-direct-io-count-initialization-parameters-mc01/#.U8oqiLEYRMY
如有错误，欢迎指正