Oracle9i Real Application Clusters Concepts
Release 1 (9.0.1)

Part Number A89867-02
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback

Go to previous page Go to next page

7
Real Application Clusters Components

This chapter describes the components used for implementing Real Application Clusters. The topics in this chapter are:

Instance and Database Components for Real Application Clusters

This chapter discusses the concepts of implementation specific to Real Application Clusters from a process and component point-of-view. Each cluster database instance has its own System Global Area (SGA) and background processes common to single instances. Instances within a cluster also share or have access to all SGAs, control and datafiles, and redo logs throughout the cluster.

Other components specific to Real Application Clusters are described in the following sections. These components enable cluster database processing and facilitate internode communication.

Real Application Clusters Processes

In addition to the processes common to single instances, such as the process monitor (PMON), system monitor (SMON), and database writer (DBWR), Real Application Clusters instances have additional processes to facilitate resource sharing among nodes in a cluster.

See Also:

Oracle9i Database Concepts for more information on Oracle processes 

Several processes used by Real Application Clusters facilitate resource sharing. These work with the Global Cache Service component to manage global enqueues and resources:

When an instance starts, the LMON and LMD processes start and register with the Cluster Manager. The LMON 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 remasters outstanding Global Cache Service resources and Global Enqueue Service (GES) enqueues for the failed instance.

Foreground Global Cache Lock Element Acquisition

Foreground processes are the processes associated with user sessions. One instance communicates enqueue requests directly to remote LMD processes in other instances. Foreground processes request information such as the resource names of the enqueues they are requesting, and their requisite enqueue modes. The Global Cache Service processes the request asynchronously. The foreground process therefore waits for request completion before closing the request.

Cache Fusion Processing

To process a Cache Fusion request, a sequence of steps must be completed. Depending on the state of the enqueues and resources, multiple processes are involved. If one or more Global Cache Service Processes (LMSn) are active, then the steps are as follows:

Overview of Real Application Clusters Processes

The processes specific to Real Application Clusters and some of the processes that Oracle also uses in single instance environments appear in Figure 7-1.

Figure 7-1 Basic Elements of Real Application Clusters


Text description of sps81034.gif follows
Text description of the illustration sps81034.gif

System Change Number Processing

The System Change Number (SCN) is a logical time stamp that Oracle uses to order events within a single instance and across all instances. The main purpose of SCNs is to mark redo log entries to synchronize recovery processing. 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 Lamport SCN generation.

In single instance Oracle, the System Global Area (SGA) maintains and increments SCNs from an instance that has mounted the database in exclusive mode. In Real Application Clusters shared mode, the SCN must be maintained globally. Its implementation can vary from platform to platform. The SCN can be handled by the Global Cache Service, by the Lamport SCN generation scheme, or by using a hardware clock or dedicated SCN server.

Lamport SCN Generation

The Lamport SCN generation scheme is fast and scalable because it generates SCNs in parallel on all instances. In this scheme, all messages between instances carry SCNs. 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 7 seconds. Note that by changing this value you change the SCN generator used by the database. 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 the threshold value, then Oracle uses the lock SCN generation scheme.


Go to previous page Go to next page
Oracle
Copyright © 1996-2001, Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Home
Go To Product List
Book List
Go To Table Of Contents
Contents
Go To Index
Index

Master Index

Feedback