Oracle 10g Clusterware Daemons

First and foremost Oracle Clusterware is one of the several clusterwares that are available in the market.
In 10.1 it was known as Cluster Ready Service or CRS.
In 10.2 it was renamed Clusterware.


Oracle Clusterware consist of three primary daemons. They are:
1. Cluster Ready Service Daemon
2. Cluster Synchronization Daemon
3. EVent Monitor Daemon


Before understanding the function of these daemons we need to know the two main components of 10g clusterware. These are:
1. Oracle Cluster Register Disk
2. Voting Disk.


The OCR disk stores the OCR file, which contains configuration information about the clusterware.In simple words all the information related to the status of the various applications running on the cluster gets stored in the OCR. These applications can be listeners, Instances, Databases, Services etc. 
Similarly node membership information is stored in a quorom file in the voting disk.
Both the OCR and Voting Disk needs to be stored in the shared storage.


Now that we know what is the purpose of OCR let us learn about the EVMD and the CRSD. The EVMD regularly monitors the status of the applications at the instance level and checks against their corresponding last known status in the OCR in case there is a change in the status of the application in the instance as compared to the status recoded in the OCR then the EVMD will inform the CRSD process about the same and the CRSD will make the corresponding modification in the OCR. The CRSD process of the remote instance will pick up this change and will take the appropriate corrective action. This is known as FAN or fast application notification.

The CSSD on the other hand is concerned with the node membership notification. Let us assume that we have a two node cluster. The CSSD of each node at regular interval will inform each other of their existence and also the Voting Disk with the same information.

Now assume that one of the nodes (Node 2) goes down. Hence the CSSD of Node 2 won't be sending any update to the CSSD of Node 1 or the voting disk. When the CSSD of Node 1 realizes that it is not receiving any information from Node 2 then it will check the Voting Disk to figure out when the last update was made by Node 2. When it identifies that the update was before a certain threshold time interval it will consider that the Node 2 is no longer active and will evict the node from the cluster and make the corresponding update in the voting disk.