sapnote_0000745639

05.05.2013 Page 1 of 22

SAP Note 745639 - FAQ: Oracle enqueues

Note Language: English Version: 133 Validity: Valid Since12.12.2012

The displayed SAP Note is not up to date in the selected language /

Summary

Symptom

1. What are Oracle enqueues?

2. How do Oracle enqueues differ from R/3 enqueues?

3. What happens if a requested enqueue has already been allocated?

4. How can I determine whether I have problems with Oracle enqueues?

5. What are the different types of Oracle enqueues?

6. Which Oracle parameters play a role in the enqueue environment?

7. In which modes can I hold or request an enqueue?

8. How do I find out which sessions are currently holding enqueues orwaiting for enqueues?

9. Are permanently visible V$LOCK entries with MR, RT, TS and XR enqueuetypes critical?

10. How I can determine the enqueue type for which a session is currentlywaiting?

11. How I can determine how long a session has been waiting for certainenqueues since the database was started?

12. What are typical enqueue wait situations and what are possiblesolutions?

13. How I can determine which tables are most responsible for TX enqueuewaits?

14. How do I find the table and the data record that is responsible for aTX enqueue?

15. How can I trace the enqueue requests of a session?

16. Where can I find more information about Oracle enqueues?

Other termsFAQ, lock wait

Reason and Prerequisites

Solution

05.05.2013 Page 2 of 22


1. What are Oracle enqueues?

Oracle enqueues are locks at database level that coordinate parallelaccess to Oracle resources such as objects or data records. Forexample, enqueues are responsible for several transactions not beingable to change the same data record at the same time.

Enqueue requests are divided into queues whose requests are thenprocessed in the chronological sequence of their arrival. This is animportant difference to Oracle latches (Note 767414), for which thereare no queues.

Oracle enqueues are often also referred to as exclusive lockwaits.

2. How do Oracle enqueues differ from R/3 enqueues?

R/3 enqueues also coordinate access to the application data in thedatabase. However, they are independent of Oracle enqueues. You canhave R/3 enqueues without Oracle enqueues and Oracle enqueues withoutR/3 enqueues. You can use transaction SM12 to monitor the R/3 enqueuesand transaction DB01 to monitor Oracle enqueues.

3. What happens if a requested enqueue has already been allocated?

In connection with most of the enqueues, there are no timeouts. Eitheran error occurs immediately, or the session waits as long as it hasto:

o Enqueue requests with NOWAIT

If an enqueue with NOWAIT is requested (for example, as part of aDDL statement without an ONLINE option) and the enqueue is alreadybeing held by another session, the following error message isissued:

ORA-00054: resource busy and acquire with NOWAIT specified

o Enqueue requests without NOWAIT

If an enqueue without NOWAIT is requested (for example, by SAPtransactions), the session waits as long as required if anothersession is holding the requested enqueue.

For specific enqueues (for example, the control file enqueue), atimeout mechanism has been implemented. If a timeout occurs, thesystem may issue the following error message:

ORA-00494: enqueue <type> held for too long

4. How can I determine whether I have problems with Oracle enqueues?

Carry out a wait event analysis in accordance with Note 619188 todetermine whether the general database performance is impaired byenqueues or whether long-running transactions must wait for enqueues.

While there was only one generic wait event "enqueue" up until Oracle9i, Oracle 10g or higher differentiates between the different enqueue

05.05.2013 Page 3 of 22


types and causes for the wait event. For example, "enq: TX - allocateITL entry" denotes an enqueue in the Interested Transaction List inthe block header.

5. What are the different types of Oracle enqueues?

Oracle enqueues are always specified in the form of a 2-digit ID. Userenqueues and system enqueues are differentiated as follows:

o User enqueues:

- TX (transaction enqueue): This enqueue type occurs if you wantto change a data record but you cannot do this because atransaction is running in parallel (for example, because thetransaction changed the same data record because a unique orprimary constraint cannot be guaranteed or because a free ITLslot is no longer available in the block header). The TXenqueue occurs most frequently in the SAP environment. Asession only ever holds one TX enqueue - even if several datarecords of one or several tables are changed.

- TM (DML enqueue): This enqueue type occurs if a complete objecthas to be protected against changes (for example, as part of anindex rebuild or a consistency check using VALIDATE STRUCTURE).Whenever a TX enqueue blocks table entries, a TM enqueue isalso set so that parallel activities such as index rebuilds orconsistency checks are not possible. ONE TM enqueue is set foreach transaction and changed object.

- UL (user-defined enqueue): A transaction has set an enqueueusing DBMS_LOCK.REQUEST (this is not used in the standard SAPsystem).

o System enqueues:

- ST (space transaction enqueue): This enqueue is held indictionary-managed tablespaces within extent allocations andreleases.

- CI (Cross instance call invocation enqueue)

- TT (Temporary table enqueue)

- US (Undo segment enqueue)

- CF (Control file enqueue)

- TC (Thread checkpoint enqueue)

- RO (Reuse object enqueue)

- ...

However, there are numerous other system enqueues which are generallynegligible because system enqueues are only held for a very shorttime.

As of Oracle 10g, the table V$LOCK_TYPE contains an overview of all

05.05.2013 Page 4 of 22


enqueues that exist.

6. Which Oracle parameters play a role in the enqueue environment?

o DML_LOCKS

The DML_LOCKS parameter specifies the maximum number of requests ofTM enqueues that may be active simultaneously. If the limit isreached, ORA-00055 occurs (see Note 398927).

