Session is waiting for a direct write to complete.
Direct path writes allow a session to queue an I/O write request and continue processing while the OS handles the I/O. If the session needs to know if an outstanding write is complete, then it waits for this wait event. This can happen because the session is either out of free slots and needs an empty buffer (it waits on the oldest I/O) or it needs to ensure all writes are flushed.
If asynchronous I/O is not being used, then the I/O write request blocks until it is completed but this does not show as a wait at the time the I/O is issued. The session returns later to pick up the completed I/O data but can then show a wait on "direct path write" even though this wait will return immediately.
Hence this wait event is misleading because:
The total number of waits does not reflect the number of I/O requests
The total time spent in "direct path write" does not always reflect the true wait time.
This style of read request is typically used for:
Sort I/O (when a sort does not fit in memory)
Parallel DML are issued to create and populate objects
Direct load operations, for example, Create Table as Select (CTAS)
The rest of the information in this section is only valid for this metric when it appears in either the Enterprise Manager Grid Control or the Enterprise Manager Database Control (if applicable).
The following table shows how often the metric's value is collected and compared against the default thresholds. The 'Consecutive Number of Occurrences Preceding Notification' column indicates the consecutive number of times the comparison against thresholds should hold TRUE before an alert is generated.
Target Version |
Evaluation and Collection Frequency |
Upload Frequency |
Operator |
Default Warning Threshold |
Default Critical Threshold |
Consecutive Number of Occurrences Preceding Notification |
Alert Text |
pre-10g |
Every Minute |
After Every Sample |
> |
50 |
Not Defined |
3 |
%value%%% of service time is spent waiting on the 'direct path write' event. |
(DeltaDirectPathWriteTime/DeltaServiceTime)*100 where:
DeltaDirectPathWriteTime: difference of 'sum of time waited for sessions of foreground processes on the 'direct path write' event' between sample end and start
DeltaServiceTime: difference of 'sum of time waited for sessions of foreground processes on events not in IdleEvents + sum of 'CPU used when call started' for sessions of foreground processes' between sample end and start
See Idle Events
It is unusual to see lots of waits on "direct path write" except for specific jobs. If the figure is a large proportion of the overall wait time it is best to identify where the writes are coming from.
You can:
Examine the V$SESSION_EVENT view to identify sessions with high numbers of waits.
Examine the V$SESSTAT view to identify sessions with high "physical writes direct" (statistic only present in newer Oracle releases).
Examine the V$FILESTAT view to see where the I/O is occurring.
Determine whether the file indicates a temporary tablespace check for unexpected disk sort operations.
Ensure the DISK_ASYNCH_IO parameter is set to TRUE. This is unlikely to reduce wait times from the wait event timings but may reduce sessions elapsed times because synchronous direct I/O is not accounted for in wait event timings.
Ensure the OS asynchronous I/O is configured correctly.
Ensure no disks are I/O bound.
For parallel DML, check the I/O distribution across disks and make sure that the I/O subsystem is adequately sized for the degree of parallelism.
Related Topics
About Alerts
About the Metric Detail Page
Editing Thresholds
Understanding Line Charts
Copyright © 1996, 2009, Oracle and/or its affiliates. All rights reserved.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates.
Other names may be trademarks of their respective owners.