Oracle11gR2後direct path read等待事件的改變

• When reading from the TEMP tablespace (a sort operation)

•  When reading a parallel full-table scan (parallel query factotum (slave) processes)

•  Reading a LOB segment

Note:  The behavior. of direct path reads changed in Oracle 11g release 2.  Before 11gr2, full table scan access path read all the blocks within a table (or a index fast full scan) into the buffer cache unless either the "_serial_direct_read" hidden parameter is set to "true" or the table/index has default parallelism set.  In sum, in 11g release 2 and beyond, Oracle will automatically decide whether to use direct path reads (thereby bypassing he buffer cache) with full table scans.

The hidden parameter "_small_table_threshold" defines the number of blocks to consider a table as being "small".   Any table having more than 5 times the number of blocks in "_small_table_threshold" (if you leave it at default value) will automatically use direct path reads for serial full table scans (FTS).

You see direct path read waits only when you are doing a parallel full-scan.  Unplanned direct path reads commonly happen when you turn on parallelism on at the system or session level:

alter table xxx parallel degree 32;

By specifying a table or index with the parallel option, the SQL optimizer thinks that a parallel full scan will be cheaper than a index range scan.  In these cases you will see lots of direct path reads.

When Oracle performs a parallel full-table scan, the database blocks are read directly into the program global area (PGA), bypassing the data buffer RAM:

Direct path reads are parallel full-table scans