o ENQUEUE_RESOURCES

The ENQUEUE_RESOURCES parameter specifies the maximum total numberof enqueue requests that may be active simultaneously. If the limitis reached, ORA-00052 occurs.

To determine which limits are defined, what the previous highest levelwas and how many requests are currently active, you can execute thefollowing SELECT on V$RESOURCE_LIMIT:

SELECT * FROM V$RESOURCE_LIMITWHERE RESOURCE_NAME IN ('dml_locks', 'enqueue_resources');

7. In which modes can I hold or request an enqueue?

- 0: Enqueue is not held or requested

- 1: null (NULL)

- 2: row-S (SS)

- 3: row-X (SX)

- 4: share (S)

- 5: S/Row-X (SSX)

- 6: exclusive (X)

8. How do I find out which sessions are currently holding enqueues orwaiting for enqueues?

The V$SESSION_WAIT view or the Oracle session overview (transactionST04 "Detail Analysis Menu -> Oracle Session") displays the wait event"enqueue" (Oracle 9i or lower) or "enq: <type> - <description>"(Oracle 10g or higher) if a session is waiting for an enqueue (seeNote 619188).

The V$LOCK Oracle view contains all information about sessions thathold or wait for an enqueue:

o SID: SID of the Oracle session that holds the enqueue or waits forit

o Associated Type: Enqueue type

o ID1, ID2: Enqueue-dependent lock IDs

05.05.2013 Page 5 of 22


TM enqueue -> ID1 = Object ID of the locked object

o LMODE: Mode of the held enqueues

o REQUEST: Mode of the requested enqueues

o CTIME: Time in current mode (in seconds), that is, hold or queuetime

o BLOCK: 0 -> no session waits for the enqueue; 1 -> at least onesession waits for the enqueue

For sessions that hold an enqueue, REQUEST is 0 and LMODE is higherthan 0. For sessions that wait for an enqueue, REQUEST is greater than0 and LMODE is 0. In the Oracle session overview, you can recognizethe sessions that wait for an enqueue (REQUEST > 0) by the fact thatthey wait for an "enqueue" wait event.

You can identify sessions that want to access the same enqueue and arethus locked by identical entries for TYPE, ID1 and ID2.

Transaction DB01 displays the current enqueue wait situationsincluding the holding and waiting shadow and client process.

9. Are permanently visible V$LOCK entries with MR, RT, TS and XR enqueuetypes critical?

These enqueues are held permanently and are not critical. The REQUESTmode is always 0, which means that a session does not have to wait forone of these enqueues.

10. How I can determine the enqueue type for which a session is currentlywaiting?

As of Oracle 10g, the enqueue type is taken directly from the name ofthe wait event.

Up to Oracle 9i, you can identify the enqueue type using DB01 orV$LOCK.

If only the current information from V$SESSION_WAIT is available (forexample, in the Oracle session overview in ST04), you can determinethe enqueue type and the request level using the first P1 wait eventparameter:

SELECT CHR(BITAND(<type>, -16777216) / 16777215) || CHR(BITAND(<type>, 16711680) / 65535) TYPE, BITAND(<type>, 65535) REQUESTFROM DUAL;

11. How I can determine how long a session has been waiting for certainenqueues since the database was started?

Up to Oracle 8I, there are no enqueue statistics accumulated since thedatabase was started.

05.05.2013 Page 6 of 22


As of Oracle 9I, this type of evaluation is possible usingV$ENQUEUE_STAT:

SELECT EQ_TYPE, CUM_WAIT_TIMEFROM V$ENQUEUE_STATWHERE CUM_WAIT_TIME > 0ORDER BY CUM_WAIT_TIME DESC;

As of Oracle 10g, the information can also be obtained fromV$SYSTEM_EVENT due to the differentiated wait event. With thefollowing SELECT, you get the ten enqueue types that are responsiblefor the highest total queue time:

SELECT * FROM(SELECT SUBSTR(EVENT, 1, 50) EVENT, TIME_WAITEDFROM V$SYSTEM_EVENTWHERE EVENT LIKE 'enq: %'ORDER BY TIME_WAITED DESC)WHERE ROWNUM <=10;

12. What are typical enqueue wait situations and what are possiblesolutions?

o TYPE is TX, REQUEST is 6

- Two transactions simultaneously access the same data record inchange mode.

If the lock is held for a longer time by the same transaction,you can determine the <upid> of the relevant R/3 work process("Client PID" column) in transaction ST04 by selecting DetailAnalysis Menu -> Oracle session". In transaction SM66, therelevant R/3 work process can be determined using <upid> ("PID"column). You can now check which action is currently processedby the R/3 work process. If this is a long-running databaseaccess, you must analyze and optimize it. If the work processis mainly held in the ABAP, you must review the program logic.If you cannot find a work process with <upid>, this is causedby the problem described in Note 20071 and you must terminatethe Oracle session.

If enqueue holders are constantly changing, you must checkwhether the number of accesses can be reduced. It the NRIVtable is frequently affected, you can reconsider buffering thenumber ranges (see Note 678501). If it proves difficult todetermine the initiating work process promptly in each case,due to the number of constantly changing enqueue holders, youcan use the following statement to determine the relevantprocesses that block other sessions but do not wait for anenqueue themselves:

