Database resources such as data blocks, index blocks, rollback segments, and the data dictionary are shared among all OPS instances. To prevent conflicts, a locking mechanism is needed to control access to these resources. The Integrated Distributed Lock Manager (IDLM) provides this locking mechanism and does the following:
Maintains a list of shared database resources
Allocates locks on these resources
Coordinates lock requests
Keeps track of granted locks on resources
Two background processes, the Lock Manager Daemon (LMD) and the Lock Monitor (LMON), together with a distributed lock area in the SGA, constitute the Integrated Distributed Lock Manager. These components are shown in Figure 6.5.
The locking status of various database resources is maintained in an area of the SGA referred to as the distributed lock area . This lock information is distributed across all OPS nodes. Each node maintains locking status for a subset of database resources. The node that maintains information on a particular database resource is called the master node for the particular resource. Lock requests by any node for a resource are referred to the master node for that resource. Distributing lock information across many nodes provides fault tolerance. If one node fails, only a subset of the lock information needs to be redistributed among the surviving nodes. Similarly, when instances are started or stopped, lock information is redistributed among the running nodes.
IDLM is one of the major differences between Oracle7 Parallel Server and Oracle8 Parallel Server. The lock management subsystem used in Oracle7 is external to Oracle and is referred to as the Distributed Lock Manager (DLM). DLM historically has been supplied by the operating system vendor as an OS component. Because each operating system vendor provided its own implementation of DLM, the functionality tended to be different on each platform. Understandably, these differences led to problems. So with the release of Oracle8, the lock management functionality has been integrated into the Oracle software. IDLM in Oracle8 provides consistency across platforms. Chapter 8 discusses the IDLM in more detail.
A standalone instance has a set of background processes, including DBWn, LGWR, SMON, PMON, CKPT, and a few other optional processes. A parallel server instance has all of these, plus a few extra processes that are specific to OPS; these are LCKn, LMDn, and LMON. Oracle8i has introduced a new process named BSP. The following sections describe these OPS-specific processes.
Each OPS instance has at least one background lock process (LCK0) to handle its locking requests, and may have as many as 10. The processes are always numbered LCK0, LCK1, and so on, up to LCK9. The LCK processes manage the locks used by an instance. They are responsible for maintaining the distributed lock area in the SGA, and for communicating with the Integrated Distributed Lock Manager.
The GC_LCK_PROCS initialization parameter controls the number of LCK processes. The default value for this parameter is 1. You can increase the number of LCK processes by increasing the value of this parameter. All instances in an OPS environment must have the same number of LCK processes and, consequently, must have the same setting for GC_LCK_PROCS. For most environments, one lock process, LCK0, is sufficient. However, you may want to start more LCK processes to improve performance if either of the following scenarios applies:
You need to manage more locks than one LCK process can handle. There is a limit to the number of locks that one LCK process can manage. The limit depends on the operating system. If more locks are required, then additional LCK processes must be started.
The LCK0 process is consuming too much CPU.
Each OPS instance has at least one Lock Manager Daemon process (LMDn). This process, which is a component of the IDLM, handles remote locking requests. Lock requests from remote instances are sent to the LMD process of the holding instance. The LMD process communicates with the LCK process to release the lock requested by the remote instance.
Each OPS instance has one Lock Monitor process (LMON). This process is responsible for cleaning up global locks in the event that an Oracle server process, or an entire instance, terminates abnormally. This is necessary, because otherwise all the resources held by the failed process or instance would remain locked as long as the database remained open.
As we’ve mentioned, lock information is distributed across all OPS instances, and each instance keeps information for a subset of locks. LMON also is responsible for redistributing global locks whenever an OPS instance is started or stopped.
The Block Server process (BSP) is required only in Oracle8i and is needed to implement cache fusion. This process is responsible for preparing a consistent read (CR) version of a block in the holding instance and then transmitting that block to the corresponding BSP process of the requesting instance over the fast interconnect, in order to maintain cache coherency.
Let’s use an example to explain how various components of OPS interact to control access to a shared database resource. For this example, let’s assume that two nodes are configured in an OPS installation. Instance 1 is updating a block in its buffer cache. Instance 2 wants to update the same block. Figure 6.6 illustrates this scenario.
With respect to this figure, the following process occurs when instance 2 needs to modify a block that is currently in the process of being modified by instance 1:
A server process in instance 2 sends a request to a local LCK process to acquire the lock on the block.
The LCK process on node 2 then communicates with IDLM to acquire the lock.
IDLM determines that the lock is currently held by instance 1. IDLM communicates to the LCK process of node 1, requesting the release of the lock.
Before instance 1 can release the lock, it must signal its DBWn process to write the block to disk.
After the block has been written to the disk, the LCK process on node 1 releases the lock and informs IDLM that the lock has been released.
IDLM then informs the LCK process on node 2 that the lock is available.
The LCK process on node 2 informs the requesting server process that it can acquire the lock.
The server process on node 2 acquires the lock, reads the block from disk, and modifies it.