6
Oracle Parallel Server Components

This chapter describes components for implementing Oracle Parallel Server. The topics in this chapter are:

• Instance and Database Components for Oracle Parallel Server

• Cache Fusion Processing and the Block Server Process

• System Change Number Processing

Instance and Database Components for Oracle Parallel Server

This chapter discusses the Oracle Parallel Server-specific concepts of implementation from a process and component point-of-view. Each Oracle Parallel Server instance has its own System Global Area and background processes common to single-instances. Each instance also has its own set of control files, data files, and redo logs. Instances within a cluster also share or have access to all System Global Areas, control and data files, and redo logs throughout the cluster.

Other Parallel Server-specific components described in the following sections. These components enable parallel processing and facilitate internode communication.

Parallel Server-Specific Processes

In addition to the processes common to single-instances, such as PMON, SMON, DBWR, and so on. Oracle Parallel Server instances have additional processes to facilitate resource sharing among nodes in a cluster.

See Also: Oracle8i Concepts for more information on Oracle processes.

Four Parallel Server-specific processes facilitate resource sharing. The first three processes work with the Distributed Lock Manager component to manage global locks and resources:

• LMON - The "Lock Monitor Process" monitors the entire cluster to manage global locks and resources. LMON manages instance and process deaths and the associated recovery for the Distributed Lock Manager. In particular, LMON handles the part of recovery associated with global locks.

• LMD - The "Lock Manager Daemon" is the lock agent process that manages lock manager service requests for Parallel Cache Management locks to control access to global locks and resources. The LMDN process also handles deadlock detection and remote lock requests. Remote lock requests are requests originating from another instance.

• LCK - The "Lock Process" manages non-Parallel Cache Management locking to coordinate shared resources and remote requests for those resources.

• BSP - The "Block Server Process" rolls back uncommitted transactions for blocks requested by cross-instance read/write requests and sends the consistent read block to the requestor.

When an instance starts, the LMON and LMDN processes start and the Distributed Lock Manager registers with the Cluster Manager. The Distributed Lock Manager de-registers with the Cluster Manager when you shut down the database.

When an instance fails while in shared mode, another instance's SMON detects the failure and recovers the failed instance. The LMON process of the instance performing recovery re-masters outstanding PCM locks for the failed instance.

Foreground Processes and Foreground Lock Acquisition

Foreground processes are the processes associated with user sessions. One instance communicates lock requests directly to remote LMD processes in other instances. Foreground processes send request information such as the resource name it is requesting a lock for and the mode in which it needs the lock. The Distributed Lock Manager processes the request asynchronously, so the foreground process waits for the request to complete before closing the request.

Overview of Oracle Parallel Server Processes

The Oracle Parallel Server-specific processes and some of the processes that Oracle also uses in single-instance environments appear in Figure 6-1.

Figure 6-1 Basic Elements of Oracle Parallel Server

Cache Fusion Processing and the Block Server Process

Cache Fusion resolves cache coherency conflicts when one instance requests a block held in exclusive mode by another instance. In such cases, Oracle transfers a consistent-read version of the block directly from the memory cache of the holding instance to the requesting instance. Oracle does this without writing the block to disk.

As mentioned, Cache Fusion uses the Block Server Process to roll back uncommitted transactions. BSP then sends the consistent read block directly to the requestor. The state of the block is consistent as of the point in time at which the request was made by the requesting instance. Figure 6-2 illustrates this process.

Cache Fusion does this only for consistent read, reader/writer requests. This greatly reduces the number of lock downgrades and the volume of inter-instance communication. It also increases the scalability of certain applications that previously were not likely Oracle Parallel Server candidates, such as OLTP and hybrid applications.

Figure 6-2 Step-by-step Cache Fusion Processing

The requestor's FG (foreground) process sends a lock request message to the master node. The requesting node, the holding node, or an entirely separate node can serve as the master node.

The LMD process of the master node forwards the lock request to the LMD process of the holding node that has an exclusive lock on the requested block.

The holding node's LMD process handles the in-coming message and requests the holding instance's BSP to prepare a consistent read copy of the requested block.

BSP prepares and sends the requested block to the requestor's FG process.

System Change Number Processing

The System Change Number (SCN) is a logical timestamp that Oracle uses to order events within a single instance and across all instances. For example, Oracle assigns an SCN to each transaction. Conceptually, there is a global serial point that generates SCNs. In practice, however, SCNs can be read and generated in parallel. One of the SCN generation schemes is called the Lamport SCN generation scheme.

In single-instance Oracle, the System Global Area maintains and increments SCNs from an instance that has mounted the database in exclusive mode. In Oracle Parallel Server shared mode, the SCN must be maintained globally. Its implementation may vary from platform to platform. The SCN may be handled by the Distributed Lock Manager, by the Lamport SCN scheme, or by using a hardware clock or dedicated SCN server.

How Lamport SCN Generation Works

The Lamport SCN generation scheme is fast and scalable because it generates SCNs in parallel on all instances. In this scheme, all messages across instances, including lock messages, piggyback SCNs. Piggybacked SCNs propagate causalities within Oracle. As long as causalities are respected in this way, multiple instances can generate SCNs in parallel, with no need for extra communication among these instances.

On most platforms, Oracle uses the Lamport SCN generation scheme when the MAX_COMMIT_PROPAGATION_DELAY is larger than a platform-specific threshold. This is generally the default. This value is typically set to seven seconds. You can examine the alert log after instance startup to see whether the Lamport SCN generation scheme is in use. If this value is smaller than seven, Oracle uses the lock SCN generation scheme?