SELECT S.SID ORACLE_SID, S.PROCESS CLIENT_PIDFROM V$SESSION S, V$LOCK L1 WHERE L1.TYPE = 'TX' AND L1.LMODE = 6 AND S.SID = L1.SID AND L1.BLOCK = 1AND NOT EXISTS(SELECT * FROM V$LOCK L2 WHERE

05.05.2013 Page 7 of 22


L2.TYPE = 'TX' AND L2.REQUEST > 0 AND L1.SID = L2.SID);

Enqueues on D020L and D021L and other SAP dictionary tablessuch as D345T can be triggered on the individual instances byusing different kernel patches, because the information savedin the tables depend on the kernel patch, which means thatconstant adjustments must be carried out. Make sure that theexact identical kernel patch is used on all instances.

Enqueues on D345T and D346T for older kernel patches can alsobe caused by the problems described in Note 1086678.

Note 1608273 describes a fix for enqueues on the tables D342Land D345T.

If enqueues occur on D020L and D020LINF in the batchprocessing, refer to Notes 596748, 36795, 330165 and 150353.

In the case of enqueues on D010SINF, refer to Note 356208.

In the case of enqueues on DDFTX, refer to SAP Notes 395997,1231267, 1614802, and 1702617.

Enqueues on D010SINF, DDFTX and REPOSRC may also occur in thecase of a parallel extraction according to SAP Note 412767.

Locks on REPOSRC and other tables such as DDFTX may also beassociated with the behavior described in Note 597885.

Enqueues in connection with dynpro loads and CUA loads (forexample, in tables D342L, D345T, D347T or DYNPLOA) areprevented by the functional kernel change described in Note949737. For more information, see also Note 1028360.

Enqueues on BTCCTL (or TBTCO, TST01, TST03, ...) due to SAPstandard transactions may be caused by long-running file systemaccesses that occur after the data base was changed. For moreinformation, see Note 183648.

Enqueues on the VARINUM table are often triggered by expensiveSQL statements on the TPRI_PAR table. Refer to Note 706478(15) and make sure that unnecessary entries are periodicallydeleted from TPRI_PAR and that TPRI_PAR is reorganised ifrequired.

If enqueues still exist after a transaction has been completed,and if secondary database connections are used, the SAP bugdescribed in Note 843042 that results in no COMMIT being sentmay be responsible.

If locks such as this occur when SMON processes are accessed inthe OBJ$ table in the RAC-environment, see Note 923099 (bugswith Oracle 9.2.0.7 or lower).

If the lock holder is mainly active in SAP report SAPLSENA, SAPenqueue problems have occurred. If this is the casee, check in

05.05.2013 Page 8 of 22


transcation SM12 if there are old enqueues that have to bedeleted. Also check, whether the enqueue logic of theapplication can be improved.

If MMON-related processes (such as M000 or M001) on Oracle10.2.0.2 wait for the TX enqueue and if (at worst) a deadlockoccurs between these processes that is not automaticallyresolved by Oracle, this may be due to Oracle bug 6057351. Thisis fixed with Oracle 10.2.0.4 or higher. As a workaround, youcan terminate the M000 or M001 process on 10.2.0.2. After theautomatic restart, the problem should no longer exist.

As of Oracle 10g, this type of TX enqueue wait is covered bythe wait event "enq: TX - row lock contention".

o TYPE is TX, REQUEST is 4

- Two transactions change data records simultaneously, which areidentical in terms of a unique or primary key constraint.

For an analysis, proceed as described above under "TYPE = TX,REQUEST = 6".

ORA-00001 errors are an additional index for this errorsituation ("unique key constraint violation") in relation tothe hanging Data Manipulation Language (DML) operations.Therefore, create an SQL trace when required, and check whetherthe long-running DML operations end with ORA-00001.

To correct this problem, ensure that the same primary key isnot inserted or changed repeatedly in parallel in a table. (forexample, by checking whether the key already exists). If thisis not possible, increase the commit-frequency in order torelease the enqueues again earlier.

As of Oracle 10g, the corresponding wait event is called "enq:TX - row lock contention".

- A session wants to access an index block for which anothersession is currently executing a leaf block split.

For a leaf block split, a new block must generally be read fromthe disk. The BLOCKING_SESSION therefore often waits for "dbfile sequential read", while the waiting sessions are blockedby a TX enqueue.

As of Oracle 10g, the corresponding wait event is called "enq:TX - index contention".

- Several transactions want to change rows from the same block,but cannot find a free entry in the Interested Transaction list(ITL) in the block header.

If the enqueues occur in a table in connection with massivelyparallel inserts or updates, this is usually a problem to dowith accessing the Interested Transaction List (ITL) in thelock header. The solution for this requires increasing theINITRANS sufficiently, as described in Note 84348. For BW,

05.05.2013 Page 9 of 22


also refer to Note 750033 (InfoCubes) and Note 831234 (ODStables). As of the enhancements from Notes 909484 (Basis 6.20),935817 (Basis 6.40) or 936253 (Basis 7.00), INITRANS can alsobe configured by SAP.

ITL waits for parallel INSERT operations can be alleviated byincreasing the FREELISTs or FREELIST GROUPs, or by switching toASSM.

The relevant 10g Wait Event is called "enq: TX - allocate ITLentry".

- Several DML operations want to change data records in the sameblock of a bitmap index.

Changes in bitmap indexes always lead to the whole area beinglocked. If several transactions want to change the same area,row lock waits occur in level 4.

