1. Enqueue Structures

2. Objectives After completing this lesson, you should be able to
do the following:
Identify the internal resources and structures that are associated with enqueues
Explain the process of acquisition, conversion, and release of enqueues
Describe how to tune waits for enqueues
Interpret diagnostic enqueue information

3. Introduction to Oracle Lock Types
Oracle locks fall into one of the following categories:
Data Dictionary Locks (DDL)
Row cache locks
Library cache locks and pins
Data Manipulation Locks (DML)
Row locks
Table locks
Internal locks and latches
Distributed locks
Parallel Cache Management (PCM) locks
Lock Types
The Oracle server uses different types of locks to control concurrent access to data and to prevent destructive interaction between users. Throughout its operation, the Oracle server automatically acquires different types of locks at different levels of restrictiveness depending on the resource that is being locked and the operation that is being performed.
Data Dictionary Locks (DDL) protect the structure of schema objects, for example, the definitions of tables, views, and procedures.
Data Manipulation Locks (DML) protect data. Table locks protect the entire table whereas row locks protect only selected rows.
Internal locks and latches: protect internal database structures such as data files, tablespaces, or rollback segments.
Distributed locks ensure that the data and other resources that are distributed among the various instances of a Real Application Cluster remain consistent.
Parallel Cache Management locks (PCM) protect the consistency of the buffer caches in a Real Application Clusters environment.
Two kernel layers provide the services that are necessary to implement these locks:
KSQ (Kernel Service Enqueues), which is discussed in this lesson
KSL (Kernel Service Latches), which is discussed in the lesson titled “Latch Internals”
Note: The discussion of distributed and PCM locks is outside the scope of this course. Refer to the course DSI408: Real Application Clusters.

4. Enqueues
Enqueues are a service that is provided by the Kernel Service Enqueues (KSQ) layer.
Other layers that make use of this service are called client layers.
Enqueues are a locking mechanism for managing access to shared resources.
Scope can be local to one instance, or can span all instances.
Interfaces are provided to acquire, convert, and release enqueues.
If an enqueue is unavailable, the client layer can choose to wait indefinitely or with timeout.
Enqueues
Enqueues are local locks that serialize access to shared resources. Examples of shared resources are redo threads, tables, and transactions.
In a single-instance environment, the scope of any enqueue is restricted to that instance. However, with Real Application Clusters (RAC) there are still local enqueues, but there are also global enqueues which span all the instances in the database. For example, the space management enqueue (ST) is a global enqueue. Only one session can perform space management on dictionary-managed objects across all the instances of a RAC database at any given time (space management on locally managed tablespaces does not require the ST enqueue).
Acquiring an enqueue involves getting a lock on a resource for the first time. Converting a lock is the process of changing the mode from one state to another. Releasing a lock then switches the lock to a no-lock state.
The client layers of the enqueue service (higher layers of the Oracle server code) wait if they cannot acquire the lock immediately. When they make the “get” call, they can choose whether to wait indefinitely or timeout after a predetermined time.
In this class, we do not discuss any aspects of global enqueues. They are covered in DSI408: Real Application Clusters.

5. Enqueue Identifiers
Each enqueue is identified by a unique name, which is also known as the lock or resource name.
This identifier has the form <Type-ID1-ID2>:
Type is a two-character string, for example “TM.”
ID1 and ID2 are positive numbers (4 bytes).
Enqueue Identifiers
The identifiers are constrained to be of the form <Type-ID1-ID2>, where Type is a two-uppercase-character string in the A–Z range, ID1 and ID2 are 4-byte unsigned numbers.
Different clients of the enqueue service have different naming conventions for the two numbers that complete the identifier. Whatever the naming convention chosen, the resource that is being locked must be uniquely identified.
For example, a table with object ID 253 is uniquely identified by an enqueue with the name TM
The values of Type, ID1 and ID2 can be seen in the view V$LOCK.

6. Enqueue Modes Mode Null SS SX S SSX X Internal ID KSQMNULL KSQMSS
KSQMSX
KSQMS
KSQMSSX
KSQMX
Value 1 2 3 4 5 6
Description
null
subshare
subexclusive
share
share/subexclusive
exclusive
Enqueue Modes
The enqueue or lock modes in themselves have no real meaning. The true meaning of the modes is dictated by the way in which they are used by the subsystem that uses them.
For example, the transaction layer uses the enqueue system for implementing DML locks. The meaning of the locks is mapped as follows:
SS = Row Share (lock a row in shared mode)
SX = Row Exclusive (lock a row in exclusive mode)
S = Share (lock the entire table in shared mode)
SSX = Share Row Exclusive (lock the table in shared mode but a row in exclusive)
X = Exclusive (lock the entire table in exclusive mode)
Refer to the Oracle9i Database Concepts Release 2 (9.2) for a description of these lock modes.

