Oracle7 Parallel Server Concepts and Administrator's Guide Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index

Go to previous file in sequence Go to next file in sequence

Overview of Locking Mechanisms

This chapter provides an overview of the locking mechanisms that are internal to the parallel server. Note that the distributed lock manager (DLM) is external to the Oracle Parallel Server. The chapter is organized as follows:

Differentiating Oracle Locking Mechanisms

This section covers the following topics:


You must understand locking mechanisms if you are to effectively harness parallel processing and parallel database capabilities. You can influence each kind of locking through the way you set initialization parameters, administer the system, and design applications. If you do not use locks effectively, your system may spend so much time synchronizing shared resources that no speedup and no scaleup is achieved; your parallel system could even suffer performance degradation compared to a single instance system.

Locks are used for two main purposes in Oracle Parallel Server:

Transaction locks are used to implement row level locking for transaction consistency. Row level locking is supported in both single instance Oracle and Oracle Parallel Server.

Instance locks (also commonly known as distributed locks) guarantee cache coherency. They ensure that data and other resources distributed among multiple instances belonging to the same database remain consistent. Instance locks include PCM and non-PCM locks.

See Also: Oracle7 Server Concepts for a detailed treatment of Oracle locks.

"Distributed Lock Manager: Controlling Access to Resources" [*] for more information about locks external to Oracle.

Local Locks

Figure 7 - 1 shows latches and enqueues: locking mechanisms which are synchronized within a single instance. These are used in Oracle with or without the Parallel Server Option, in both exclusive and shared modes.

Figure 7 - 1. Locking Mechanisms: Oracle and OPS Exclusive Mode

* The mount lock is obtained for the DLM if the Parallel Server Option has been linked in to your Oracle executable.


Latches are simple, low level serialization mechanicsms to protect in-memory data structures in the SGA. Latches do not protect datafiles. They are entirely automatic, are held for a very short time, and can only be held in exclusive mode. Being local to the node, internal locks and latches do not provide internode synchronization.


Enqueues are shared memory structures which serialize access to resources in the database. These locks can be local to one instance or global to a database. They are associated with a session or transaction, and can be in any mode: shared, exclusive, protected read, protected write, concurrent read, concurrent write, or null.

Enqueues are held longer than latches, have more granularity and more modes, and protect more resources in the database. For example, if you request a table lock (a DML lock) you will receive an enqueue.

Certain enqueues are local to a single instance, in exclusive mode. But in shared mode, those enqueues can no longer be managed on the instance level: they need to be maintained on a sytem-wide level--which the DLM manages.

In shared mode, most of the local enqueues become global enqueues. This is reflected in Figure 7 - 1 and Figure 7 - 2. They will all appear as enqueues in the fixed tables--no distinction is made there between local and global enqueues. Global enqueues are handled by the DLM.

Note: Transaction locks are simply a subset of enqueues.

Instance Locks

Figure 7 - 2 illustrates the instance or "distributed" locks that come into play when Oracle Parallel Server is used in shared mode. In OPS implementations, the status of all Oracle locking mechanisms is tracked and coordinated in the DLM.

Figure 7 - 2. Locking Mechanisms: OPS Shared Mode

Instance locks (other than the mount lock) only come into existence if you start an Oracle instance in shared mode. They synchronize between instances, communicating the current status of a resource among the instances of an Oracle Parallel Server.

Instance locks are held by background processes of instances, rather than by transactions. An instance owns an instance lock that protects a resource (such as a data block or data dictionary entry) when the resource enters its SGA.

The Distributed Lock Manager, external to Oracle, handles locking only for resources accessed by more than one instance of a Parallel Server, to ensure cache coherency. The DLM communicates the requests for instance locks and the status of the locks between the lock processes of each instance.

Instance locks are of two types: parallel cache management (PCM) locks and non-PCM locks.

PCM Locks

Parallel cache management locks are instance locks that cover one or more data blocks (table or index blocks) in the buffer cache. PCM locks do not lock any rows on behalf of transactions. PCM locks are implemented in two ways:

hashed locking

This is the default implementation, in which PCM locks are statically assigned to blocks in the datafiles.

fine grain locking

In this implementation, PCM locks are assigned to blocks on a dynamic basis. Refer to your platform-specific documentation to determine whether your DLM supports fine grain locking.

With hashed locking, an instance never disowns a PCM lock unless another instance asks for it. This minimizes the overhead of instance lock operations in systems that have relatively low contention for resources. With fine grain locking, once the block is released, the lock is released. (Note that non-PCM locks are disowned.)

Non-PCM Locks

Non-PCM locks of many different kinds control access to data and control files, control library and dictionary caches, and perform various types of communication between instances. These locks do not protect datafile blocks. Examples are DML enqueues (table locks), transaction enqueues, and DDL or dictionary locks. The System Change Number (SCN), and the mount lock are global locks, not enqueues.