Drop the bitmap indexes before you begin with parallel loading.See also the relevant section in Note 84348 for furtherinformation.

These wait situations are logged under 10g as "enq: TX - rowlock contention".

- When you use Oracle 10g or higher, in individual cases, theevent "enq: TX - contention" is also logged. For example,this is then possible if parallel INSERTs are running and oneof these INSERTs triggered an AUTOEXTEND operation and mustwait for "Data file init write" (Note 619188). In this case,the other INSERTs wait for "enq: TX - contention". Thisevent may also occur as a secondary Wait Event in other places,for example in connection with "enq: HW - contention".

o TYPE = ST

- Very large numbers of extents are allocated or deallocated.

You can solve the problem permanently by using LMTS instead ofDMTS (refer to Notes 214995 and 659946). If you use DMTS, youmust ensure that the extents of temporary segments, tables andindexes are sufficiently big so that you can avoid largequantities of extents being allocated and deallocated.

If you use DMTS, check whether PSAPTEMP was created with asufficient extent size (as described in Note 164925 (OLTP) or359835 (BW)).

If you use DMTS, check whether there are objects with a largenumber of extents (more than 500) and a very small extent sizeand use sufficient extent sizes. This applies in particular todynamic segments that are deleted from time to time withTRUNCATE/DROP and created again (for example, in the BWenvironment). Note 666061 describes according to which rulesthe extent sizes are determined. Note 787533 contains moredetailed information about analyzing and correcting errorsregarding ST enqueues. Note 78595 contains events that you can

05.05.2013 Page 10 of 22


use to temporarily deactivate the coalescing of the SMON.

If a TEMPORARY segment that has allocated several extentsexists, outside of PSAPTEMP, this may concern a table that hasalready been dropped. If a DROP terminates, the affectedsegment is converted into a TEMPORARY segment whose extents arecleaned up in the course of SMON. If all extents are cleanedup, the temporary segment is also deleted. The same applies toindex creation: While you create an index, it only exists as atemporary segment. Only after the creation process is complete,it is converted into a permanent segment.

In the BW environment, ST enqueues can also be triggered by thelarge-scale parallel creation of segments (for example,partitions). Each segment requires at least one extent for eachparallel session. As a result, several thousand events can berequired within less than an hour, which are serialized on theST enqueue. To determine whether such a case exists, proceed asfollows:

SELECT OBJECT_NAME, CREATEDFROM DBA_OBJECTSWHERE CREATED > SYSDATE - 1 / 24;

This statement returns all segments that were created withinthe last hour. In such a case, the best solution is to changeto LMTS.

The ST enqueue problems that occur when you reorganise orallocate a large number of extents are mainly caused by poorindexdesign in the Oracle dictionary tables FET$ and UET$.However, despite the severe problems, Oracle does not find itnecessary to improve the design.

In 10g, the corresponding Wait Event is called "enq: ST -contention".

- Follow-On problem of CI enqueues

ST enqueues could also be follow-on problems of CI enqueues. STenqueues may also occurs if dictionary managed tablespaces areno longer used or if not a large number of extents isallocated. In this case, the CI enqueues must be omptimized.The ST enqueues do not pose a problem.

In 10g, the corresponding Wait Event is called "enq: ST -contention".

o TYPE = TM, REQUEST = 3

- Object lock during operations such as REBUILD INDEX or VALIDATESTRUCTURE or due to command "LOCK TABLE ... IN EXCLUSIVE MODE[NOWAIT]"

Determine the session that holds the lock and determine itsLMODE.

If LMODE = 4, the locking session currently executes an

05.05.2013 Page 11 of 22


operation such as an index rebuild or a consistency check usingVALIDATE STRUCTURE without an ONLINE flag. Terminate thisoperation, so other transactions can access the object again.

If LMODE = 3, the session that holds the lock is not the mainproblem, since several sessions can use a TM lock with mode 3at the same time and in the same table (for instance, if twotransactions change different records in the same table at thesame time). Instead, you must analyze whether there is anotherwaiter that requires a TM enqueue with REQUEST = 4 (forexample, REBUILD INDEX ONLINE, see below) and which thereforeblocks all requests in the queue lined up behind it.

In the case of LMODE = 6, the blocking session executes a DMLoperation based on PARALLEL DML and/or INSERT /*+ APPEND */. Onthis topic, note section "TYPE = TM, REQUEST = 6" below.

In 10g, the wait event is called "enq: TM - contention".


- REBUILD INDEX ONLINE or SHRINK waits due to an active TXenqueue on the corresponding table.

As described in Note 682926, a REBUILD INDEX ONLINE is onlyonline-enabled to a limited extent. You must therefore makesure that an online rebuild is only started if no long-runningtransactions are working in the relevant table. See Note 910389for information about Segment Shrinking.



- If DML operations are executed using PARALLEL DML or if data isloaded using INSERT /*+ APPEND */, the system always blocks theentire table with a TM enqueue (and not only the changed datarecords with a TX enqueue). If two sessions want to change atable at the same time using PARALLEL DML or INSERT /*+ APPEND*/, one of the sessions has to wait in the state REQUEST = 6until the other session has completed the change with COMMIT orROLLBACK.

In the SAP environment, PARALLEL DML and INSERT /*+ APPEND */are usually not used. However, in certain situations (forexample, during BRSPACE online reorganizations), thesefunctions can be used successfully. For more information, seeNote 651060.


o TYPE = US

