WAITEVENT: "enqueue" Reference Note (Doc ID 34566.1)

WAITEVENT: "enqueue" Reference Note (Doc ID 34566.1)   

https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=3bhyoiwyl_4&_afrLoop=115231731644753


"enqueue" Reference Note
This is a reference note for the wait event "enqueue" which includes the following subsections:
Brief definition
Individual wait details (eg: For waits seen in <>)
Systemwide wait details (eg: For waits seen in <>)
Reducing waits / wait times
See Note:61998.1 for an introduction to Wait Events.
Definition:
Versions:7.0 - 9.2 Documentation: 9.0
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. See Note:29787.1 (about V$LOCK) for details of which lock modes are compatible with which.
Enqueues are usually represented in the format "TYPE-ID1-ID2" where

"TYPE" is a 2 character text string
"ID1" is a 4 byte hexadecimal number
"ID2" is a 4 byte hexadecimal number
Individual Waits:
  Parameters:
P1 = Lock Type & Mode
P2 = Lock ID1
P3 = Lock ID2
Lock Type & Mode
The lock type and requested mode are encoded into P1 thus:
Convert P1 into hexadecimal (or use P1RAW) and extract the lock type and requested mode from this by converting the first 2 bytes of the hexadecimal number to ASCII and the second 2 bytes to a number:
  Eg: 54580006  
      ^^^^------ Converted to ASCII gives "TX" (0x54 = "T", 0x58 = "X")
          ^^^^-- 0006 is 6 in decimal so this is a mode 6 request

  Note that on UNIX, the command 'man ascii' will display the Octal, 
  hexadecimal, and decimal ASCII character sets to help with the hex 
  translation.

An alternative way to extract this information is to use SQL thus:
 SELECT chr(to_char(bitand(p1,-16777216))/16777215)||
         chr(to_char(bitand(p1, 16711680))/65535) "Lock",
         to_char( bitand(p1, 65535) )    "Mode"
    FROM v$session_wait
   WHERE event = 'enqueue'
  ;


Lock ID1
P2 represents ID1 of the enqueue name in decimal.
P2RAW represents ID1 of the enqueue name in hexadecimal.
Lock ID2
P3 represents ID2 of the enqueue name in decimal.
P3RAW represents ID2 of the enqueue name in hexadecimal.
  Wait Time:
The actual wait time depends on the lock type. In most cases Oracle waits for up to 3 seconds or until posted that the enqueue resource is now available (whichever occurs first). When the wait event times out Oracle will check that the session holding the lock is still alive and if so wait again. Deadlock detection is also performed against deadlock sensitive locks.
  Finding Blockers:
If a session is stuck waiting on an "enqueue" wait one can use <> to find the blocker/s and other waiters:
V$LOCK.TYPE is the lock type from P1
V$LOCK.ID1 is the lock ID1 from P2
V$LOCK.ID2 is the lock ID2 from P3
It can often be simpler just to look at waiters in V$LOCK directly:
  SELECT * FROM v$lock WHERE request > 0;
or to see blockers as well:
  SELECT DECODE(request,0,'Holder: ','Waiter: ')||sid sess, 
         id1, id2, lmode, request, type
    FROM V$LOCK
   WHERE (id1, id2, type) IN
             (SELECT id1, id2, type FROM V$LOCK WHERE request>0)
   ORDER BY id1, request
  ;
Systemwide Waits:
The count and average wait times for this wait-event can be misleading as "enqueue" waits re-arm every few seconds (see "Wait Time" above). To qualify how many waits have really occurred you need the enqueue waits statistic from <>, or from the "Statistics" section of the StatsPack or Estat report.
Eg: Assume
        Wait Events show enqueue time_waited=3000 total_waits=10
        Statistics  show enqueue waits has a count of 2
    This means there were 2 actual waits whose individual wait times totalled 
    to 3000 hundredths of a second (ie: 30 seconds).
To determine which enqueues are causing the most waits system-wide look at <> (Oracle9i onwards only) thus:
  SELECT  eq_type "Lock", 
          total_req# "Gets",
          total_wait# "Waits",
      cum_wait_time
    FROM V$enqueue_stat 
    WHERE Total_wait# > 0
  ;
In Oracle8i or earlier look at <> instead thus:
  SELECT  ksqsttyp "Lock", 
          ksqstget "Gets",
          ksqstwat "Waits"
    FROM X$KSQST where KSQSTWAT > 0;
The above give the system wide number of waits for each lock type. Remember that it only takes one long wait to distort the average wait time figures. One can also look at:
Sessions with high numbers of "enqueue waits" in <>
Sampling of <> to find waiting / blocking sessions
Reducing Waits / Wait times:
The action to take depends on the lock type which is causing the most problems. It is beyond the scope of this reference note to look at the reasons for waits on each lock type - the most common lock waits are generally for:
     TX      Transaction Lock 
                Generally due to application or table setup issues
                See Note:62354.1 for example scenarios which can cause
                TX lock waits.

     TM      DML enqueue
                Generally due to application issues, particularly if 
                foreign key constraints have not been indexed. The following
        two articles describe referential integrity issues related
        to TM locking:
             Example TM locks During Referential 
            Integrity Enforcement                  Note:38373.1

                  TM locks and Foreign Key Constraints         Note:33453.1

     ST      Space management enqueue 
                Usually caused by too much space management occurring 
                (Eg: small extent sizes, lots of sorting etc..) 
                See Note:33567.1 for more information about the ST
                enqueue.

Related:
Details of V$LOCK view and lock modes Note:29787.1
Tracing User sessions Note:62160.1