在Oracle Database 11g中有一个新特性，全表扫描可以通过直接路径读的方式来执行（Direct Path Read），这是一个合理的变化，如果全表扫描的大量数据读取是偶发性的，则直接路径读可以避免大量数据对于Buffer Cache的冲击。

当然对于小表来说，Oracle允许通过Buffer Cache来进行全表扫描，因为这可能更快，也对性能影响不大。
小表受到隐含参数：_small_table_threshold 影响。如果表大于 5 倍的小表限制，则自动会使用DPR替代FTS。
可以设置初始化参数： _serial_direct_read 来禁用串行直接路径读。
当然，Oracle通过一个内部的限制，来决定执行DPR的阈值。
可以通过设置10949事件屏蔽这个特性，返回到Oracle 11g之前的模式上：
alter session set events '10949 trace name context forever,level 1' ;
还有一个参数 _very_large_object_threshold 用于设定（MB单位）使用DPR方式的上限，这个参数需要结合10949事件共同发挥作用。
10949 事件设置任何一个级别都将禁用DPR的方式执行FTS，但是仅限于小于 5 倍 BUFFER Cache的数据表，同时，如果一个表的大小大于 0.8 倍的 _very_large_object_threshold 设置，也会执行DPR。
这些限定的目标在于：
对于大表的全表扫描，必须通过Direct Path Read方式执行，以减少对于Buffer Cache的冲击和性能影响。
但是我们可以通过参数调整来决定执行DPR的上限和下限。
以下的AWR信息是典型的DPR症状：

备注：

目前数据库使用10949 trace name contextforever,level 1 事件来关闭了11G 新特性直接路径读,而在11.2.0.3 版本有可能该事件是不能关闭该功能的,需要设置另外一个参数 "_serial_direct_read"=never来关闭

关于direct pathread: 在11g中，全表扫描可能使用direct path read方式，绕过buffer cache，这样的全表扫描就是物理读了. 在10g中，都是通过gc buffer来读的，所以不存在direct path read的问题

1. 减少了对latch 的使用，避免可能的闩争用

2.物理IO的大小不再取决于buffer_cache中所存在的块。

当然直接路径读取也会引入一些缺点：

1.即便在buffer cache足够大到可以放下整个大表的情况下，direct path read无法从高速缓冲受益，每次扫描大表均需重复等量的直接路径物理读取IO

2.在直接路径读取某段前需要对该对象进行一次段级的检查点(A segment checkpoint).

3.可能导致重复的延迟块清除操作