Shulou(Shulou.com)05/31 Report--

This article mainly introduces "how to understand Oracle RAC distributed resource management". In daily operation, I believe many people have doubts about how to understand Oracle RAC distributed resource management. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful for you to answer the doubts about "how to understand Oracle RAC distributed resource management". Next, please follow the editor to study!

Because of the distributed architecture of the cluster, it is particularly necessary to share, distribute and synchronize resources through inter-process communication for distributed lock management. With the existence of this communication, after the LMD process completes communication with other instances in the cluster to lock a resource, no matter how many DLM instances fail, important information about the lock resource will not be lost. It is important to note, however, that database crash recovery (the ability to recover blocks lost in the buffer cache that aborts the instance) is not a function of DLM, and the global cache processing of blocks still uses the same "brush log before write" rule to ensure persistence. From the previous series of articles, we know that GRD or DLM is made up of GES components and GCS components, and we also have a general understanding of the process of implementing these functions (LMON, LMS, LMD, etc.). Now let's take a closer look at the function implementation and parameter tuning of these processes.

DLM exists in every instance of the cluster.

-coordinate requests between different instances and access to shared resources.

-keep a list of all locks in the cluster.

-Grant and notify processes when resources are available.

-notifies the owner of the lock when another process requests a lock.

Fault tolerance: DLM can withstand 1 node failure.

Deadlock detection: DLM detects and reports deadlocks.

LMD process:

LMD0 is the core of DLM, and LMD0 handles all locking operations and resource creation, detects deadlocks, and sends messages to other LMD0. The processing statistics for LMD0 can be viewed through two views, V$DLM_CONVERT_LOCAL and V$DLM_CONVERT_REMOTE. Statistics are controlled by the initialization parameter timed_statistics, which defaults to TRUE in the 11g version.

Assuming that the lock currently waiting on the translation queue matches the authorization queue, LMD uses the move-scan-convert process to check periodically.

The main cycle of LMD0: kjmdm

Lock db Lock:

-stop any deadlock detection: kjdddei

-Lock and reset: kjfzfcl

In the locked state, you cannot get any locks or create any new resources from DLM. Lock the entire GRD during refactoring so that you can quickly recover from a node failure.

Lock db unlock:

-detect lock conversion: kjcvscn.

-deadlock detection: kjddits / kjddscn.

-Clean the recovery domain: kjprsem.

-Update statistics: kjxstc.

-send flow control message: kjctssb.

LMON process:

From the previous series of articles, we know that the LMON process is mainly responsible for the consistency relationship (CGS) at the cluster level of the entire database, monitoring the global queues and resources of the entire cluster. According to the previous introduction to DLM cache resources and locking structure. When the cluster has resources that are no longer needed, it is placed on a free list. LMON then calls kjrchc to clear the resource's DLM cache.

The main functions used by the LMON process are as follows:

-the main cycle of LMON: kjfcln

-listen for local messages: kjcswmg

-response to the refactoring event: kjfcrfg

-clear GES cache: kjrchc

LMS process:

LMS is the most active and busiest process in the whole Cache Fusion system. It is responsible for maintaining block resource information in GRD.

The default value for the number of LMS processes determined by _ lm_lms is max (# CPU/ 4)

1. Scan for PCM resources that can be granted conversion locks.

two。 Processing the degraded conversion queue is handled by kclpbi.

3. If the message is queued and exceeds the time set by the _ side_channel_batch_timeout parameter, the flush message.

4. Handles remote messages for PCM locks.

GES resources and locks

GES resources, that is, the initial allocated quantity of non-PCM resources, can be queried by the implicit parameter _ lm_ress. If exhausted, you can request more resources in shared_pool. The initial allocation, usage and restriction information of ges resources can be obtained from the ges_ res value of v$resource_limit (SELECT * FROM V$RESOURCE_LIMITWHERE RESOURCE_NAME LIKE 'ges%';)

By default _ lm_ress=1.1 * (localres + (number_of_instance-1) * localres / number_of_instance)

Localres = processes + dlm_locks + transactions+ enqueue_resources+ db_files+7+

Parallel_max_servers * cluster_database_instance+ parallel_max_servers + cluster_database_instance+200

The initial allocation of GES resource locks can be done by querying the implicit parameter _ lm_locks. Similarly, if exhausted, you can request the allocation of more lock resources in shared_pool. The initial allocation, usage and restriction information of ges locks can be obtained through the ges_ locks value of v$resource_limit (SELECT * FROM V$RESOURCE_LIMIT WHERE RESOURCE_NAME LIKE 'ges%';)

By default, _ lm_locks= (localres+_enqueue_locks) + (number_of_instance-1 * (localres+_enqueue_locks) / number_of_instance)

Localres = processes + dlm_locks + transactions + enqueue_resources + db_files + 7 +

Parallel_max_servers * cluster_database_instance+ parallel_max_servers + cluster_database_instance+200

GCS resources and locks

GCS resources, that is, the initial allocated quantity of PCM resources, can be configured by the implicit parameter _ gcs_resources or the default max (1.1 * _ db_block_buffers,2500). If exhausted, more resources are allocated from shared_pool in increments of 1024. The initial allocation, usage and restriction information of gcs resources can be obtained through the gcs_ resources value of v$resource_limit (SELECT * FROMV$RESOURCE_LIMIT WHERE RESOURCE_NAME LIKE 'gcs%';)

The initial allocated number of GCS resource locks, that is, PCM resource locks, can be configured by the implicit parameter _ pcm_shadow_locks or the default max (1.1 * _ db_block_buffers,2500). If exhausted, more resources are allocated from shared_pool in increments of 1024. Information on the initial allocation, use and restrictions of gcs resources can be obtained from the gcs_ shadows value of v$resource_limit (SELECT * FROMV$RESOURCE_LIMIT WHERE RESOURCE_NAME LIKE 'gcs%';)

DLM process

The initial allocation of the number of DLM processes can be done by setting the implicit parameter _ lm_procs or max ((64 + 256) + (number_of_instance-1), processes) if exhausted, more resources are allocated from the shared_pool. The initial allocation, usage and restriction information of the DLM process can be obtained from the ges_ locks value of v$resource_limit (SELECT * FROM V$RESOURCE_LIMIT WHERE RESOURCE_NAME LIKE 'ges%';)

At this point, the study on "how to understand Oracle RAC distributed resource management" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.