Direct Path Read is one of the most common and misunderstood wait events in Oracle databases.
DBAs regularly see it inside AWR/ASH reports during performance slowdowns — especially when large tables are scanned.
In this blog, we will explain Direct Path Read, why it occurs, how to improve performance, and when to use direct reads.
What Is Direct Path Read in Oracle?
A Direct Path Read occurs when Oracle bypasses the SGA buffer cache and reads data blocks directly into the PGA.
✔ Why Oracle uses Direct Path Read?
Because reading directly to PGA:
Avoids buffer cache latches Speeds up large sequential I/O Works better for full table scans on large tables Helps parallel execution
In simple words:
Oracle skips the buffer cache because the table is too large or the query needs high-speed I/O.
When Does Oracle Use Direct Path Read?
Oracle decides to use Direct Path Read mainly in the following cases:
1. Full Table Scan on Large Tables
If a table is larger than Oracle’s small table threshold, Oracle treats it as a “big table,” and full table scans go directly to PGA.
2. Not Enough Buffer Cache
If SGA is small and cannot hold the table, Oracle uses direct read.
3. Parallel Query
Parallel execution always prefers direct path reads.
4. Statistics Driven Decision
When _direct_read_decision_statistics_driven = TRUE, Oracle uses object statistics to decide.
Why You See High “Direct Path Read” Waits in AWR?
High Direct Path Read waits simply mean Oracle is reading a lot of data from disk, usually because:
👉 The SQL uses FULL TABLE SCAN.
👉 Table size has grown over time.
👉 No useful indexes exist.
👉 Buffer cache cannot hold table blocks.
👉 LOB reads behave differently and often bypass cache.
In many cases, this is normal — especially in Data Warehouse workloads.
Example Production Issue
SELECT c1, c2, c3 FROM table_name WHERE c1 = :1 AND c3 = :5;
was originally fast, but over time:
Table size increased. Oracle stopped treating it as a small table. Full table scans now caused direct path reads.
This made the query I/O heavy and slow.
How to Reduce Direct Path Read Waits (Best Solutions)
Here are the practical fixes:
1. Tune the SQL to Avoid Full Table Scan
Create indexes on filter columns (e.g., C1, C3).
This is the best and most common fix.
2. Cache the Table (Force Buffer Cache Reads)
ALTER TABLE table_name CACHE;
or use KEEP buffer pool.
This forces Oracle to treat the table like a small table despite its size.
⚠ Only works if buffer cache has enough memory.
3. Increase SGA / Buffer Cache Size
A bigger buffer cache increases the threshold used to decide direct reads.
4. Change _small_table_threshold
If you want Oracle to stop using direct path read for medium tables:
SELECT ksppstvl FROM x$ksppsv WHERE indx =
(SELECT indx FROM x$ksppi WHERE ksppinm = ‘_small_table_threshold’);
You can increase it manually — but do this carefully.
How to Force Direct Path Read (If You Need It)
Sometimes the reverse is needed:
You want a query to always use direct path reads.
Here are the two methods:
Method 1: Use Parallel Hint
SELECT /*+ PARALLEL(4) */ * FROM table;
Parallel execution always triggers direct reads.
Method 2: Manipulate Table Statistics
If _small_table_threshold = 480 and your table has only 100 blocks, you can force direct reads:
EXEC DBMS_STATS.SET_TABLE_STATS(‘USER’,’TABLE_NAME’, numblks=>1000);
Checklist for Troubleshooting Direct Path Read Issues
Check AWR Top SQL (elapsed time)
Look for FULL TABLE SCAN in execution plan
Check if table grew recently
Check missing indexes
Check buffer cache size
Review hidden parameters: _serial_direct_read
_small_table_threshold
_direct_read_decision_statistics_driven
Check I/O performance (latency)
Check dirty buffer checkpoint waits
Conclusion
Direct Path Read is not always a database problem — it is often how Oracle is designed to read big data efficiently.
However, when performance suffers, it is usually because:
A table grew too big A query is doing unnecessary full scans Buffer cache is too small Wrong statistics influenced Oracle’s decisions