7. Enqueue Compatibility
When a lock is held, an attempt to get another one follows these compatibility rules:
Held/Get
Null SS SX S
SSX X
Enqueue Compatibility
The generic enqueue modes are designed so that enqueue service clients can map the compatibility that they need onto them.
For example, some clients may only want exclusive locks. Others need to use the complete range of lock modes, such as the Transaction Layer for the implementation of DML locks. The important thing to note is that the generic modes, as provided by the Service Layer, have no meaning within themselves, except that they adhere to strict compatibility rules.

8. Resources and Locks
Enqueues are acquired, converted, and released by sessions (not processes).
At any given time, there may be sessions that have acquired a lock, and also sessions waiting to acquire or convert a lock.
For each enqueue there is a resource structure (ksqrs), which maintains a list of owners, waiters, and converters.
Each owner, waiter, and converter has a lock structure (ksqlk).
Resources and Locks
Enqueues, unlike latches, are acquired by a session. Because sessions can migrate between Oracle processes, it follows that the holder of an enqueue can also migrate from one process to another. The migration is simply a reassociation between a session (and its owned resources) and a process, which is tracked via state objects. For example, the Kernel Cache Threads component uses enqueues to control access to the threads of redo. Enqueues of this type are named <RT-thread#-0> where thread# is the redo thread concerned. In a system state dump, the session that is associated with the log writer process can normally be seen holding the <RT-1-0> enqueue in X mode.
Enqueues are used to control access to shared resources. Internally, these resources are represented by a resource structure. When a session requires access, it obtains a lock structure (ksqlk) and makes a request to acquire access to the resource at a specific level (mode). The lock structure is placed on one of three linked lists which hang off the resource structure. These are called the owner (ksqrsown), waiter (ksqrswat), and converter (ksqrscon) lists.

9. Resources and Locks (continued)
The lock structure is:
On the owner list if a session has acquired the lock
On the waiter list if a session is waiting to acquire the lock
On the converter list if the lock is acquired, but the session is waiting for the lock to be converted to a different mode
The lock and resource tables are allocated within the System Global Area (SGA). The total number of rows in the resource table is determined by the initialization parameter ENQUEUE_RESOURCES and the rows can be seen in X$KSQRS. Values in use are externalized in V$RESOURCE.
The total number of rows in the enqueue lock table is determined by _ENQUEUE_LOCKS and the rows can be seen in X$KSQEQ. Values in use are externalized in V$ENQUEUE_LOCK.

10. Resource Structure <TM-432-0> Owners Waiters Converters S X
Lock Structures (showing modes) S
Resource Structure
This diagram shows the resource structure, which contains the resource name and three linked lists.
The owners list contains the lock structures belonging to sessions that have acquired a lock on the resource.
The waiters list contains the lock structures belonging to sessions that currently have no lock on the resource, but want to acquire one for the first time.
The converters list contains the lock structures belonging to sessions that already have a lock in one mode and want to convert this lock to a different mode.
Lock conversions are typical of PCM locks (used in Real Application Clusters).

11. Client and Managed Enqueues
Enqueues may be of two different types:
Client enqueues
The lock structures are allocated by the client layer.
For example, DML locks (TM)
Managed enqueues
The lock structures are allocated by KSQ itself.
For example, media recovery enqueues (MR)
Client and Managed Enqueues
Enqueues can be managed enqueues or client enqueues. The difference between these two kinds of enqueues lies in the location of the lock data structure (the structure specific to a holder of a lock). In client enqueues, the client embeds the lock data structure in its own structure (a state object), whereas in managed enqueues, the KSQ layer allocates and manages the lock data structures. Therefore, sufficient space must be made available through appropriate setting of initialization parameters at startup. For this reason, managed enqueues normally have a fixed or limited number of locks associated with them.
Client or managed enqueues referred to within this lesson (and the source code) are referred to as user or system locks in the Oracle documentation.
Client or User Enqueues
TM: DML enqueue
TX: Transaction enqueue
UL: User supplied

