Enqueues are local locks that serialize access to various resources. This wait event indicates a wait for a lock that is held by another session (or sessions) in an incompatible mode to the requested mode.
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 |
> |
20 |
Not Defined |
3 |
%value%%% of service time is spent waiting on the 'enqueue' event. |
(DeltaEnqueueTime/DeltaServiceTime)*100 where:
DeltaEnqueueTime: difference of 'sum of time waited for sessions of foreground processes on the 'enqueue' event, or any other 'enqueue:' 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
The action to take depends on the lock type which is causing the most problems. The most common lock waits are generally for:
TX: Transaction Lock -- Generally due to application or table setup issues, for example row level locking conflicts and ITL allocation
TM: DML enqueue -- Generally due to application issues, particularly if foreign key constraints have not been indexed.
ST: Space management enqueue -- Usually caused by too much space management occurring (for example, small extent sizes, lots of sorting, and so on)
HW: High Water Mark -- Concurrent users trying to extend a segment's high-water mark for space allocated.
To determine which enqueues are causing the most waits systemwide, examine the V$ENQUEUE_STAT view thus:
SELECT eq_type "Lock", total_req# "Gets", total_wait# "Waits", cum_wait_time FROM V$enqueue_stat WHERE Total_wait# > 0 ;
This gives the systemwide number of waits for each lock type. Remember that it only takes one long wait to distort the average wait time figures.
You can also examine:
Sessions with high numbers of "enqueue waits" in the V$SESSTAT view
Sampling of the V$LOCK view to find waiting / blocking sessions
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.