Note: The context of OPS causes most local enqueues to become global. These are still enqueues even when they use the DLM, and can still be seen in the fixed tables and views which show enqueues (such as V$LOCK). The V$LOCK table does not, however, show instance locks, such as SCN locks, mount locks, and PCM locks.

Many More PCM Locks Than Non-PCM Locks

Although PCM locks are typically far more numerous than non-PCM locks, there is still a substantial enough number of non-PCM locks that you must carefully plan adequate DLM capacity for them. Typically 5% to 10% of locks are non-PCM. Non-PCM locks do not grow in volume the same way that PCM locks do.

The user controls PCM locks in detail by setting initialization parameters to allocate the number desired. However, the user has almost no control over non-PCM locks. You can try to eliminate the need for table locks by setting DML_LOCKS = 0 or by using the ALTER TABLE ENABLE/DISABLE TABLE LOCK command, but other non-PCM locks will still persist.

The LCKn Processes

With the Oracle Parallel Server, up to ten Lock processes (LCK0 through LCK9) provide inter-instance locking.

LCK processes manage most of the locks used by an instance and coordinate requests for those locks by other instances. LCK processes maintain all of the PCM locks (hashed or fine grain) and some of the non-PCM locks (such as row cache or library cache locks). LCK0 will handle PCM as well as non-PCM locks. Additional lock processes, LCK1 through LCK9, are available for systems that require exceptionally high throughput of distributed lock requests; they will only handle PCM locks. Multiple LCK processes will improve recovery time and startup time.

Although instance locks are mainly handled by the LCK processes, some instance locks are directly acquired by other background or shadow foreground processes. In general, if a background process such as LCK owns an instance lock, it is for the whole instance. If a foreground process owns an instance lock, it is just for that particular process. For example, the log writer (LGWR) will get the SCN instance lock, the database writer (DBWR) will get the media recovery lock. The bulk of all these locks, however, are handled by the LCK processes.

Attention: Foreground processes obtain transaction locks--LCK processes do not. Transaction locks are associated with the session/transaction unit, not with the process.

See Also: Oracle7 Server Concepts for more information about the LCKn processes.

Cost of Locks

To effectively implement locks, you need to carefully evaluate their relative expense. As a rule of thumb, latches are cheap; local enqueues are more expensive; instance locks and global enqueues are quite expensive. In general, instance locks and global enqueues have equivalent performance impact. (In exclusive mode, all enqueues are local; in shared mode, most are global.)

Table 7 - 1 dramatizes the relative expense of latches, enqueues, and instance locks. The elapsed time required per lock will vary by system--the values used in the "Actual Time Required" column are only examples.

Class of Lock Actual Time Required Relative Time Required
Latches 1 microsecond 1 minute
Local Enqueues 1 millisecond 1000 minutes (16 hours)
Instance Locks (or Global Enqueues) 1/10 second 100,000 minutes (69 days)
Table 7 - 1. Comparing the Relative Cost of Locks

Microseconds, milliseconds, and tenths of a second all sound like negligible units of time. However, if you imagine the cost of locks using grossly exaggerated values such as those listed in the "Relative Time Required" column, you can grasp the need to carefully calibrate the use of locks in your system and applications. In a big OLTP situation, for example, unregulated use of instance locks would be impermissible. Imagine waiting hours or days to complete a transaction in real life!

See Also: "Allocating PCM Instance Locks" [*].

"Ensuring DLM Capacity for All Resources & Locks" [*].

Oracle Lock Names

This section covers the following topics:

Lock Name Format

All Oracle enqueues and instance locks are named using one of the following formats:

type ID1 ID2

or type, ID1, ID2

or type (ID1, ID2)



a two-character type name for the lock type, as described in the V$LOCK table, and listed in Table 7 - 2 and Table 7 - 3


the first lock identifier, used by the DLM. The convention for this identifier differs from one lock type to another.


the second lock identifier, used by the DLM. The convention for this identifier differs from one lock type to another.

For example, a space management lock might be named ST 1 0. A PCM lock might be named BL 1 900.

The V$LOCK table contains a list of Oracle lock types and lock identifiers.

PCM Lock Names

All PCM locks are Buffer Cache Management locks.

Code Lock Name
BL Buffer Cache Management
Table 7 - 2. PCM Lock Name

The syntax of PCM lock names is type ID1 ID2, where


is always BL (because PCM locks are buffer locks)


is the block class (described in "Classes of Blocks")


is the lock element (LE) index number obtained by hashing the block address (see the V$LOCK_ELEMENT fixed view)

In DBA fine grain locking, ID2 is the database address of the block.

Sample PCM lock names are:

BL (1, 100)

This is a data block with lock element 100.

BL (4, 1000)

This is a segment header block with lock element 1000.

BL (27, 1)