12. Client and Managed Enqueues (continued)
Managed or System Enqueues
BL: Buffer Cache Management
CF: Controlfile Transaction
CI: Cross-instance Call Invocation
CU: Bind Enqueue
DF: Datafile
DL: Direct Loader Index Creation
DM: Database Mount
DR: Distributed Recovery
DX: Distributed TX
FS: File Set
IN: Instance Number
IR: Instance Recovery
IS: Instance State
IV: Library Cache Invalidation
JQ: Job Queue
KK: Redo Log “Kick”
L[A–P]: Library Cache Lock
MR: Media Recovery
N[A–Z]: Library Cache Pin
PF: Password File
PI: Parallel Slaves
PR: Process Startup
PS: Parallel Execution Process Synchronization
Q[A–Z]: Row Cache
RT: Redo Thread
SC: System Commit Number
SM: SMON
SQ: Sequence Number Enqueue
SR: Synchronized Replication
SS: Sort Segment
ST: Space Management Transaction
SV: Sequence Number Value
TA: Transaction Recovery
TS: Temporary Segment (also TableSpace)
TT: Temporary Table
UN: User Name
US: Undo Segment, Serialization
WL: Being Written Redo Log
XA: Instance Attribute Lock
XI: Instance Registration Lock
Note: The names of enqueues and their definitions may change from release to release.

13. State Objects
All lock structures are embedded within a state object to allow PMON to recover in the event of process failure.
Client lock structures are embedded within customized state objects, for example:
DML lock (TM) structures are embedded in a DML lock state object.
Transaction (TX) lock structures are embedded in a transaction state object.
Managed lock structures are embedded within an enqueue state object.
State Objects
All lock structures are embedded within a state object so that their information remains available even if the process dies.
This means that one can always perform a system state dump to see which enqueues are being held by which sessions and in what modes.
Depending on the type of enqueue, the information may be found on an enqueue state object or a client state object.

14. Hashing and Latching
All resource structures form part of the resource table.
To find a resource within the resource table, a hashing algorithm is used.
The resource name (<Type-ID1-ID2>) is hashed to produce an index into the table of hash buckets (ksqht).
Each hash bucket contains a linked list of resources known as a hash chain.
The hash chains are covered by one or more latches (children of the enqueue hash chains latch) that are allocated in a round-robin fashion.
Hashing and Latching
It is important that KSQ is able to find the resource structure that is associated with a particular resource name as quickly and efficiently as possible. To achieve this, a hashing algorithm is used.
The hash function converts the resource name into an index and then into an array of hash buckets. Within each bucket there is a linked list of resource objects for that particular hash value. By using this list, KSQ can quickly find the resource, or if it does not appear on the list, it can be sure that the resource structure has not yet been allocated.
One or more latches cover the hash chains. Before scanning a hash chain, the appropriate latch must be acquired.
Note: Latches and latch operations are discussed in detail in the lesson titled “Latch Internals.”

15. Hashing and Latching Hash Buckets Resource Structures
hash(<MR-3-0>) -> 5
. . . 1 2
enqueue hash chain 3 4 5 6
Hashing and Latching (continued)
The name <MR-3-0> hashes to bucket number five in this example. This means that if the resource structure has been allocated, then it must be on the hash chain that is linked with bucket five. In the example, bucket five has no resource structures, so resource <MR-3-0> does not currently exist in the system.
To access the hash buckets in the resource table, the enqueue hash chain latch must be acquired first. Latching is discussed in detail in the lesson titled “Latch Internals.”
The enqueue hash chains are analogous to the hash chains of the buffer cache. The buffer cache implementation is discussed in the lesson titled “The Buffer Cache.” 7

16. Hashing and Latching Hash Buckets Resource Structures . . . 1 2
. . . 1 2
enqueue hash chain 3 4 5
(<MR-3-0>)
hash(<TM-432-0>)->0 6
Hashing and Latching (continued)
Allocation of the new resource structure occurs under the enqueues latch. The latch is acquired by the session and held while the resource is allocated to the resource table. The new resource structure is allocated (if possible) and placed in the hash chain that is linked with bucket five.
Consider what happens when a DML Enqueue (TM lock) is requested on a table. The hashing algorithm determines that the resource structure hashes to bucket 0. The enqueue hash chain must be acquired first before accessing the hash bucket. If the resource structure exists on the hash chain, then the resource structure’s lists (owner’s, waiter’s, and converter’s) will be checked to determine whether the enqueue can be allocated. This example is further explained in the following slides on Lock Acquisition. 7
enqueues

17. Resource Free List
To enable reuse, unused resource structures are placed on a linked list, known as the resource free list.
Operations in the resource free list are covered by the enqueues latch.
Resource Free List
The unused resource structures are placed on a linked list, which is called the resource free list. When a new resource is required, the free list is used to find a structure quickly.
The resource free list is analogous to the buffer cache least recently used (LRU) algorithm.
Operations on the resource free list are covered by the enqueues latch.
Note: If the free list has substantial free resource structures (see V$RESOURCE_LIMIT), then the parameter ENQUEUE_RESOURCES may be too large.

