LMSn (Lock Monitor Services) or Global Cache Services
> LMS is most active background processes.
> Consuming significant amount of CPU time. ( 10g R2 - ensure that LMS process does not encounter the CPU starvation).
> GCS is responsible for informing an instance that its PI is no longer needed when a recent version of the block is written to disk.
> Primary job is to transport blocks across the nodes for cache-fusion requests.
> If there is a consistent-read request, the LMS process rolls back the block, makes a Consistent-Read image of the block and then ship this block across the HSI (High Speed Interconnect) to the process requesting from a remote node.
> LMS must also check constantly with the LMD background process (or our GES process) to get the lock requests placed by the LMD process.
> Each node have 2 or more LMS processes.
> GCS_SERVER_PROCESSES --> no of LMS processes specified in init. ora parameter.
> Above parameter value set based on number of cpu's ( MIN(CPU_COUNT/2,2))
> 10gR2, single CPU instance,only one LMS processes started.
> Increasing the parameter value,if global cache activity is very high.
Also called the GCS (Global Cache Services) processes.
LMDn (Lock Monitor Daemon Process) or Global Enqueue Service
> Manages requests for resources and controls access to blocks and global enqueues
> LMD process performs global lock deadlock detection.
> Also monitors for lock conversion timeouts.
> Manages lock manager service requests for GCS resources and sends the requests to a service queue to be handled by the LMSn process.
> Also sometimes referred to as the GES (Global Enqueue Service) daemon since its job is to manage the global enqueue and global resource access.
> LMD process also handles deadlock detection and remote enqueue requests.
> Remote resource requests are the requests originating from another instance.
Internal View: X$KJMDDP
LMON (Lock Monitor Processes) or Global enqueue service monitor
> It Monitors the ENTIRE cluster and Maintains GCS memory structures.
> Handles the abnormal termination of processes and instances.
> Reconfiguration of locks & resources when an instance joins or leaves the cluster are handled by LMON ( During reconfiguration LMON generate the trace files)
> Responsible for executing dynamic lock remastering every 10 mins ( Only in 10g R2 & later versions).
> LMON Processes manages the global locks & resources.
> It monitors all instances in cluster, primary for dictionary cache locks,library cache locks & deadlocks on deadlock sensitive on enqueue & resources.
> LMON also provides cluster group services.
> Also called Global enqueue service monitor.
LCKn ( Lock Process)
> Manages noncache fusion resource requests such as library, row cache, and lock requests that are local to the server.
> Manages instance resource requests & cross instance calls for shared resources.
> During instance recovery,it builds a list of invalid lock elements and validates lock elements.
> Because the LMS process handles the primary function of lock management, only a single LCK process exists in each instance.
DIAG (Diagnostic Daemon)
> Oracle 10g - this one new background processes ( New enhanced diagnosability framework).
> Regularly monitors the health of the instance.
> Also checks instance hangs & deadlocks.
> It captures the vital diagnostics data for instance & process failures.
>The operation of this daemon is automated and updates the alert log file to record the activity it performs.
Cluster ready Service Daemon (CRSD)
CRSD, or Oracle Clusterware daemon, function is to define and manage resources.
Resources have profiles that define metadata about them. This metadata is stored in the OCR.The CRS reads the OCR
The OCR information is cached inside the CRS.
CRS also starts and communicates with the RACGIMON daemon process.
Resources that are managed by the CRS include:
>Global Service Daemon(GSD) {nodeapps}
>ONS Daemon {nodeapps}
>Virtual Internet Protocol (VIP) {nodeapps}
>listeners {nodeapps}
>databases
>instances
>services
RACGIMON
Database health check monitor and performs the tasks of starting, stopping, and failover services.
Monitors the instances by reading a memory-mapped location in the SGA that is updated by the PMON process on all nodes.
Only one instance of the RACGIMON process for the entire cluster
PROCD
A process monitor that runs on hardware platforms supporting other third-party cluster managers and is present only on
hardware platforms other than Linux. Its function is to create threads for the various processors on the system and to check
if the processors are hanging. Every second, the PROCD thread wakes up and checks the processors on the system, and then goes
to sleep for about 500 ms and tries again. If it does not receive any response after n seconds, it reboots the node.
Event Management Daemon (EVMD)
> Event Manager Daemon (EVMD) propagates events through the Oracle Notification Service (ONS)
> Also scans the node callout directory and invokes callouts in reaction to detected events (e.g., node up and node down events).
> EVMD is the communication bridge between the Cluster-Ready Service Daemon (CRSD) and CSSD. [ All communications between the
CRS and CSS happen via the EVMD]
Cluster Synchronization Service (CSS)
CSS is a subcomponent of Oracle Clusterware
It maintains membership in the cluster through a special file called a voting disk
This is the first process that is started in the Oracle Clusterware stack
CSS performs the following 13 steps :-
1) CSS identifies a clustered configuration
2) Determines the location of the OCR from the ocr.loc file and reads the OCR file to determine the location of the voting disk. (This is the only time CSS needs to read the OCR file.)
3) Read voting disk to determine the number and names of members in the cluster.
4) CSS performs state changes to bring the voting disk online.
5) CSS tries to establish connection to all nodes in the cluster using the private interconnect.( local listeners are configured which are different forn normal db listeners )
6) Once connection is established between the various listeners, the node moves to an ALIVE state.
7) CSS performs a verification check on voting disk and after an acknowledgement message is received from the vote disk, the node status moves to an ACTIVE state.
8) CSS verifies the number of nodes already registered as part of the cluster by performing an active count function.
9) If no MASTER node has been established CSS authorizes the first node that attains the ACTIVE state as MASTER.
10) Oracle Clusterware performs synchronization of group/locks for the node.
11) The CSS brings other members to ALIVE state and alter on active state after BY VERIFICATION.
12) Cluster synchronization begins when the MASTER node synchronizes with the other nodes in the cluster
13) These ACTIVE nodes register with the MASTER node.