Basic Hints On RAC Architecture For Oracle 9i

Nodes
Single CPU nodes are Known as uni processors. In uniform memory access (UMA) configurations, each CPU has equal access to all of the memory. These systems are known as SymmetricMulti-Processor (SMP) System. In nonuniform memory access (NUMA) system, each CPU has a pool of local memory it uses by preference, but can also access the memory assigned to other CPUs, if needed.
Interconnect
The cluster interconnect provides a physical link between the nodes of the Cluster.
Best results are achieved using high speed interconnects such as:
-> Gigabit Ethernet
-> Virtual Interface Architecture (VIA)
-> Vendor-specific, certified, Proprietary systems.
Cluster Software
Real Application Cluster software uses all the components of single instance oracle environment plus cluster software that facilitates internodes communication. The Operating system cluster software contains operating System-dependent (OSD) Cluster ware components.
Cluster Manager
A layer of software, known as the Cluster Manager, Provides a cluster wide view of the nods. The Cluster Manager Regulates cluster Membership and manager messages sent between nodes. The Node Monitor, a component of the Cluster Manager, Monitors the status of the nodes (whether they are active members of the cluster).
Real Application Clusters interacts with the Cluster Manager for its own cluster information and requirements.
Inter process Communication
The inter process communication software is the second key subcomponent of the operating system-depended OSD clusterware. The IPC layer controls messaging functions so the nodes can communicate with each other through the interconnect.
Real Application Cluster enlists the ipc to transfer messages and data blocks between instances on different nodes.
Disk Access And Shared File
All Files are created commonly except the Redo logs. Redo logs are segregated using the Parameter Thread. On Some Platforms, a quorum disk (also known as voting disk on some systems) is used by the node monitor to manage the cluster configuration. On Windows the voting disk and configuration data share the same disk resource.
If you employ a server parameter file (spfile), this must also be shared by the instances.
Global Service Daemon
The Global Services Daemon (GSD) performs manageability tasks, such as instance startup and shutdown, for clients such as the Server Control Utility (SRVCTL), the Database Configuration Assistant (DBCA), and Oracle Enterprise Manager. You must start the GSD on all the nodes in Your Real Application Clusters database so that the manageability features and these tools operate properly. However, you only need on GSD service on each node regardless of how many Real Application Clusters database installation you have.
As an example, assume you execute a SRVCTL command to stop all active instances in your Real Application Clusters database. The GSD receives your request from SRVCTL and executes the command locally on each node. Finally, The GSD returns the results to you SRVCTL Session.
Background Process
The additional process available along with the regular process are as follows:
LMON : The Global Enqueue Service Monitor
LMD : The Global Enqueue Service Daemon, typically appearing with the
process name ora_lmd0_instance on a UNIX system.
LMSn : The Global cache service processes, where n can range from zero to
nine (LMS0 to LMS9)
LCK : Typically appearing with the process name ora_lck0_instance
on a UNIX system.
DIAG : The Diagnosability Daemon.

Global Enqueue Service Monitor

An Enqueue is a memory structure that serializes access to the database resources.
The global Enqueue Service Monitor (LMON) is responsible for monitoring the entire cluster to manage global enqueues and resources. The Process ensures the LMD processes and the storage they require for global enqueue information are functioning correctly.

Global Enqueue Service Daemon
The current status of each global enqueue is maintained in as shared memory area of one of the active instances. The status indicates which instances, if any, have the right to use that resource.
Global Cache service process
The Global Cache Service Processes(LMSn) manage requests for data access across the cluster. They ensure that images of the same block can only appear in the buffer caches of two different instances if the block contents are valid for each instance.
LMSn processes coordinate block access by sending messages between an instance requesting access to a specific block to an instance holding an image of that block, if there is one. An LMSn process on the holding instance can:
-> Build a read consisten block image and ship it to the buffer cache of the requesting instance, or
-> Forward the current block image to the requesting instance.

LCK Process

The LCK process manages instance resource requests and cross-instance call operations. These are calls associated with coordinating access to dictionary and row cache objects.
Diagnosability Daemon (DIAG)
The Diagnosability Daemon captures diagnostic information related to process and instance failures. This information can be used Oracle World Wide Support to help and analyze and resolve problems with your database and instances.
The DIAG process writes its diagnostic information to files in a subdirectory of the directory specified by the initialization parameter BACKGROUN_DUMP_DEST.The subdirectories are named cdmp_timestamp, where timestatmp identifies when the subdirectory, and trace information, was written. The following is an example taken from a Solaris system.

$ ls cdmp*
cdmp_20011218004549:
pln1_arco_21550.trw pln1_lmon_21525.trw ...
pln1_lmd0_21530.trw pln1_p001_21565.trw

The Command was issued from the Background_Dump_Dest directory and shows DIAG output created at 45 minutes and 9 seconds after midnight on December 18, 2001.

The Diag process starts automatically, is not tunable, and should not be disabled or removed. It can be automatically restarted by other background processes if this becomes necessary.