18. Initialization Parameters
ENQUEUE_RESOURCES: resource structures
_ENQUEUE_LOCKS: enqueue lock structures
_ENQUEUE_HASH: size of hash table for resource structures
_ENQUEUE_HASH_CHAIN_LATCHES: number of latches protecting the hash chains of the resource structure
Initialization Parameters
At instance startup time, the Oracle server allocates the number of enqueues that are specified by the ENQUEUE_RESOURCES parameter. The default value of ENQUEUE_RESOURCES is calculated based on the number of database files and the values of SESSIONS and DML_LOCKS. The Oracle server automatically allocates additional enqueues from the shared pool as needed if the number that is specified by ENQUEUE_RESOURCES is exceeded.
Managed enqueue lock structures are limited by _ENQUEUE_LOCKS. Its default value is calculated based on the number of session, files, query slaves, lock processes, and cross-instance messages. You can use V$RESOURCE_LIMIT to determine the settings for the two previous parameters. Normally, the default values are sufficient. If the maximum utilization starts to approach the limit, then increase these parameters. These resources do not take much space, so you can leave some room for growth above the high watermark without affecting the system too much.
The number of hash buckets is dictated by _ENQUEUE_HASH, and its default value is calculated in a similar way to ENQUEUE_RESOURCES, taking into consideration the value of SESSIONS.
The number of hash chain latches is dictated by _ENQUEUE_HASH_CHAIN_LATCHES, defaulting to CPU_COUNT. Refer to ksq.c for the exact calculations of the default values.

19. Lock Acquisition
Lock acquisition occurs when a session gets a lock that it did not have.
A session is allowed to acquire a lock if:
There are no converters or waiters ahead of it.
The mode that is requested is compatible with the modes that are already held by other sessions.
Acquisition steps:
Locate the resource structure.
Obtain a free lock structure.
Populate it for the resource that is requested.
Link the lock structure to the resource structure.
Lock Acquisition
Acquisition is the process by which a session gets a lock on a resource for which it previously did not have one. A session is allowed to acquire a lock if:
There are no converters
There are no waiters ahead of it, and
The mode that is requested is compatible with the modes that are already held by other sessions
Otherwise, the session waits in the waiters queue.
Acquisition steps in detail:
Use the hash function to determine the linked list for the required resource.
Get the corresponding enqueue hash chain latch.
Locate the resource, or if it is not there, find a free resource structure and place it in this linked list.
Get the enqueues latch.
Obtain a free lock structure (unlink the head of the lock free list).
Populate it with the correct information for the resource that is requested.
Link the lock structure to the resource structure.
Release the enqueues latch.
Release the enqueue hash chain latch.

20. Lock Conversion
Lock conversion occurs when a session requests to change the mode of a currently held lock.
A session is allowed to convert a lock if the mode that it requests:
Is a subset of the mode that it already holds
Is compatible with the modes that are held by others
Lock Conversion
Conversion occurs when the session requests to change the mode that is currently held on a lock. Even if the mode is Null, the session is regarded as holding a lock.
A session is allowed to convert a lock if the mode that it requests:
Is a subset of the mode that it already holds, or
Is compatible with the modes that are already held by other sessions
Otherwise, the session waits in the converters queue.
For example, assume two tables that are related by a foreign key constraint (such as HR.EMPLOYEES and HR.DEPARTMENTS on DEPARTMENT_ID column). Assume that a session inserts a new department into DEPARTMENTS and then proceeds to insert employees for that department into EMPLOYEES. Before any commit, the session acquires a TX enqueue, a TM lock on DEPARTMENTS(SX), and a TM lock on EMPLOYEES(SX). Now, if the session tries to update the foreign key (in other words, the number of the department that is just inserted), the lock on EMPLOYEES is converted from SX to SSX. Instead of releasing the SX lock and acquiring the SSX one, the lock is converted because the session cannot release the SX lock even momentarily in case there is need to roll back.

21. Lock Release
A session is always allowed to free a lock that it has on a resource.
Release operation:
Locate the resource structure.
Unlink the lock structure from the resource.
Link the lock structure to the lock free list.
Post the next converter or waiter (if any).
Lock Release
Release steps in detail:
Use the hash function to determine the linked list for the required resource.
Get the corresponding enqueue hash chain latch.
Locate the resource.
Get the enqueues latch.
Unlink the lock structure from the resource.
Link the lock structure to the lock free list.
Release the enqueues latch.
Post the next converter or waiter (if any).
If possible, unlink the resource structure from the hash chain, and link it to the resource free list.
Release the enqueue hash chain latch.

