Oracle ASM Process

Automatic Storage Management Background (ASMB) process: the ASMB process runs in the database instance that uses ASM. It is responsible for communicating with the management and storage ASM instance, providing updated statistics to the ASM instance, and providing a "Heartbeat" to the ASM instance to let the ASM instance know that it is still alive, and it is still running.

Relalance (RBAL) process: the RBAL process is also running in the database instance Using ASM. When a disk is added or removed from the ASM disk group, the RBAL process is responsible for processing the rebalance request (that is, re-distributing the load request ).

The following process appears in the Oracle RAC instance. RAC is an Oracle configuration. Multiple instances in the cluster can load and open a database, each instance runs on a separate node (usually a separate physical computer ). in this way, you can have multiple instances to access the same data file (in a full-read-write mode. RAC has two main directories:

High Availability: with Oracle RAC, if one node/computer in the cluster fails due to software, hardware, or human errors, other nodes can continue to work and access the database through other nodes. You may lose some computing power, but won't be able to access the database.

Scalability: you do not need to purchase a larger machine to handle the increasing workload (this is called vertical scaling). RAC allows you to add resources in another way, that is, add more machines (called horizontal scaling) to the cluster ). for example, you do not need to scale down your 4-core CPU to 8 or 16 CPUs by using RAC, you can choose to add another relatively inexpensive 4-CPU machine (or multiple such machines ).

The following processes are unique to the RAC environment. If they are not in the RAC environment, they cannot be seen.

Lock monitor (LMNO) process: LMON monitors all instances in the cluster and checks whether an instance has failed. This helps to recover the global lock held by the failed instance. It is also responsible for re-configuring the lock and other resources when the instance leaves or joins the cluster (the instance will leave the cluster when the instance fails, and will be added to the cluster when it is restored to online, or there may be new instances in the cluster in real time ).

Lock manager daemon (LMD) process: the LMD process processes Lock Management Service requests for global cache services (keeping block buffers consistent among instances. It is mainly used as a broker to send resource requests to a queue, which is processed by the LMSn process. LMD detects and resolves global deadlocks and monitors lock timeouts in the global environment.

Lock manager server (LMSn) process: As mentioned above, in a RAC environment, each Oracle instance runs on different machines in the cluster, they all access the same set of data files in one read/write mode. For this purpose, the cache of the SGA block must be consistent with each other. This is also one of the main goals of the LMSn process. In earlier versions of Oracle parallel server (oracle parallel server, OPS), this is achieved through ping. That is to say, if a node in the cluster needs a read consistency view of the block, and the block is locked by another node in an exclusive mode, data exchange is completed by refreshing the disk output (the block is pinged ). If you only need to read data, the ping operation will be too expensive. Now it is different. With LMSn, data exchange can be completed through a very fast cache to cache exchange on the high-speed connection of the cluster. Each instance can have up to 10 LMSn processes.

Lock (LCK0) process: the function of this process is very similar to the LMD process described above, but it processes all global resource indeed requests, not just database block buffer requests.

Diagnosability daemon (DIAG) process: DIAG can only be used in RAC environments. It monitors the overall "Health Status" of the instance and captures the information required to handle instance failures.