- US enqueues (undo segment enqueues) occur in connection withthe automatic online or offline setting of undo segments by theSMON process or by other undo segment activities such as stealsand relocations of expired blocks.

05.05.2013 Page 12 of 22


- Therefore, check in the first step whether a large number ofsteals and relocations of expired undo blocks occur in periodsof critical undo segment waits. For example, you can use thescript Transactions_UndoStatistics from Note 1438410 for this(column EXP_RELOC_MB). If this is the case, increasing the undotablespace or reducing the UNDO_RETENTION time can solve thisproblem.

To reduce US enqueues, you can set the following event. Amongother things, this event suppresses the automatic offlinesetting of undo segments that are no longer required.

event="10511 trace name context forever, level 2"

If US enqueues are responsible for performance problems in theReal Application Cluster, import the latest Oracle patch set.If this does not solve the problem, create an SAP customermessage to initiate further analysis.

In 10g, the wait event is called "enq: US - contention".

o TYPE = CI

- The CI enqueue is allocated when a session executes a crossinstance call, in other words, when a background process istriggered in the Oracle instance to carry out a certain task.When a session has allocated the CI enqueue successfully, itwaits for the Wait Event "rdbms ipc reply" until the backgroundprocess issues a response. Other sessions that also require theCI enqueue must wait for it.

this means that the optimization of CI enqueues corresponds tothe optimization of "rdbms ipc reply" waits. Therefore, referto the "rdbms ipc reply" section in Note 619188.

In 10g, the wait event is called "enq: CI - contention".

o TYPE = RO

- The reuse object enqueue is used in exactly the same way as theCI enqueue in TRUNCATEs and DROPs. For this reason, refer tothe details described under "TYPE = CI".

- In Oracle 10.2.0.4, bugs such as 7385253 or 8544896 may be thecause of reuse object (RO) enqueue waits. Therefore, ensurethat a current kcb merge fix is implemented in accordance withNote 1333619.

In 10g, the wait event is called "enq: RO - fast object reuse".

o TYPE = TT

- The TT enqueue is used to avoid deadlocks in paralleltablespace operations (deleting and creating tablespaces,creating data files, tablespace point-in-time recovery,creating undo segments in the tablespace, ALTER TABLESPACE,extent allocation and deallocation in the tablespace, ...).

05.05.2013 Page 13 of 22


Such waits are understandable, for example, when a sessionexecutes a COALESCE of a DMTS (which may take a long time formany freespace fragments) and another session wants to executeanother tablespace operation, scu as ALTER TABLESPACE OFFLINE.In this case, the second session has to wait for the TTenqueue.

DBMS_SPACE_ADMIN.TABLESPACE_FIX_SEGMENT_EXTBLKS as described inSAP Note 871455 may also cause TT enqueue waits at runtime.Therefore, you should execute this command only at uncritical,off-peak times.

If an ALTER DATABASE TEMPFILE DROP hangs due to a TT enqueuethat is retained by the SMON process in Oracle 9.2.0.6 orlower, Oracle bug 3833893 is responsible. This problem has beensolved in Oracle 9.2.0.7. For more information, see Note867681.

Longer waits for the TT enqueue are generally caused by Oraclebugs. If you experience problems with this enqueue type, youshould therefore first import the latest Oracle patchset.

If the problem persists, open an SAP message.

In 10g, the wait event is called "enq: TT - contention".

o TYPE = HW

- A HW enqueue occurs if several processes are simultaneouslytrying to move the high water mark of a table. In particular,this situation can occur when there are parallel INSERToperations. In such a case, the high water mark is moved byfive blocks (in the case of several FREELISTs: five blocks foreach FREELIST) by default. If there is a large number ofparallel INSERTs, this may be insufficient. The followingoptimizations are possible:

Increase the number of FREELISTs.

Increase the _BUMP_HIGHWATER_MARK_COUNT parameter to a valuegreater than 5, which increases the high water mark by morethan five blocks and means that the HWM does not have to bechanged so often. Important: Due to possible side effects (suchas an increase in the space required), this underscoreparameter should only be adjusted after consultation with SAP.

HW enqueues may also occur when you create objects with largeinitial values, since in this case, the high water mark has tobe increased up to the INITIAL value.

When there are HW enqueues with LOB segments, check that thememory parameter PCTVERSION for the LOB segment is set to 10(percent) or lower.

If HW enqueues occur in connection with LOB segments and ASSM,this may be due to the bug described in Note 1166242.

05.05.2013 Page 14 of 22


In 10g, the wait event is called "enq: HW - contention".

o TYPE = HV

- The HV enqueue is similar to the HW enqueue; the onlydifference is that it occurs with parallel direct path INSERTs.This may be the case if BRSPACE online reorganizations are madeusing active DML parallel processing.

In 10g, the wait event is called "enq: HV - contention".

o TYPE = TC

- TC enqueue waits may occur in connection with ALTER TABLESPACEBEGIN BACKUP and when other tablespace commands such as OFFLINEor READ ONLY are used. A checkpoint is executed for theseoperations. While the DBWR writes the dirty blocks from thebuffer pool to the hard disk, the system waits for a TCenqueue. Long runtimes may be caused by a large buffer pool orpoor DBWR performance.

If massive TC enqueue waits occur, the runtime of the backupmay increase significantly as a result. However, there are noside effects on the system that is running in parallel.

If the backup takes too long because of TC enqueues, open amessage for further analysis with SAP.

