|Oracle8i Parallel Server Concepts
Release 2 (8.1.6)
Part Number A76968-01
This chapter describes components for implementing Oracle Parallel Server. The topics in this chapter are:
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.
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.
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:
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 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.
The Oracle Parallel Server-specific processes and some of the processes that Oracle also uses in single-instance environments appear in Figure 6-1.
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.
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.
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?