Oracle Technologies Blog


VOTING DISK Importance in RAC clusterware

Posted by Srikrishna Murthy Annam on March 25, 2010

VOTING DISK Importance in RAC clusterware:

One of the critical files for the Oracle Clusterware is the Voting Disk.The voting disk is generally a file (approximately 20 MB) on cluster-aware storage. The voting disk is used by the Cluster Synchronization Service (CSS) component of the clusterware to resolve network splits.

During normal processing, each node writes a disk heartbeat (updates the voting disk by writing a record to each voting disk) on a periodic basis, generally once per second. Each node also reads its kill block on a periodic basis, generally once per second. When the kill block indicates that the node has been evicted, the node exits, generally causing a node reboot.

When a cluster reconfiguration occurs, either as a result of a node joining, or a node leaving the cluster,the Cluster Synchronization Service Daemon (CSSD) monitors all configured nodes in the cluster, including those with no network heartbeat, to determine whether a node has a disk heartbeat. If a node has not written a disk heartbeat within the I/O timeout, the node is declared dead. Nodes that are of an unknown state, i.e. cannot be definitively said to be dead, and are not in the group of nodes designated to survive, are evicted, i.e. the node’s kill block is updated to indicate that it has been evicted. The I/O timeout can be calculated from the MissCount setting in the cluster.

As long as we have enough voting disks online, the node can survive, but when the number of offline voting disks is greater than or equal to the number of online voting disks, the CSS daemon is failed, generally resulting in a reboot.

Important Terms To Know:
Network Split
Disk HeartBeat
Kill Block
Node Eviction
I/O Timeout
Reboot Time
Disk Timeout


2 Responses to “VOTING DISK Importance in RAC clusterware”

  1. Gibran Khal said

    Is there a way to re-mark an OFFLINE voting file to ONLINE after the partition is once again available, i.e. in a
    scenario with voting files on 2 storage arrays and one array experiences a transient outage?


  2. learnwithme11g said

    Yes, it is possible. If you have configured multiplexed voting disks configured and if one voting disk is inaccessible, the cluster will remain available. The voting disk will be automatically brought online when access is restored. You can verify the log files located @ $GI_HOME/log//cssd/cssd.log and $GI_HOME/log//alert.log.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s