22. Enqueue Operations
When a new lock is requested, the Oracle server checks the queues to verify whether the request can be granted or not.
When a lock is released or converted, the converters and waiters are also rechecked to see whether they can be acquired.
The converters queue is processed first, followed by the waiters queue.
Enqueue Operations
When a new lock request is made, the Oracle server checks if the lock is currently owned.
If it is not, the new request is granted.
If it is owned and there are waiters or converters, then the new request is placed at the bottom of the waiters queue.
If it is owned but there are no waiters or converters, then a check is made to assess if the requested mode is compatible with the currently held modes.
If it is compatible, then the new request is granted.
If it is not compatible, then the new request is placed in the waiters queue.
A converter is allowed to proceed if the mode that is requested is less restrictive than the mode that is currently held, or the mode that is requested is compatible with the modes that are held by others.
A waiter is allowed to proceed if there are no converters waiting, there are no waiters ahead in the queue, and the mode that is required is compatible with the modes that are already held.
The Oracle server also rechecks the queues every time a lock is released or converted. The converters are processed first, and then the waiters.

23. Enqueue Operations Example
<TM-432-0>
Owners
Waiters
Converters 1. S X
S->X 1 2 1 S 3 S
Owner releases lock 4
<TM-432-0>
Owners
Waiters
Converters 2. X X 1 2 S
Enqueue Operations Example
Step 1: Session 1 holds a share lock on the table with object ID 432. Because it has acquired the lock, it appears in the owners queue. However, session 1 would like to convert the lock from the current share mode to exclusive mode so that it also appears in the converters queue. Sessions 2, 3, and 4 are waiting to acquire the lock. They are all in the waiters queue.
Step 2: Because there were no other owners, session 1 is allowed to convert. Had there been other owners, session 1 would have had to wait until the other owners released their locks. After processing the converters queue, the waiters queue is processed. In this case, session 2 also requests an exclusive lock. Because this is not compatible with the lock that is held by session 1, session 2 has to wait. Sessions 3 and 4 are not even looked at because these are all first in, first out (FIFO) queues.
The state of the queues is not checked until session 1 releases its lock. 3 S
Owner releases lock 4

24. Enqueue Operations Example3.
<TM-432-0>
Owners
Waiters
Converters X S 2 3 S 4
Owner releases lock 4.
<TM-432-0>
Owners
Waiters
Converters S 3 S
Enqueue Operations Example (continued)
Step 3: When the lock is finally released by session 1, the converters queue is checked (in this case, it was empty) and then the waiters queue, in that order. Session 2 was at the head of the waiters queue, so it acquires the lock in exclusive mode. Session 3 is now at the head of the waiters queue, but since the requested mode is not compatible with the mode of the current owner (session 2), it has to wait.
Step 4: Session 2 has released the lock, so the queues are checked again. The converters queue continues to be empty, so the waiters queue is processed. Session 3 acquires the lock in share mode. The request that is made by session 4 is also in share mode, which is compatible with the lock from session 3, so it too acquires the lock. 4

25. Wait Event: Enqueue
When a session is waiting on a local enqueue, it can be found to be waiting on the enqueue wait event.
This can be seen by querying V$SESSION_WAIT as follows:
SQL> select *
2 from v$session_wait
3 where event = 'enqueue';
Wait Event: Enqueue
The parameters for this wait event have the following meaning:
P1: resource type and mode wanted
P2: ID1 of resource
P3: ID2 of resource
Query V$SYSTEM_EVENT to determine the amount of waits for the enqueue wait event:
SQL> select event, total_waits, total_timeouts
2 from v$system_event
3 where event = 'enqueue';
EVENT TOTAL_WAITS TOTAL_TIMEOUTS
enqueue

26. Wait Event: Enqueue (continued)
Query V$SYSSTAT to get enqueue statistics:
SQL> select *
2 from v$sysstat
3 where name like '%enq%';
STATISTIC# NAME CLASS VALUE
22 enqueue timeouts
23 enqueue waits
24 enqueue deadlocks
25 enqueue requests
26 enqueue conversions
27 enqueue releases
Use the following query to break down the gets and waits by lock type:
SQL> select ksqsttyp TYPE, ksqstsgt GETS, ksqstwat WAITS
2 from x$ksqst
3 where ksqstsgt > 0
4 order by ksqstwat desc;
TY GETS WAITS TX US TM CF CI CU
...
Note: The discrepancy in the number of enqueue waits between V$SYSTEM_EVENT and V$SYSSTAT is explained as follows: consecutive waits during a single attempt to get a lock are recorded as separate waits in V$SYSTEM_EVENT but only as one wait in V$SYSSTAT when the lock is finally acquired.
The discrepancy in the number of enqueue timeouts between V$SYSTEM_EVENT and V$SYSSTAT is explained as follows: each time a session finishes a wait for enqueue (3 seconds), the number of timeouts increased in V$SYSTEM_EVENT. However, the number of timeouts in V$SYSSTAT is only incremented if the entire request is aborted which occurs after 300 seconds (“ORA-51: timeout occurred while waiting for a resource”).

