Disclaimer

Tuesday 7 September 2021

RAC background processes

Each instance has its own SGA, several background processes, and each instance runs on a separate machine in the cluster having its own CPU and physical memory. 

Keeping the configurations identical across all nodes in the cluster would be beneficial for easy maintenance and load balancing. 

In the following sections, we discuss the various RAC related background processes.


LMSn

The Global cache service' is multithreaded and includes block server processes (LMSn) that copy data blocks directly from the holding instance's buffer cache to the foreground process on the requesting instance. 

The LMS processes produce read consistent copies (versions) for any blocks that are being requested for consistent read by the remote instance. 

They maintain the global state of each buffer in the global cache. 

The initial number of LMSn processes is driven by the parameter GCS_SERVER_PROCESSES. 

The number of LMS processes (Table 13-1) to allocate to an instance is based on the number of CPUs on the server and is driven by the following algorithm:

If the server has between 1 to 3 CPUs, Oracle sets this parameter to value 1; and if the server has between 4 to 15 CPUs, Oracle sets this parameter to value 2





However, the method of calculating the value for this parameter changes when the number of CPUs is more than 16. 

The value is computed using the formula 2 + (CPUs/32). 

If the result includes a fraction, then the fraction is disregarded. 

That is, if you had 20 CPUs, then 2 + (20/32) would equal 2 LMS processes. 

A more specific example, on a ProLiant DL370 G6 server with 16 cores (2 physical × 8 core), the number of LMS processes will be 2 + 16/32 = 2.5. 

Because the fraction part of this value is ignored, the value is set to 2.

In an ASM instance (clustered environment), where the Cache Fusion activity is confined to the transfer of metadata information when disks are added or removed, the value of this parameter is set to 1.

Prior to Oracle Database 11g Release 2, the value of this parameter was also based on the number of CPUs; however, Oracle used a standard formula of allocating and starting one LMS process for every pair of CPUs. 

For example, for the ProLiant DL370 G6 server with 16 cores, Oracle will set the value of this parameter to 4 (4 LMS processes).Oracle supports up to 36 LMS processes (0-9 and a-z).



LMON
The global enqueue service monitor (LMON) is a background process that monitors the state and health of the RDBMS instances in the cluster. 

It communicates with the cluster monitor and initiates reconfiguration when the state of a node or instance changes. 

When a node joins or leaves the cluster, it coordinates the reconfiguration of locks and resources. 
In particular, LMON performs reconfiguration of GES and GCS resources.




LMDn

The global enqueue service deamon (LMDn) is a background process that manages enqueue requests. 

It processes incoming enqueue message requests and controls access to global enqueues. 

The LMD process also handles global deadlock detection and remote resource requests (remote resource requests are requests originating from another instance). 

Examples of enqueues encountered in a RAC environment are the following: 

1) TX—Transaction lock: will be acquired for the following reasons:

->•When a row is locked. TX Transaction lock is acquired when a transaction initiates its first change and is held until the transaction does a COMMIT or ROLLBACK. 

It is used mainly as a queuing mechanism so that other sessions can wait for the transaction to complete.

->•Every transaction that needs to modify a block requires a slot in the ITL (interested transaction list) of the block. If there are no slots in the ITL of the block, then the requesting session will wait on one of the active transaction locks.

2) IS—Instance State: can be encountered during enqueue operations to synchronize instances.


LCK0

The lock process (LCK0) manages global requests for the row cache and library cache and is responsible for  cross-instance broadcasts. 

Its major use is for the row cache and library cache and for some cross-instance calls (which are basically remote function invocations on all instances in the cluster). 

With LMD and LCK, the responsibility for global enqueues is shared between the two. 

None of them is managing the buffer cache. 

This handles all requests for resources other than data blocks.


LMHB

Global Cache/Enqueue Service Heartbeat Monitor (LMHB) was introduced in Oracle Database 11g Release 2 and monitors the heartbeat of LMON, LMD, and LMSn processes to ensure they are running normally without blocking or spinning. 


ACMS

Atomic Control File to Memory Service (ACMS) introduced in Oracle Database 11g Release 2 is an agent that contributes to ensuring distributed SGA memory updates. 

It is globally committed across SGAs on success or globally aborted/rolled back if a failure occurs. 

This coordinates consistent updates to a control file resource with its SGA counterpart on all instances in an Oracle RAC environment. 

The ACMS process works with a coordinating caller to ensure that an operation is executed on every instance in Oracle RAC despite failures. ACMS is the process in which a distributed operation is called. As a result, this process can exhibit a variety of behaviors. 

In general, ACMS is limited to small, non-blocking state changes for a limited set of cross-instance operations.


RMSn

Oracle RAC Management Processes (RMSn) introduced in Oracle Database 11g Release 2 performs manageability tasks for RAC tasks accomplished by an RMSn process when instances are added to the cluster.


RSMN

Remote Slave Monitor (RSMN) introduced in Oracle Database 11g Release 2 manages background slave process creation and communication on remote instances. 

This background process manages the creation of slave processes and the communication with their coordinators and peers. 

These background slave processes perform tasks on behalf of a coordinating process running in another cluster instance.


PING

Interconnect Latency Measurement Process (PING) assesses the latencies associated with any two instances in the cluster. 

Every few seconds, the process in one instance sends two messages to the target instance. 

One message is of size 500 bytes and the second message if of size 8KB. 

Once the message is received by the target instance, it's acknowledged indicating the health of the interconnect. 


IPC0

IPC service background process (IPC0) is a new background process introduced in Oracle Database 12c Release 1. 

It handles very high rates of incoming connect requests as well as completing reconfigurations to support basic messaging and RDMA (remote direct memory access) primitives over several transports such as UDP (User Datagram Protocol), RDS (Reliable Datagram Sockets), Infiniband, and RC (reliable connection). 


LDDn

Global Enqueue Service Daemon Helper Slave (LDDn) introduced in Oracle Database 12c Release 1, are slave processes spawned on demand by the LMDn process. 

These slaves help perform certain tasks when certain workloads start creating performance bottlenecks.



No comments:

Post a Comment

100 Oracle DBA Interview Questions and Answers

  Here are 100 tricky interview questions tailored for a Senior Oracle DBA role. These questions span a wide range of topics, including perf...