Analysis of RAC Architecture Evolution

An analysis of the evolution of the RAC architecture from a single instance to RAC. The architecture is also built by the RAC cluster and Clusterware cluster. (1) The significant changes of SGA www.2cto.com SGA are saved by a GRD: ① PCM Lock information ② bitmap of node health status (ii) background process changes here only describes the changes of background processes on the RAC cluster ① LMON process provides the CGS and NM services to maintain RAC cluster Status (1) NM is the communication channel between the RAC cluster and the Clusterware cluster through NM, register the resources of the current node to the local Clusterware, and then pass the local Clusterware to other nodes at the same time, NM also obtains the resource status of each instance of RAC from Clusterware of other nodes. All processes of each instance of RAC are registered to Clusterware as a NM group. The LMON process acts as the group leader and obtains the Member ID, other processes register with the same ID (2) CGS Cluster Group Services. This service is mainly responsible for: bitmap in GRD records the health status of the node. 0 indicates that the node is disabled, 1 indicates regular LMON communication between nodes in normal operation to ensure the consistency of GRD Bitmap. In addition, LMON can work with the lower-level Clusterware or work independently. The RAC cluster does not always assume that the Clusterware cluster can handle the problem. If the wait times out, LMON will automatically trigger the IMR (instance membership recovery) ② LMSn process is responsible for transferring data blocks between instances ③ LMD process is responsible for coordinating the access sequence of data blocks among multiple instances ④ LCK process is responsible for concurrent access to non-cache fusion resources ⑤ the DIAG process is responsible for running instance errors and recording them to alert. in log, the GSD process is responsible for receiving USER commands from the client tool. (3) file changes: www.2cto.com ① Redo Thread. A redo thread corresponds to a Redo Thread Redo which is shared by each instance, the node that executes the recover operation must be able to access the online logs of the faulty node. In RAC, each instance is written to its own redo log, but the redo log of other instances can be read. Each instance has a thread #, different from the recovery of redo instances of other instances, you can read the global rodo when the redo media of your thread # is restored. ② Undo tablespace each instance needs a separate undo parameter sid. undo_tablespace configuration ③ spfile needs to be accessed by all nodes and should be stored on the shared Disk