WAITEVENT: "enq: TX - row lock contention" Reference Note (文档 ID 1966048.1) 转到底部

"enq: TX - row lock contention" Reference Note

This is a reference note for the wait event "enq: TX - row lock contention" which includes the following subsections:

  • Brief definition

  • Individual wait details (eg: For waits seen in V$SESSION_WAIT)

  • Systemwide wait details (eg: For waits seen in V$SYSTEM_EVENT)

  • Reducing waits / wait times

  • Troubleshooting

  • Known Bugs

See Document:61998.1 for an introduction to Wait Events.

Definition:

Versions: 10.1 - 12.1
Documentation: 12.1 11.2 11.1 10.2 10.1 

This wait indicates time spent waiting for a TX lock, typically due to waiting to gain access to a row in a table that is currently locked by that transaction. The TX lock waited on is "TX-P2RAW-P3RAW" and the object / row that triggered the wait can usually be found in the ROW_WAIT_* columns of V$SESSION for the waiting session.

Individual Waits:

  Parameters:

P1 = name|mode

P2 = usn<<16 | slot

P3 = sequence

  • name|mode

    The lock  name and requested  mode are encoded into  P1 as " name<<16 | mode". This is best seen in  P1RAW (or you can convert P1 to hexadecimal). 
    For this wait:
    eg:  P1RAW of 54580006 = eXclusive mode TX wait, P1RAW of 54580004 = Shared mode TX wait.

    • "6" = eXclusive mode TX wait.

    • "4" = Shared mode TX wait.

    • name is always the ASCII for "TX" = 0x5458.

    • mode is the mode that the TX lock is being requested in. 
      In most cases mode will be 6 . Occassionally it may be 4:

  • usn<<16 | slot

    P2RAW indicates the ID1 part of the TX lock being waited on, which is an encoding of the undo segment (usn) and the undo slot.

  • sequence

    P3RAW indicates the ID2 part of the TX lock being waited on, which is the undo slot sequence number.

  Wait Time:

Oracle waits for the TX lock until it is either granted or the request times out, as can occur if a "WAIT" clause is included in the current SQL. Deadlock detection occurs for TX locks.

  Finding Blockers:

Details of the object / block / row that caused the wait can usually be found in the  ROW_WAIT_* columns of  V$SESSION for the waiting session. eg: 
SELECT row_wait_obj#, row_wait_file#, row_wait_block#, row_wait_row#
  FROM v$session
 WHERE event='enq: TX - row lock contention'
   AND state='WAITING'
;
If the OBJ# is -1 then the object could not be determined.

P2 and P3 correspond to the ID1 and ID2 columns of [G]V$LOCK for rows with TYPE='TX'.

P2 and P3 also give the XIDUSN/XIDSLOT/XIDSQN values of the blocking transaction in [G]V$TRANSACTION.

You can identify the specific TX lock being waited on, and blocking tranaction id, using SQL like this:

SELECT 
   sid, seq#, state, seconds_in_wait,
   'TX-'||lpad(ltrim(p2raw,'0'),8,'0')||'-'||lpad(ltrim(p3raw,'0'),8,'0') TX,
   trunc(p2/65536)      XIDUSN,
   trunc(mod(p2,65536)) XIDSLOT,
   p3                   XIDSQN
  FROM v$session_wait 
 WHERE event='enq: TX - row lock contention'
;

You can find current blockers by querying GV$LOCK like this:

SELECT distinct w.tx, l.inst_id, l.sid, l.lmode, l.request
 FROM 
  ( SELECT p2,p3,
     'TX-'||lpad(ltrim(p2raw,'0'),8,'0')||'-'||lpad(ltrim(p3raw,'0'),8,'0') TX
      FROM v$session_wait 
     WHERE event='enq: TX - row lock contention'
       and state='WAITING'
  ) W, 
  gv$lock L
 WHERE l.type(+)='TX'
   and l.id1(+)=w.p2
   and l.id2(+)=w.p3
 ORDER BY tx, lmode desc, request desc
;

If the sequence of events leading to the row contention is not clear then one could use LogMiner to get details of what the transactions involved did in what order.

Systemwide Waits:

"enq: TX - row lock contention" waits are generally related to the application code being executed and do not indicate a problem with the DB itself.

Possible actions:

Check the "Segments by Row Lock Waits" section of the AWR for clues about objects incurring high waits

Use ADDM reports to identify SQLs and sessions involved in high TX waits at systemwide level. See Note:1680075.1 for instructions on running ADDM.

Drill down into individual SQLs or sessions showing high waits to understand which application code , which objects, and which SQL/s are involved in the waits.

ASH reports for sessions showing high "enq: TX - row lock contention" wait time can also help.

Reducing Waits / Wait times:

Reducing waits typically involves altering application code to avoid the contention scenario/s.
eg: altering code so that concurrent sessions work on non-intersecting data sets, committing more frequently if the blocker is a long running transaction, etc..
See the documents in the "Troubleshooting" section below.

Troubleshooting

See the following documents for help troubleshooting "enq: TX - row lock contention" waits:

Document:1680075.1 "How to Generate and Check an ADDM report" 
Document:62354.1 "TX Transaction locks - Example wait scenarios" 
Document:1476298.1 Resolving Issues Where 'enq: TX - row lock contention' Waits are Occurring 

If reporting a suspected problem to Oracle collect evidence as described in: 
Document:1595636.1 SRDC - How to Collect Standard Information for an Issue Where 'enq: TX - ...' Type Waits Are the Primary Waiters on the Database

Known Issues / Bugs:

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button: 
               


NB Prob Bug Fixed Description

II 16763016 11.2.0.4, 12.1.0.2, 12.2.0.1 DBMS_PARALLEL_EXECUTE causes row lock contention on DBMS_PARALLEL_EXECUTE_CHUNKS$ - superseded

II 13511170 12.1.0.1 Multi-node Deadlock detection among many processes in RAC does not detect deadlock

II 22239699 12.2.0.1 FBDA TCRV delete maintenance colliding with archiving delete causing TX contention

- 16421696 12.1.0.2, 12.2.0.1 "SELECT .. FOR UPDATE WAIT n" against IOT does not time out after N seconds or ORA-7445 [kdidgb2]

III 16470836 12.1.0.2, 12.2.0.1 High DML rate against MON_MODS$ related to DBMS_STATS

- 8323978 10.2.0.5, 11.2.0.1 "enq: TX - row lock contention" from SYNC_INDEX in parallel

III 7529174 10.2.0.5, 11.1.0.7.3, 11.2.0.1 Deadlock / hang between SMON and foreground process

- 6055481 10.2.0.5, 11.2.0.1 Concurrent RMAN delete obsolete jobs hang on row lock contention

I 5849679 11.1.0.7, 11.2.0.1 Undetected deadlock in RAC involving a TM lock

'*' indicates that an alert exists for that issue.

'+' indicates a particularly notable issue / bug.

See Note:1944526.1 for details of other symbols used


Related:

Document:1392319.1 Master Note: Locks, Enqueues and Deadlocks (ORA-00060)
Document:402983.1 Master Note: Database Performance Overview
Document:197057.1 TX Lock "Transaction Enqueue"
Document:276103.1 Performance Tuning Using Advisors and Manageability Features: AWR, ASH, ADDM and Sql Tuning Advisor