A TC enqueue is also requested if, in the context of parallelquery accesses, the data on the disk is accessed directlywithout using the buffer pool. To ensure data consistency, youmust ensure that all changes to the affected segment arewritten from the buffer pool to the disk. This occurs in thecontext of a segment checkpoint, where the TC enqueue is held.

In 10g, the wait event is called "enq: TC - contention".

o TYPE = CF

- CF enqueues are control file enqueues, which occur duringparallel access to the control file. Actions that make itnecessary to access the control file can be for example, BEGINBACKUP, redolog archiving by an ARCH process, or a logfileswitch by the LGWR process. If a CF enqueue is requested withina period of 15 minutes without success, ORA-00600 [2103]occurs, and the Oracle instance may terminate (see Note658744)..

- Executing NOLOGGING operations (for example, creating aNOLOGGING index with many partitions, changing data inNOLOGGING LOBs) also results in control file accesses. Inaddition to reducing the amount of index partitions (forexample, using BW compression) or activating logging, you canalso set Oracle event 10359 to level 1 in this case to avoidcontrol file accesses. However, this means that Oracle toolssuch as RMAN no longer recognize which data files are affectedby UNRECOVERABLE operations. As of Oracle 11.2.0.2, as an

05.05.2013 Page 15 of 22


alternative to the event 10359, the official parameterDB_UNRECOVERABLE_SCN_TRACKING is available, which can be set toFALSE to prevent control file accesses. This parameter worksreliably only as of Oracle 11.2.0.3. Event 10359 can still beused if problems occur with DB_UNRECOVERABLE_SCN_TRACKING.

In "checkpoint not complete" situations (Note 79341), the LGWRprocess may wait for a long time for the CF enqueue. This is afollow-on problem. The "checkpoint not complete" situationsthat cause this problem must be corrected (Note 793113).

See Note 658744, which contains possible causes and solutionsfor CF enqueues and the ORA-00600 [2103] that are triggered byit.

CF enqueue waits may also occur during an Archiver stuck (Note391) since in such cases the ARCH process may hold the CFenqueue for a long time. In this case, CF enqueue are only afollow-on problem; after you solve the Archiver stucksituation, the enqueue waits will also disappear.

In 10g, the wait event is called "enq: CF - contention".

o TYPE = SS

- SS enqueues are sort segment enqueues. A session that mustcarry out a sorting process on the disk must first request acorresponding Sort Segment. Until this request is met, thesession waits on the Wait Event "sort segment request". Ifseveral sessions request a sort segment during this time, thesesessions wait on an SS enqueue.

The SS enqueue occurs in particular if the SMON process is verybusy and cannot respond to the incoming requests promptly. Thismay happen, for example, when it carries out large rollbackactivities.

If you encounter performance problems due to SS enqueues, youfirst have to import the most recent Oracle Patchset, sinceolder patchsets may be partially responsible for problems withSS enqueues. If the problem still occurs with a currentpatchset, open an SAP message.

In 10g, the wait event is called "enq: SS - contention".

o TYPE = FB

- The FB enqueue (format block enqueue) is retained if blocks areformatted in ASSM tablespaces (for example, in the context ofINSERT operations). Significant waiting times for this enqueuetype are generally a result of other problems, such as"logbuffer space" waits. Therefore, check whether there are alsonoticeable Wait Events during times of increased FB EnqueueWaits.

In 10g, the wait event is called "enq: FB - contention".

o TYPE = PE

05.05.2013 Page 16 of 22


- The PE enqueue (parameter enqueue) occurs if a parameter changeusing "ALTER SYSTEM SET ..." or "ALTER SESSION SET ..." isactive and other sessions are waiting for the completion ofthis change. Significant waiting times on this enqueue aregenerally connected to runtime problems during the parameterchange. You must primarily check whether there are "ALTER ...SET" commands with longer runtime and what is triggering thisincreased runtime.

In 10g, the wait event is called "enq: PE - contention".

o TYPE = TQ

- The TQ enqueue (queue table access enqueue) may occur inconnection with Data Pump activities. For more information, seeNote 1013049.

In Oracle 10g, the Wait Event is called "enq: TQ - DDLcontention".

o TYPE = PS

- The PS enqueue (Parallel Slave Synchronization Enqueue) occursfor parallel query coordinators if problems occur when settingup slaves or parsing the statement to be executed. Therefore,the PS enqueue is usually a follow-up problem and you mustinvestigate why the start of the slave has been delayed (forexample, by analyzing a wait event). For more information aboutthe parallel query, see Note 651060.

On Oracle 10g (10.2.0.3 or lower), bug 5908030 for statementssuch as INSERT ... SELECT or MERGE and the use of parallelexecution may cause a "cursor: pin X" and "enq: PS -contention" deadlock. As a workaround, you can use_KKS_USE_MUTEX_PIN = FALSE to deactivate the use of mutexes(see Note 964344).

In Oracle 10g, the Wait Event is called "enq: PS - contention".

o TYPE = UL

- The UL enqueue is set by executing DBMS_LOCK.REQUEST. Thismodule is not used in the standard SAP system, but it may occurin connection with the Oracle data pump (Note 1013049).

In Oracle 10g, the Wait Event is called "enq: UL - contention".

o TYPE = SQ

- The sequence cache enqueue is used to synchronize access toOracle sequences. Values may be increased in connection withparallelized online reorganizations, which does not usuallyrequire any major changes. If there is an RAC environmentproblem with enqueues, check if the problem is solved byimporting the current patch set. If not, open an SAP customermessage for a more thorough analysis.

