before we talk about direct path read let’s first understand on important concept
Question: What is asynchronous I/O and how is asynchronous I/O different from standard I/O?
When a system process attempts to read or write using the normal synchronous read() or write() system calls, then it must wait until the physical I/O is completed. Once the success or failure of the read/write operation is known, the process finishes the task. During this time, the execution of the process is blocked while it waits for the results of the system call. This is synchronous or blocking I/O.
Asynchronous I/O which indicates that it is a Non-blocking I/O. If the process instead uses the asynchronous aio_read() or aio_write() system calls, then the system call will return immediately once the I/O request has been passed down to the hardware or queued in the operating system, typically before the physical I/O operation has even begun. It can continue executing and then receive the results of the I/O operation later, once they are available. Thus it is asynchronous or non-blocking I/O.
Asynchronous I/O enables write intensive processes like Oracle’s DBWn to make full use of the I/O bandwidth of the hardware
The direct path read Oracle metric occurs during Direct Path operations when the data is asynchronously read from the database files into the PGA instead of into the SGA data buffer. Direct reads occur under these conditions:
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: