Oracle8i Parallel Server Concepts and Administration
Release 8.1.5






Prev Next

Overview of Locking Mechanisms

This chapter provides an overview of Oracle Parallel Server's (OPS) internal locking mechanisms by covering the following topics:

Differentiating Oracle Locking Mechanisms

This section covers the following topics:


You must understand locking mechanisms to effectively harness parallel processing and parallel database capabilities. You can influence each type of locking by setting initialization parameters, administering the system, and by designing efficient applications. Not using locks effectively causes your system to spend so much time synchronizing shared resources that you do not achieve speedup and scaleup. Your parallel system could even suffer performance degradation.

OPS uses locks for two primary purposes:

Transaction locks implement row level locking for transaction consistency. Row level locking is supported in both single instance Oracle and OPS.

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

See Also:

For more information about Oracle locks, please refer to Chapter 8, "Integrated Distributed Lock Manager" and to Oracle8i Concepts.  

Local Locks

Figure 7-1 shows latches and enqueues: locking mechanisms that are synchronized within a single instance. These are used in single instance Oracle and in OPS whether parallel server is enabled or disabled.

Figure 7-1 Locking Mechanisms: Oracle and OPS Disabled

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


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


Enqueues are shared memory structures that serialize access to database resources. 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:

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

Certain enqueues are local to single instances when OPS is disabled. But with OPS enabled, enqueues must be maintained on a system-wide level. Enqueues are managed by the Integrated Distributed Lock Manager (IDLM).

When OPS is enabled, most local enqueues become global enqueues. This is reflected in Figure 7-1 and Figure 7-2. They appear as enqueues in the fixed tables--no distinction is made between local and global enqueues. Global enqueues are handled in a distributed fashion.


Transaction locks are simply a subset of enqueues.  

Instance Locks

Figure 7-2 illustrates the instance locks used by OPS. In OPS implementations, the status of all Oracle locking mechanisms is tracked and coordinated by the IDLM.

Figure 7-2 Locking Mechanisms: Parallel Server Enabled

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

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.

To ensure cache coherency, the IDLM handles locking only for resources accessed by more than one instance of OPS. The IDLM communicates requests for instance locks and the status of the locks between lock processes of each instance. There are several views associated with the IDLM as described in Table 7-1.

Table 7-1 IDLM Views
IDLM View Name  Content 


Lists information on blocking and blocked locks currently known to the IDLM.  


Shows all locks and their states.  


Shows all resources and their states.  

There are two type of Instance locks: Parallel Cache Management (PCM) and Non-PCM locks.

PCM Locks

PCM locks are instance locks covering one or more data blocks (table or index blocks) in the buffer cache. PCM locks do not lock rows for transactions and are implemented in two ways:

Fine grain locking  

This is the default implementation where PCM locks are assigned to blocks on a dynamic basis.  

Hashed locking  

This is where PCM locks are statically assigned to blocks in the datafiles.  

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 with relatively low contention for resources. With fine grain locking, once the block is released, the lock is released. Non-PCM locks are disowned.

Non-PCM Locks

There are many different types of non-PCM locks. These 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.


The context of OPS causes most local enqueues to become global; they can still be seen in the fixed tables and views that 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

PCM locks are typically more numerous than non-PCM locks. However, there are still enough non-PCM locks for which you must carefully plan adequate IDLM capacity. Typically 5% to 10% of locks are non-PCM. Non-PCM locks do not grow in volume the way PCM locks do.

You can control PCM locks in detail by setting initialization parameters to allocate the number desired. However, you have almost no control over non-PCM locks. You can attempt 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.

See Also:

For more information, please see Chapter 16, "Ensuring IDLM Capacity for Resources and Locks".  

The LCK Process

In OPS, the LCK process provides inter-instance locking. LCK manages most locks used by an instance and coordinates requests for those locks by other instances. LCK maintains all PCM locks, hashed or fine grain, and some of the non-PCM locks, such as row cache or library cache locks. LCK handles PCM as well as non-PCM locks.

Although instance locks are mainly handled by LCK, 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 entire instance. If a foreground process owns an instance lock, it is just for that particular process. For example, the log writer (LGWR) obtains the SCN instance lock, the database writer (DBWR) obtains the media recovery lock. The bulk of these locks, however, are handled by LCK.

Foreground processes obtain transaction locks, LCK does not. Transaction locks are associated with the session/transaction unit, not with the process.

See Also:

For more information about LCK, please refer to Oracle8i Concepts.  

The LMON and LMD0 Processes

The LMON and LMD0 processes implement the global lock management subsystem of OPS. LMON performs lock cleanup and lock invalidation after the death of an Oracle shadow process or another Oracle instance. It also reconfigures and redistributes the global locks as OPS instances are started and stopped.

