| Oracle7 Parallel Server Concepts and Administrator's Guide |  Library |
 Product |
 Contents |
 Index |
| Oracle7 Parallel Server Concepts and Administrator's Guide | Library |
Product |
Contents |
Index |
Locks are used for two main purposes in 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" ![[*]](jump.gif)
for more information about locks external to Oracle.
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.
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.
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.
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.)
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.
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.
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.
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) |
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" .
type ID1 ID2
or type, ID1, ID2
or type (ID1, ID2)
where
type
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
ID1
the first lock identifier, used by the DLM. The convention for this identifier differs from one lock type to another.
ID2
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.
| Code | Lock Name |
| BL | Buffer Cache Management |
The syntax of PCM lock names is type ID1 ID2, where
type
is always BL (because PCM locks are buffer locks)
ID1
is the block class (described in "Classes of Blocks")
ID2
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).
for descriptions of all these non-PCM locks.
This section covers the following topics:
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.
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
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.
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" .
|
Prev Next |
 Copyright © 1996 Oracle Corporation. All Rights Reserved. |
Library |
Product |
Contents |
Index |