05.05.2013 Page 17 of 22


In Oracle 10g, the Wait Event is called "enq: SQ - contention".

o TYPE = KO

- KO enqueues coordinate the checkpoints of several segments, forexample when you create temporary Oracle tables in STARtransformations. Increased wait times are usually a result ofpoor DBWR performance. Therefore, check the Oracle I/O behavioraccording to Note 793113.

In Oracle 10g, the Wait Event is called "enq: KO - fast objectcheckpoint".

o TYPE = SSTYPE = TS

- If segments are allocated in the temporary tablespace, the sortsegment enqueue and the temporary segment enqueue are required.There should be no significant wait times for these enqueues.Due to Oracle bug 6083815, the SMON process may allocate the TSenqueue at level 3 although the M001 process requires thisenqueue at level 6, but must wait for SMON. At the same time,M001 has already exclusively allocated the SS enqueue, andtherefore, all further PSAPTEMP requirements must permanentlywait for the SS enqueue.

- If the SS enqueue times or the TS enqueue times are long, opena message with SAP.

In Oracle 10g, the wait events are called "enq: SS -contention" and "enq: TS - contention".

o TYPE = CU

- The cursor enqueue may occur on Oracle 10.2.0.2 and 10.2.0.4 inconnection with the Oracle bug 7188932. For more information,see Note 1227227.

In Oracle 10g, the wait event is called "enq: CU - contention".

o TYPE = WF

- The "AWR Flush" enqueue occurs if several processes want towrite AWR data or ASH data from the memory to a disk andserialize themselves in doing so. For example, this may occurin RAC environments and is usually unproblematic since theprocesses that are involved, such as MMON or M00, have nodirect influence on the runtime of database queries. You canstill check whether the lock holder holds the WF enqueue toolong due to problems.

o TYPE = DX

- When you use distributed transactions, "DistributedTransaction" enqueues may occur (for example, when you use adatabase link to perform a cross-system copy of data). Bydefault, scenarios like this do not occur in the SAP

05.05.2013 Page 18 of 22


environment.

o TYPE = JI

- Waits on "enq: JI - contention" occur in connection withmaterialized view refreshes. In particular, inefficient oncommit refreshes can lead to a serialization in JI enqueues.Therefore, check and optimize the SQL statements that occur inconnection with the refreshes.

o TYPE = BF

- Waits on "enq: BF - allocation contention" occur if a parallelSQL statement bloom filter is used in the access plan ("PX JOINFILTER"). In this case, you can check whether the access can beperformed in an unparallel manner, or whether the bloom filtercan be avoided (by making changes in the access plan or theparameter _BLOOM_FILTER_ENABLED = FALSE).

13. How I can determine which tables are most responsible for TX enqueuewaits?

As of Oracle 9I, V$SEGMENT_STATISTICS contains information about TXenqueues in the application ("row lock waits") and ITL TX enqueues("ITL waits"). You can determine the top ten of the segments in termsof the following two categories as follows:

SELECT * FROM (SELECT OBJECT_NAME, SUBSTR(STATISTIC_NAME, 1, 30), VALUE FROM V$SEGMENT_STATISTICS WHERE STATISTIC_NAME = 'ITL waits' OR STATISTIC_NAME = 'row lock waits' ORDER BY VALUE DESC )WHERE ROWNUM <=10;

Note that only the NUMBER, but not the DURATION of enqueue waitsituations is recorded. Therefore, the returned objects may notactually be responsible for the longest enqueue wait situations.

As of Oracle 9i, a further indication of enqueue problems is the timeit takes to execute an SQL statement. In newer SAP releases, this canbe determined in the shared cursor cache analysis in transactions ST04or ST04N (see Note 766349). Alternatively, you can use a databasequery such as the following one to determine the SQL statements thattake the longest to be executed (times are in microseconds):

column SQLTEXT word_wrap format A43column READS wrapped format A8column ELAPEREXEC wrapped format A8column ELATIME wrapped format A8column CPUTIME wrapped format A8

SELECT * FROM(SELECT TO_CHAR(ELAPSED_TIME) ELATIME, TO_CHAR(DECODE(EXECUTIONS, 0, 0, TRUNC(ELAPSED_TIME / EXECUTIONS))) ELAPEREXEC, TO_CHAR(CPU_TIME) CPUTIME, TO_CHAR(DISK_READS) READS,

05.05.2013 Page 19 of 22


MODULE || SQL_TEXT SQLTEXT FROM V$SQL ORDER BY DECODE(EXECUTIONS, 0, 0, TRUNC(ELAPSED_TIME / EXECUTIONS)) DESC)WHERE ROWNUM <=10;

As of Oracle 10g, it is possible to determine which objects are mainlyresponsible for enqueue waits by using the V$ACTIVE_SESSION_HISTORYview for the recent past. See Note 619188 for more information.

Furthermore, as of Oracle 10g, you can determine those SQL statementsthat waited the most for wait events of type "Application". In manycases, this corresponds to the TX enqueue waits:

SELECT * FROM(SELECT ROUND(APPLICATION_WAIT_TIME / 1000000) "APPLICATION WAIT TIME (S)", SQL_ID, SQL_TEXT FROM V$SQLSTATS ORDER BY APPLICATION_WAIT_TIME DESC )WHERE ROWNUM <=10;