27. Tuning Enqueue Waits
Tuning of enqueue waits depends on the type of enqueue that is causing the waits.
Possible approaches:
Reduce the number of requests for the enqueue.
Reduce the amount of time for which the enqueue is being held.
Tuning Enqueue Waits
The tuning of enqueue waits depends greatly on the type of the enqueue that is causing the waits.
There are two possible approaches:
Reduce the number of requests for the enqueue: for example, the SQ enqueue is requested every time a process wants the next value from a sequence. However, this enqueue is not required if several values are cached in memory. So, the solution in this case would be to increase sequence caching. In another example, the ST enqueue is required for space transactions on tablespaces that are managed in the data dictionary. By moving some tablespaces to be locally managed, many space transactions do not require the ST enqueue, and therefore its contention reduces.
Reduce the amount of time for which the enqueue is being held: for example, the CF enqueue must be held during updates to the control file. The more copies of the control file there are, the more time it takes to update all of them and release the enqueue. The solution in this case is to reduce the number of control files, which may not be acceptable for your business requirements.

28. Deadlock Detection
If a lock has not been acquired or converted after waiting, then a deadlock check is made by calling ksqded().
Starting with the session that requests the lock, this function scans all the queues that are looking for the blocking session.
Recursively, the function is called again with the blocking session, and a network of dependencies is built.
A deadlock occurs when a session is revisited by the recursive call and ORA-60 is signaled.
Deadlock Detection
When the client layers request a lock, they have the option of specifying how long they want to wait for the acquisition before initiating a deadlock detection.
A call from within a function to itself is called a recursive call. Calling the function ksqded() recursively, a network of dependencies is formed with each session that is waiting and blocking another. It is possible in a situation like this for a session to end up indirectly waiting for itself. When this happens, it is called a deadlock and is signaled by “ORA-60 deadlock detected while waiting for resource.” This increments the enqueue deadlocks statistics.
Note: In a distributed environment, the Oracle server cannot distinguish between a blocking lock (one that is taking a long time to release) and a true deadlock. This is because not all the data is on the same SGA. In this case, the parameter _DISTRIBUTED_LOCK_TIMEOUT determines how long a process should wait for a distributed lock before aborting the request. The default value for this parameter is 60 seconds and the Oracle server signals “ORA-2049 timeout: distributed transaction waiting for lock” if the timeout occurs. This increments the enqueue timeouts statistics.

29. Deadlock Detection <TM-432-0> Owners Waiters Converters S X1 2
<TM-320-0>
Owners
Waiters
Converters S X 2 1
Deadlock Detection (continued)
In this simple example, session 1 gets a share lock on resource <TM-432-0> and session 2 gets an share lock on resource <TM-320-0>. Later, session 1 requests an exclusive lock on <TM-320-0> and waits. Finally, session 2 requests an exclusive lock on resource <TM-432-0> and also waits. Session 1 is indirectly waiting for itself: a deadlock!
Note: It is usual for a deadlock situation to be more complex than this illustration. In the next section, “Diagnostics,” we look at interpreting the trace file that is generated by a deadlock situation.
Refer to the following WebIV notes for further information on lock modes and deadlock interpretation: LOCK: V7/8 Lock Modes (Reference Information), What to do with “ORA-60 Deadlock Detected” Errors, and OERR: ORA 60 “deadlock detected while waiting for resource.”

30. Diagnostics: State Object Dump
Information in a State Object Dump offers significant insight on enqueues:
Lock structures are embedded within state objects and can be found in system or process state dumps.
The enqueue’s name is shown along with the mode that is held (mode) and the mode that is requested (req).
This indicates which queue it resides in:
Owner: mode only
Waiter: req only
Converter: mode and req
Diagnostics: State Object (SO) Dump
Example output from a SO dump:
(enqueue) MR DID: B
lv:
res:304c7fc, mode: S, prv: 304c804, sess: 3024c5c, proc: 301dd30
Following the (enqueue) keyword, the enqueue resource type (MR) with id1 and id2 is displayed. Also:
DID: deadlock id (fake transaction id). <instance number>-<Oracle PID>-<sequence number>
lv: 16-byte array that defines the lock value. (See sc.h and the struct scgv). Normally zeroes.
res: Address of resource

