using DIRECT PATH READ in oracle database

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 mechanism for direct path reads has been modified in 11g as compared to 10g.
IN 10g
 – all the parallel queries resulted in direct reads irrespective of the size of the data as parallel queries are normally used in data warehouse where amount of data read is large.
 –  all the serial queries were executed using buffered reads assuming that amount of data read is not large.
1. Parallel queries fetching even small amount of data bypassed the buffer cache so that if any other server process needed to access the same data,  he had to access the disk.
2. A serial query fetching massive amount of data could age out a lot of data from buffer cache .
In 11g we can modify this behaviour using some undocumented parameters.
1. we can set a threshold on the no. of blocks read (_small_table_threshold) so that even parallel queries fetching data less than the threshold will perform bufered I/O so that the fetched data in buffer cache can be accessed by other server processes also.
2. For serial queries we can enable direct I/O (_serial_direct_read) for all full table scans irrespective of the amount of the data read so that Full Table Scans (FTS’s)  read the data into PGA and data in buffer cache is not aged out.

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:

Direct path reads are parallel full-table scans


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s