The following are the additional
processes spawned for supporting the multi-instance coordination:
LMON
- The Global Enqueue Service Monitor (LMON) monitors the entire
cluster to manage the global enqueues and the resources. LMON
manages instance and process failures and the associated recovery
for the Global Cache Service (GCS) and Global Enqueue Service (GES).
In particular, LMON handles the part of recovery associated with
global resources. LMON-provided services are also known as cluster
group services (CGS)
LMDx
- The Global Enqueue Service Daemon (LMD) is the lock agent process
that manages enqueue manager service requests for Global Cache
Service enqueues to control access to global enqueues and resources.
The LMD process also handles deadlock detection and remote enqueue
requests. Remote resource requests are the requests originating from
another instance.
LMSx
- The Global Cache Service Processes (LMSx) are the processes that
handle remote Global Cache Service (GCS) messages. Real Application
Clusters software provides for up to 10 Global Cache Service
Processes. The number of LMSx varies depending on the amount of
messaging traffic among nodes in the cluster.
The LMSx handles the acquisition
interrupt and blocking interrupt requests from the remote instances
for Global Cache Service resources. For cross-instance consistent
read requests, the LMSx will create a consistent read version of the
block and send it to the requesting instance. The LMSx also controls
the flow of messages to remote instances.
LMSn
- The LMSn processes handle the blocking interrupts from the remote
instance for the Global Cache Service resources by:
* Managing the resource requests
and cross-instance call operations for the shared resources.
* Building a list of invalid
lock elements and validating the lock elements during recovery
* Handling the global lock
deadlock detection and Monitoring for the lock conversion timeouts
LCKx
- This process manages the global enqueue requests and the
cross-instance broadcast. Workload is automatically shared and
balanced when there are multiple Global Cache Service Processes (LMSx).
DIAG
? The Diagnosability Daemon monitors the health of the instance and
captures the data for instance process failures.
The following shows typical
background processes of the RAC instance named NYDB1.
$
rac-1a:NYDB1:/app/home/oracle >ps -ef | grep ora_
oracle 31136
1 0 08:45 ? 00:00:00
ora_pmon_NYDB1
oracle 31138
1 0 08:45 ? 00:00:00
ora_diag_NYDB1
oracle 31141
1 0 08:45 ? 00:00:00
ora_lmon_NYDB1
oracle 31143
1 0 08:45 ? 00:00:04
ora_lmd0_NYDB1
oracle 31145
1 0 08:45 ? 00:00:03
ora_lms0_NYDB1
oracle 31147
1 0 08:45 ? 00:00:03
ora_lms1_NYDB1
oracle 31149
1 0 08:45 ? 00:00:00
ora_mman_NYDB1
oracle 31151
1 0 08:45 ? 00:00:01
ora_dbw0_NYDB1
oracle 31153
1 0 08:45 ? 00:00:01
ora_lgwr_NYDB1
oracle 31155
1 0 08:45 ? 00:00:05
ora_ckpt_NYDB1
oracle 31157
1 0 08:45 ? 00:00:05
ora_smon_NYDB1
oracle 31159
1 0 08:45 ? 00:00:00
ora_reco_NYDB1
oracle 31161
1 0 08:45 ? 00:00:00
ora_cjq0_NYDB1
oracle 31163
1 0 08:45 ? 00:00:00
ora_d000_NYDB1
oracle 31165
1 0 08:45 ? 00:00:00
ora_s000_NYDB1
oracle 31168
1 0 08:45 ? 00:00:02
ora_lck0_NYDB1
oracle 31190
1 0 08:46 ? 00:00:00
ora_arc0_NYDB1
oracle 31193
1 0 08:46 ? 00:00:02
ora_arc1_NYDB1
oracle 31207
1 0 08:46 ? 00:00:00
ora_qmnc_NYDB1
oracle 31210
1 0 08:46 ? 00:00:07
ora_mmon_NYDB1
oracle 31213
1 0 08:46 ? 00:00:00
ora_mmnl_NYDB1
oracle 31286
1 0 08:46 ? 00:00:00
ora_q000_NYDB1
oracle 31288
1 0 08:46 ? 00:00:00
ora_q001_NYDB1
oracle 31290
1 0 08:46 ? 00:00:00
ora_q002_NYDB1
oracle 18041
1 0 20:41 ? 00:00:06
ora_j000_NYDB1
oracle 25579
1 0 23:19 ? 00:00:00
ora_pz99_NYDB1
oracle 25581
1 0 23:19 ? 00:00:00
ora_pz98_NYDB1
oracle 26703 19731
0 23:23 pts/5 00:00:00 grep ora_
$ rac-1a:NYDB1:/app/home/oracle
>