31. Diagnostics: State Object Dump (continued)
mode or req: Lock mode that is held or requested. Normally mode and req are mutually exclusive but it is possible for a process to hold a lock at one level and be requesting it at a higher level. The values of mode and req determine the list that we are on as follows:
No mode and No req = Not on a list
No mode and req = On waiter list
mode and No req = On owner list
mode and req = On converter list
prv: Previous pointer in a linked list
sess: Address of session (state object) that has acquired the resource
proc: Address of the process state object that owns the session that is given in sess

32. Diagnostics Example
When a deadlock is detected, one of the calls is terminated with the error ORA-60. This error is associated with a trace file. The following paragraphs are sections of a sample file which indicates what is happening:
Deadlock graph:
Blocker(s) Waiter(s)
Resource Name process session holds waits process session holds waits
TM-00000af X S
TM-00000af X X
TM-00000af S X
TM-00000af SSX SSX
session 10: DID A session 7: DID
session 7: DID session 9: DID
session 9: DID session 8: DID B
session 8: DID B session 10: DID A
Process State Dump:
SO: 81361a9c, type: 1, owner: 0, flag: INIT/-/-/0x00
(process) Oracle pid=10, calls cur/top: 8138ac30/8138ac30, flag: (0) -
...
SO: a4, type: 3, owner: 81361a9c, flag: INIT/-/-/0x00
(session) trans: , creator: 81361a9c, flag: (41) USR/- BSY/-/-/-/-/-
DID: A , short-term DID:
last wait for 'enqueue' seq=92 wait_time=-2
name|mode=544d0005, id1=af8, id2=0
SO: 8141c968, type: 21, owner: , flag: INIT/-/-/0x00
DML LOCK: tab=2808 flg=01 chi=0
his[0]: mod=5 spn=124
(enqueue) TM-00000AF DID: A
lv:
res:813b7780, req: SSX, prv: 813b7790, sess: a4, proc: 81361a9c
SO: 8141c798, type: 21, owner: , flag: INIT/-/-/0x00
DML LOCK: tab=2803 flg=01 chi=0
his[0]: mod=6 spn=119
(enqueue) TM-00000AF DID: A
res:813b7540, mode: X, prv: 813b7548, sess: a4, proc: 81361a9c

33. Diagnostics Example (continued)
Note: The deadlock graph shows that four sessions are in deadlock. The graph starts and finishes with session 10. This is the session that performed the deadlock detection.
Following the deadlock graph, the trace contains the process state dump for the process that is associated with session 10. The session state object shows that the last wait was for the enqueue wait event. To find out which enqueue caused the wait, the next line is interpreted as follows:
name|mode=544d0005 -> name = 544d, mode=0005
The name is two characters, so 544d is converted from hex to ascii resulting in “TM” (54 -> “T”, 4d -> “M”). So the enqueue waited for is <TM-af8-0> which corresponds to a table with object id = The mode is 5 which, as shown at the beginning of this lesson, corresponds to SSX.
Further down, there are two enqueue state objects. The first one is for resource TM-00000AF and the trace shows “req:SSX” which means this session is on the waiters queue having requested the lock in share row exclusive mode. This confirms the previous calculation.
The second one is for resource TM-00000AF but in this case, the trace shows “mode: X” meaning that the session is the owner of the lock.

34. Diagnostics: Enqueues Dump
Obtained with oradebug or the following command:
SQL> alter session set events
2 'immediate trace name enqueues level 2';
This trace allows the following levels:
Level 1: dump a summary of active resources and locks, the resource free list, and the hash table
Level >= 2: include a dump of resource structs
Level >= 3: include a dump of lock structs
Diagnostics: Enqueues Dump
Sample output of enqueues dump at level 2:
ENQUEUES
Resources: free list: [81390ea0, ], base: 81390c60,
total: 320, free: 274, lowest free: 208
Active: lock: 0, resource: 0
Global: name: ORCL
Hash: length: 111, at: c8
[813966c8,813966c8] [813966d4,813966d4] [813966e0,813966e0]
[813966ec,813966ec] [813966f8,813966f8] [ , ]
...
res identification FL NL SS SX S SSX X md link
owners converters waiters
81390c60 TM-00000af U [813967b8,813967b8] [813f09d4,813f09d4] [81390c78,81390c78] [813f0a48,813f0a48]
81390cf0 RT [813968e4,813968e4] [81390bc4,81390bc4] [81390d08,81390d08] [81390d00,81390d00]

