| Oracle7 Parallel Server Concepts and Administrator's Guide |  Library |
 Product |
 Contents |
 Index |
| Oracle7 Parallel Server Concepts and Administrator's Guide | Library |
Product |
Contents |
Index |
The Oracle Parallel Server uses a distributed lock manager to coordinate concurrent access to resources, such as data blocks and rollback segments, across multiple instances. Oracle Corporation has defined a DLM interface which a variety of vendors have implemented.
convert queue
If a lock request cannot be granted immediately, it is placed in the convert queue, where waiting lock requests are tracked.
Lock requests that have been granted are tracked in the granted queue.
acquisition AST
When the lock is obtained, an acquisition AST (a "wakeup call") is sent to tell the requestor that the requestor owns the lock.
When a process requests a lock on a resource, the DLM sends a blocking AST to notify processes which currently own locks on that resource in incompatible modes. (Shared and exclusive modes, for example, are incompatible.) Upon notification, owners of locks can relinquish them to permit access by the requestor.
Resource persistence is necessary for fine grain locking. Each resource in the DLM has an associated value tracked in the lock value block. If the caller of the DLM wishes to preserve this value when owners of locks on the resource die abnormally, then resource persistence is required. It ensures that the database resources protected by these locks can be recovered efficiently.
Note: Not all resource information is kept after failures, only adequate information to protect resources during recovery.
Check your operating system documentation to determine whether persistent resources are implemented in your DLM.
Figure 8 - 1. The DLM Granted and Convert Queues
The lock value block is normally an area of 16 bytes that is created when you allocate the resource in the DLM. It is a means of communicating the status of the lock between processes. For example, if process 1 owns the lock in exclusive mode, it can write some status information to the lock value block when it downconverts from X to N. When process 2 obtains the lock in exclusive mode, it will read the lock value block to obtain the last written value of the lock.
As illustrated in Figure 8 - 2, the DLM sends a blocking AST to Process 1, the owner of the shared lock, notifying it that a request for an exclusive lock is waiting. When the shared lock is relinquished by Process 1, it is converted to a null mode lock, or released.
Figure 8 - 2. Blocking AST
An acquisition AST is then sent to wake up Process 2, the requestor of the exclusive lock. The exclusive lock is granted and it is converted to the granted queue. This is illustrated in Figure 8 - 3.
Figure 8 - 3. Acquisition AST
Locks are used to obtain various rights to a resource. A lock may be initially created on a resource with no access rights granted. Later, a process will convert a lock to obtain new access rights.
Figure 8 - 4. DLM Lock Modes: Levels of Access
NL
Null mode; corresponds to Oracle null mode (N). Holding a lock at this level conveys no access rights. Typically, a lock is held at this level to indicate that a process is interested in a resource, or it is used as a place holder.
Once created, null locks ensure that the requestor always has a lock on the resource; there is no need for the DLM to be constantly creating and destroying locks when ongoing access is needed.
CR
Concurrent read mode; corresponds to Oracle sub shared mode (SS). When a lock is held at this level, the associated resource can be read in an unprotected fashion: other processes can read and write the associated resource. Note: The DLM concurrent read mode (CR) should not be confused with the consistent read buffer state (also abbreviated as CR).
CW
Concurrent write mode; corresponds to Oracle shared exclusive mode (SX). When a lock is held at this level, the associated resource can be read or written in an unprotected fashion: other processes can both read and write the resource.
PR
Protected read mode; corresponds to Oracle shared mode (S). When a lock is held at this level, no process can write the associated resource. There can be multiple processes reading the resource. This is the traditional shared lock.
In shared mode, any number of users can have simultaneous read access to the resource. Shared access is appropriate for read operations.
PW
Protected write mode; corresponds to Oracle sub-shared exclusive mode (SSX). Only one process can hold a lock at this level. This allows a process to modify a resource without allowing any other process to modify the resource at the same time. Other processes can perform unprotected reads. This is the traditional update lock.
X
| DLM Mode | Oracle Mode | Description |
| NULL | NULL | No lock is on the resource |
| CR | SS | Read; there may be writers and other readers |
| CW | SX | Write; there may be other readers and writers |
| PR | S | Read; no writers are allowed |
| PW | SSX | One writer only; there may be readers |
| EX | X | Write; no other access is allowed |
Note that the Oracle modes listed here exist only in the context of the DLM. The Oracle7 Server Reference manual lists Oracle lock mode names you will normally encounter.
When planning a parallel system, take into consideration the features supported by the DLM component, to ensure that it will adequately meet your needs.
The method of lock mastering used by your DLM has a number of implications. First, it has an impact on system performance. Oracle performance is optimized if certain locks (particularly non-PCM locks) are always mastered locally. Second, understanding how your DLM functions enables you to interpret phenomena that you will observe in your configuration. For example, if all locks are mastered on one node then all locks and resources will be created on that node during startup. This means that the second node to start up (and later nodes) must go to the first node to open the lock; you will thus observe a slower startup time for these nodes.
Three methods of lock mastering in the DLM are available:
static hashing
In static hashing the resource may be arbitrarily created on any particular node, either local or remote.
directory service
With directory service, every resource is created locally and its location is stored in a directory node from which it can be found. A process must always go first to the directory node to find out on which node the resource has been created.
dynamic mastering
With dynamic mastering a resource requested on one node is always migrated to that particular node; the system figures this out without recourse to the DLM.
Make sure that your DLM is configured to support all the resources which your application will require.
DLMs can perform deadlock detection in two ways:
distributed
In distributed deadlock detection, all deadlock sensitive locks and resources can be distributed. Deadlock detection thus becomes more expensive, because all nodes must be scanned for deadlocks.
centralized
With centralized deadlock detection, all lock requests must go to one particular node. This could mean that some users' deadlock-sensitive locks take longer to acquire (if the user does not happen to reside on the centralized deadlock node).
per-process ownership
group-based ownership
With group-based locking, ownership becomes dynamic: a single lock can be shared by two or more processes belonging to the same group. Processes in the same group can share the lock without going to the DLM grant and convert queues.
Group-based locking is an important DLM feature if you wish to use Oracle multi-threaded server (MTS) or XA library functionality.
MTS
Group-based locking is strongly recommended for Oracle MTS configurations. Without it, sessions cannot migrate between shared server processes. In addition, load balancing may be affected, especially with long running transactions.
XA libraries
With Oracle XA libraries, multiple sessions or processes can work on the transaction; they therefore need to share the same locks, even in exclusive mode. With group-based lock ownership, processes can share access to an exclusive resource.
|
Prev Next |
 Copyright © 1996 Oracle Corporation. All Rights Reserved. |
Library |
Product |
Contents |
Index |