14. How do I find the table and the data record that is responsible for aTX enqueue?

If you identified a session that holds a TX enqueue over a long periodof time, you can use the ROW_WAIT_OBJ#, ROW_WAIT_FILE#,ROW_WAIT_BLOCK# and ROW_WAIT_ROW# columns of V$SESSION to determinethe relevant object and the relevant entry.

The following statement generates an additional SQL statement thatreturns the data record on which the session <sid> must wait due to aTX enqueue:

SELECT 'SELECT * FROM "' || O.OWNER || '"."' || O.OBJECT_NAME || '"WHERE ROWID = DBMS_ROWID.ROWID_CREATE(1, ' ||O.DATA_OBJECT_ID || ', ' || S.ROW_WAIT_FILE# || ', ' || ROW_WAIT_BLOCK# || ', ' || ROW_WAIT_ROW# || ');'FROM DBA_OBJECTS O, V$SESSION SWHERE S.ROW_WAIT_OBJ# = O.OBJECT_ID AND S.SID = <sid>;

The name of the relevant table can be taken from the statement itself.

15. How can I trace the enqueue requests of a session?

In individual cases it may make sense to analyze which enqueues arerequested by a certain activity in the process. You can obtain thisinformation (for example, during the reproduction at SQLPLUS level) byactivating the Oracle event 10704:

ALTER SESSION SET EVENTS = '10704 trace name context forever, level10';

16. Where can I find more information about Oracle enqueues?

05.05.2013 Page 20 of 22


Oracle online documentation:

Oracle9i Database Reference-> 3 Dynamic Performance (V$) Views-> V$LOCK

Oracle9i Database Performance Tuning Guide and Reference-> 22 Instance Tuning-> Wait Events-> Enqueue

Oracle10g Database Reference-> 4 Dynamic Performance (V$) Views-> V$LOCK

Oracle10g Database Performance Tuning Guide-> 10 Instance Tuning Using Performance Views-> Wait Event Statistics-> Enqueue Waits

Header Data

Release Status: Released for CustomerReleased on: 08.03.2013 15:49:48Master Language: GermanPriority: Recommendations/additional infoCategory: FAQPrimary Component: BC-DB-ORA Oracle

Secondary Components:SV-BO Backoffice Service Delivery

The Note is release-independent

Related Notes

Number Short Text

1725432 CL_CTMENU_LOAD_TEXTS and invalid program name

1702617 Timeout or deadlock on table DDFTX when generating screens

1614802 Mass activation hangs during INSERT in the table DDFTX

1608273 Deadlock on D342L and D345T

1231267 Code optimization for Master Data operations

1227227 SQL statement runs endlessly or times out (kkompr)

05.05.2013 Page 21 of 22


Number Short Text

1166242 10g: "enq: HW contention" waits for LOB Inserts in ASSM TBS

1086678 D345T updates

1028360 Locks on DYNPLOAD during parallel execution of reports

1013912 FAQ: Oracle BW performance

949737 Generating screen & CUA loads in own LUW

935817 SE14: INITRANS storage parameter not configurable (Basis 640

923099 Locking background processes SMON in RAC environment

915242 FAQ: Reverse key indexes

910389 FAQ: Oracle Segment Shrinking

909484 SE14: Storage parameter INITRANS is configurable (Basis 620)

867681 ALTER DATABASE TEMPFILE DROP hangs

843042 Oracle: Database locks for SELECT FOR UPDATE

840553 BW Oracle: TRUNCATE table slower than DELETE

831234 Deadlock ORA-00060 during parallel loading into BW ODS

825653 Oracle: Common misconceptions

821687 FAQ: Space utilization and fragmentation in Oracle

793113 FAQ: Oracle I/O configuration

787533 Bad performance/ system lockup due to enqueue waits

767414 FAQ: Oracle latches

766349 FAQ: Oracle SQL optimization

750033 INITRANS parameter for InfoCube secondary indexes

712624 High CPU consumption by Oracle

706478 Preventing Basis tables from increasing considerably

682926 Composite SAP note: Problems with "create/rebuild index"

678501 System stoppage, locks on table NRIV

666061 FAQ: Database objects, segments and extents

659946 FAQ: Temporary tablespaces

658744 Composite SAP Note: ORA-00600 [2103]

651060 FAQ: Oracle Parallel Execution

619188 FAQ: Oracle wait events

618868 FAQ: Oracle performance

596748 Simultaneous generation of selection screens in background

521264 Hang situations

412767 Lockwait for parallel extraction from Profitability Analysis

395997 DB block on DDFTX after language transport action

359835 Design of the temporary tablespace in the BW System

356208 Locks on D010SINF after transport

330165 problems due to locks on D020L and D020LINF

214995 Oracle locally managed tablespaces in the SAP environment

183648 SAPMSSY2: long runtime in background process

164925 Storage parameter of tablespace PSAPTEMP

150353 In batch mode impairment by DB locks on D020L

84348 Oracle deadlocks, ORA-00060

79341 Checkpoint not complete

78595 ORA1575 timeout waiting for space management res.

05.05.2013 Page 22 of 22


Number Short Text

36795 Locks on D020L / D020LINF in batch processing

20071 Permanent lock after connection termination

sapnote_0000745639

Documents

independent of oracle

specific enqueues

enqueues orwaiting

requested enqueue

canhave r3 enqueues

oracle resources

oracle latches

oracle parameters