35. Diagnostics: Enqueues Dump (continued)
The first section in the dump displays the beginning and end of the resource free list, as well as a pointer to the first used resource on the table (base). You see how this address (81390c60) corresponds to the first resource address in the table below. The resource table contains a total of 320 slots, out of which 274 are currently free. The value “lowest free” is a good indication for the tuning of ENQUEUE_RESOURCES. In this case, there are many free slots all the time (208), so that memory could be better utilized elsewhere. For more information, refer to ksqdme() in ksq.c.

36. Diagnostics: V$LOCK
V$LOCK contains a list of all the lock structures that are currently held in the system.
TYPE, ID1, and ID2, can be used to join with V$RESOURCE.
LMODE and REQUEST indicate which queue the session is waiting for, as follows:
LMODE > 0, REQUEST = 0 owner
LMODE = 0, REQUEST > 0 waiter (acquirer)
LMODE > 0, REQUEST > 0 converter
Diagnostics: V$LOCK
ADDR: address of lock state object (raw)
KADDR: address of lock (raw)
SID: identifier of session that is holding the lock (number)
TYPE: resource type (char)
ID1: resource identifier #1 (number)
ID2: resource identifier #2 (number)
LMODE: lock mode that is held (number) (=mode:)
REQUEST: lock mode that is requested (number) (=req:)
CTIME: time since current mode was granted
BLOCK: flag to indicate that this is a blocking lock
This view is based on a number of tables, but the principal one is X$KSQEQ.

37. Diagnostics: V$RESOURCE
V$RESOURCE gives a list of all the resource structures that are currently locked in the system.
Each row is associated with one or more rows in V$LOCK.
V$RESOURCE is based on X$KSQRS.
Diagnostics: V$RESOURCE
ADDR: address of resource object (raw)
TYPE: resource type (char)
ID1: resource identifier #1 (number)
ID2: resource identifier #2 (number)
Each row in V$RESOURCE is associated with one or more rows in V$LOCK. For example, if a resource such as a table is locked by three different sessions in share mode, V$LOCK displays three rows, one for each lock. However, V$RESOURCE only displays one row as there is only one resource structure involved.

38. Diagnostics: V$LOCKED_OBJECT
V$LOCKED_OBJECT shows all the locks on objects (TM locks) in the system.
Provides the following cross-reference information:
Rollback segment associated with the transaction that is run by the locking session (if any)
Username at the operating system level
Process ID
Diagnostics: V$LOCKED_OBJECT
XIDUSN: undo segment number
XIDSLOT: slot number
XIDSQN: sequence number
OBJECT_ID: object ID that is being locked
SESSION_ID: session ID
ORACLE_USERNAME: Oracle username
OS_USER_NAME: OS username
PROCESS: OS process ID
LOCKED_MODE: lock mode
When a locking conflict occurs, a database administrator must resolve the issue by committing or terminating the blocking transaction. This view assists the database administrator to make a decision on how to resolve the conflict.
This view is based on X$KTCXB (transaction control info), X$KTADM (DML lock info), and X$KSUSE (undo segment info).

39. Diagnostics: Scripts
The script catblock.sql creates the following views:
DBA_LOCKS like V$LOCK
DBA_DML_LOCKS DML (TM) locks only
DBA_DDL_LOCKS DDL locks (not enqueues!)
DBA_WAITERS waiters and converters
DBA_BLOCKERS blockers
The script utllockt.sql gives a tree of locks. It requires catblock.sql to have been run first.
Diagnostics: Scripts
Sample from utllockt.sql:
WAITING_SESSION LOCK_TYPE MODE_REQUESTED MODE_HELD LOCK_ID1 LOCK_ID2
None
DML Share Exclusive
DML Exclusive Exclusive
DML Exclusive Share
This graph is read from the bottom up: Session 8 wants an exclusive DML lock on object 2805, but it cannot have it because it is held in share mode by a blocking session. This blocking session is session 9, which wants an exclusive lock on 2807 but cannot have it because another session is already holding an exclusive lock on this object. The blocker in this case is session 7, which is requesting a share lock on 2803, but once again is blocked by an exclusive lock. Session 10 is the blocker here and is not waiting for anything.
Note: The utllockt.sql script uses SET CHARWIDTH svrmgrl command which produces a runtime error when used with SQL*Plus. See bug

40. Diagnostics: Scripts (continued)
The information from the previous example can be confirmed in V$LOCK:
SID TY ID ID LMODE REQUEST
7 TM
7 TM
8 TM
8 TM
9 TM
9 TM
10 TM

41. Summary In this lesson, you should have learned about:
Enqueue internal concepts
Enqueue operations
Acquisition
Conversion
Release
Tuning enqueues
Enqueue diagnostics
Object dumps
Data dictionary views

42. References
WebIV Note:
Source: ksq.h, ksq1.h, ksq.c