The LMD0 process handles remote lock requests for global locks, that is, lock requests originating from another instance for a lock owned by the current instance. All global lock messages directed to an OPS instance are handled by the LMD0 process of that instance.

Cost of Locks

To effectively implement locks, carefully evaluate their relative expense. As a rule-of-thumb:

In general, instance locks and global enqueues have an equivalent effect on performance. When OPS is disabled, all enqueues are local. When OPS is enabled, most enqueues are global.

Table 7-2 dramatizes the relative expense of latches, enqueues, and instance locks. The elapsed time required per lock varies by system. Values used in the "Actual Time Required" column of this table are only examples.

Table 7-2 Comparing the Relative Cost of Locks
Class of Lock   Actual Time Required   Relative Time Required  


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)  

Microseconds, milliseconds, and tenths of a second may seem like negligible units of time. However, imagine the cost of locks using grossly exaggerated values such as those listed in the "Relative Time Required" column. This should make the need to carefully calibrate lock use in your systems and applications more obvious. In a large OLTP implementation, for example, you should avoid unregulated instance lock use. Imagine waiting hours or days to complete a transaction!

Stored procedures are available for analyzing the number of PCM locks an application uses if it performs particular functions. You can set values for your initialization parameters and then call the stored procedure to see the projected expenditure in terms of locks.

See Also:

For more information, please refer to Chapter 15, "Allocating PCM Instance Locks" and Chapter 16, "Ensuring IDLM Capacity for Resources and 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-3 and Table 7-4.  


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


The second lock identifier, used by the IDLM. 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 lists local and global Oracle enqueues currently held or requested by the local instance. The "lock name" is actually the name of the resource; locks are taken out against the resource.

PCM Lock Names

All PCM locks are Buffer Cache Management locks.

Table 7-3 PCM Lock Type and Name
Type  Lock Name 


Buffer Cache Management  

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


Is always BL because PCM locks are buffer locks.  


Is the block class.  


For fixed locks, ID2 is the lock element (LE) index number obtained by hashing the block address (see the V$LOCK_ELEMENT fixed view). For releasable locks, 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.

Table 7-4 Non-PCM Lock Types and Names
Type  Lock Name 


Controlfile Transaction.  


Cross-Instance Call Invocation.  




Direct Loader Index Creation.  


Database Mount.  


Distributed Recovery.  


File Set.  


Redo Log "Kick".  


Instance Number.  


Instance Recovery.  


Instance State.  


Mount Definition.  


Media Recovery.  


Library Cache Invalidation.  


Library Cache Lock.  


Library Cache Pin.  


Row Cache.  


Password File.  


Process Startup.  


Parallel Slave Synchronization.  


Redo Thread.  


System Commit Number.  




Sequence Number.  


Sequence Number Enqueue.  


Sequence Number Value.  


Space Management Transaction.  


Transaction Recovery.  


DML Enqueue.  


Temporary Segment (also Table-Space).  


Temporary Table.  




User-Defined Locks.  


User Name.  


Begin written Redo Log.  


Instance Registration Attribute Lock.  


Instance Registration Lock.  

See Also:

Please refer to the Oracle8i Reference for descriptions of non-PCM locks.  

Coordination of Locking Mechanisms by the IDLM

The IDLM component is a distributed resource manager that is internal to OPS. This section explains how the IDLM coordinates locking mechanisms that are internal to Oracle. Chapter 8, "Integrated Distributed Lock Manager" presents a detailed description of IDLM features and functions.

This section covers the following topics:

The IDLM Tracks Lock Modes

In OPS implementations, the IDLM facility maintains an inventory of Oracle instance locks and global enqueues held against system resources. The IDLM acts as a referee when conflicting lock requests arise.

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

Figure 7-3 The IDLM 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 IDLM Resources

Oracle database resources are mapped to IDLM 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 IDLM resource level; the hashing function used is dependent on GC_* parameter settings. The IDLM resource name identifies the physical resource in views such as V$LOCK.


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

Figure 7-4 Database Resource Names Corresponding to IDLM Resource Names

How IDLM Locks and Instance Locks Relate

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

As illustrated in the following conceptual diagram, the IDLM checks outstanding locks on the granted queue and determines there are already two shared locks on resource BL1,441. Since shared locks are compatible with read-only requests, the IDLM 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 IDLM Checks Status of Locks


The global lock space is cooperatively managed in distributed fashion by the LMDs of all instances.  

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

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

The IDLM Provides One Lock Per Instance on a Resource

The IDLM 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 actually have 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:

For more information, please see Chapter 10, "Non-PCM Instance Locks".  


Copyright © 1999 Oracle Corporation.

All Rights Reserved.