This is an undo segment header with rollback segment #10. The formula for the rollback segment is 7 + (10 * 2).

Non-PCM Lock Names

Non-PCM locks have many different names.

Type Lock Name
CF Controlfile Transaction
CI Cross-instance Call Invocation
DF Datafile
DL Direct Loader Index Creation
DM Database Mount
DX Distributed Recovery
FS File Set
KK Redo Log "Kick"
IN Instance Number
IR Instance Recovery
IS Instance State
MM Mount Definition
MR Media Recovery
IV Library Cache Invalidation
L[A-P] Library Cache Lock
N[A-Z] Library Cache Pin
Q[A-Z] Row Cache
PF Password File
PR Process Startup
PS Parallel Slave Synchronization
RT Redo Thread
SC System Commit Number
SN Sequence Number
SQ Sequence Number Enqueue
SV Sequence Number Value
ST Space Management Transaction
TA Transaction Recovery
TM DML Enqueue
TS Temporary Segment (also TableSpace)
TT Temporary Table
TX Transaction
UL User-defined Locks
UN User Name
WL Being written Redo Log
XA Instance Registration Attribute Lock
XI Instance Registration Lock
Table 7 - 3. Lock Codes and Names

See Also: "Enqueue and Lock Names" [*] for descriptions of all these non-PCM locks.

Coordination of Oracle Locking Mechanisms by the DLM

The Distributed Lock Manager (DLM) is a resource manager that is external to the Oracle Parallel Server. This section explains how the DLM coordinates locking mechanisms that are internal to Oracle. The "Distributed Lock Manager" chapter presents a detailed description of DLM features and functions.

This section covers the following topics:

The DLM Tracks Lock Modes

In OPS implementations, the Distributed Lock Manager (DLM) keeps an inventory of all the Oracle instance locks and global enqueues held against the resources of your system. It acts as a referee when conflicting lock requests arise.

In Figure 7 - 3 the DLM is represented as an inventory sheet listing resources and the current status of locks on each resource. Locks are represented as follows: S for shared mode, N for null mode, X for exclusive mode.

Figure 7 - 3. The DLM Inventory of Oracle Resources and Locks

This inventory includes all instances. For example, resource BL 1, 101 is held by three instances with shared locks and three instances with null locks. Since the table reflects up to 6 locks on one resource, at least 6 instances are evidently running on this system.

The Instance Maps Database Resources to DLM Resources

DLM resources are distinct from Oracle resources, although the two may overlap. DLM resources may correspond to Oracle resources such as tablespaces, blocks, and so on, across multiple instances.

Oracle's internal lock manager only covers a single instance. Oracle database resources in this context (a block, a lock, a tablespace) are specific to a single instance.

Oracle database resources are mapped to DLM resources, with the necessary mapping performed by the instance. For example, a hashed lock on an Oracle database block with a given data block address (such as file 2 block 10) becomes translated as a BL resource with the class of the block and the lock element number (such as BL 9 1). The data block address (DBA) is translated from the Oracle resource level to the DLM resource level; the hashing function used is dependent on GC_* parameter settings.

Note: For DBA fine grain locking, the database address is used as the second identifier, rather than the lock element number.

Figure 7 - 4. Correspondence of Database Resource Names to DLM Resource Names

How DLM Locks and Instance Locks Relate

Figure 7 - 5 illustrates the way in which DLM locks and PCM locks relate. For instance B to read the value of data at data block address x, it must first check for locks on that data. The instance translates the block's database resource name to the DLM resource name, and asks the DLM for a shared lock in order to read the data.

In the following example, the DLM checks all the outstanding locks on the granted queue and determines that there are already two shared locks on the resource BL1,441. Since shared locks are compatible with read-only requests, the DLM grants a shared lock to Instance B. The instance then proceeds to query the database to read the data at data block address x. The database returns the data.

Figure 7 - 5. The DLM Checks Status of Locks

If the required block already had an exclusive lock on it by another instance, then Instance B would have to wait for this to be released. The DLM would place on the convert queue the shared lock request from Instance B. The DLM would notify the instance when the exclusive lock was removed, and then grant its request for a shared lock.

The term DLM lock refers simply to the DLM's notations for tracking and coordinating the outstanding locks on a resource.

The DLM Provides One Lock Per Instance on a Resource

The DLM provides one lock per instance on a PCM resource. As illustrated in Figure 7 - 6, if you have a four-instance system and require a buffer lock on a single resource, you will actually end up with four locks--one per instance.

Figure 7 - 6. Resources Have One Lock Per Instance

The number of non-PCM locks may depend on the type of lock.

See Also: "Non-PCM Instance Locks" [*].

Go to previous file in sequence Go to next file in sequence
Prev Next
Copyright © 1996 Oracle Corporation.
All Rights Reserved.
Go to Product Documentation Library
Go to books for this product
Go to Contents for this book
Go to Index