Master in Data Analyst | Join Free Webinar on 26 Sep 2025 at 7 PM IST | Register for Free Demo

Voting disks in RAC

Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
Breadcrumb Abstract Shape
  • User AvatarKiran Dalvi
  • 04 Oct, 2022
  • 0 Comments
  • 9 Mins Read

Voting disks in RAC

Voting Disks In RAC

Voting Disks :

Key Functions of the Voting Disk: 

  1. Cluster Node Membership Management:
  • The voting disk is used to manage cluster node membership, ensuring that the nodes in a RAC cluster agree on which nodes are active or inactive at any given time. 
  • Each node in the cluster regularly sends “heartbeat” messages to the voting disk. If a node’s heartbeat fails to be recorded for a specific time, it is considered as failed or inactive. 
  1. Failure Detection and Recovery:
  • When Oracle Clusterware detects that a node is not sending heartbeats, it can initiate a node eviction process. This ensures that the node is removed from the cluster, preventing any potential corruption or split-brain scenario (where two instances may think they are the primary node). 
  1. Quorum Management:
  • The voting disk ensures that the cluster has a quorum, which is the minimum number of active nodes required for the cluster to function properly. The quorum helps avoid situations where split-brain issues occur, in which two or more nodes in the cluster cannot communicate with each other but continue to process transactions independently. 
  • In a typical RAC configuration, the voting disk requires more than half of the nodes to agree on the status of other nodes. This prevents a minority of nodes from continuing in isolation. 

Key Points about Voting Disk: 

  • Oracle RAC clusters require an odd number of voting disks to avoid tie situations during voting for quorum. 
  • The voting disk must be accessible by all nodes in the cluster at all times. 
  • If the voting disk becomes inaccessible, the entire cluster may be compromised, as the nodes won’t be able to communicate with each other properly. 
  • Oracle recommends placing the voting disks on shared storage that is accessible by all cluster nodes (such as Oracle ASM or a network file system). 

Managing Voting Disks: 

  • In Oracle 12c and later, Oracle Automatic Storage Management (ASM) can store voting disks, eliminating the need for dedicated raw or block storage devices. 
  • The crsctl command is used to manage voting disks: 
  • Check Voting Disk Status: crsctl query css votedisk 
  • Add Voting Disk: crsctl add css votedisk <path> 
  • Remove Voting Disk: crsctl delete css votedisk <path> 
  • Replace Voting Disk: crsctl replace css votedisk 

Backup and Recovery of Voting Disk: 

  • Oracle Clusterware automatically backs up voting disks whenever they are changed. These backups are stored in the Oracle Cluster Registry (OCR). 
  • In the event of failure, voting disks can be restored using these backups. 

 

What is stored in voting disk?

Key Functions of the Voting Disk: 

  1. Cluster Node Membership Management:
  • The voting disk is used to manage cluster node membership, ensuring that the nodes in a RAC cluster agree on which nodes are active or inactive at any given time. 
  • Each node in the cluster regularly sends “heartbeat” messages to the voting disk. If a node’s heartbeat fails to be recorded for a specific time, it is considered as failed or inactive. 
  1. Failure Detection and Recovery:
  • When Oracle Clusterware detects that a node is not sending heartbeats, it can initiate a node eviction process. This ensures that the node is removed from the cluster, preventing any potential corruption or split-brain scenario (where two instances may think they are the primary node). 
  1. Quorum Management:
  • The voting disk ensures that the cluster has a quorum, which is the minimum number of active nodes required for the cluster to function properly. The quorum helps avoid situations where split-brain issues occur, in which two or more nodes in the cluster cannot communicate with each other but continue to process transactions independently. 
  • In a typical RAC configuration, the voting disk requires more than half of the nodes to agree on the status of other nodes. This prevents a minority of nodes from continuing in isolation. 

Key Points about Voting Disk: 

  • Oracle RAC clusters require an odd number of voting disks to avoid tie situations during voting for quorum. 
  • The voting disk must be accessible by all nodes in the cluster at all times. 
  • If the voting disk becomes inaccessible, the entire cluster may be compromised, as the nodes won’t be able to communicate with each other properly. 
  • Oracle recommends placing the voting disks on shared storage that is accessible by all cluster nodes (such as Oracle ASM or a network file system). 

Managing Voting Disks: 

  • In Oracle 12c and later, Oracle Automatic Storage Management (ASM) can store voting disks, eliminating the need for dedicated raw or block storage devices. 
  • The crsctl command is used to manage voting disks: 
  • Check Voting Disk Status: crsctl query css votedisk 
  • Add Voting Disk: crsctl add css votedisk <path> 
  • Remove Voting Disk: crsctl delete css votedisk <path> 
  • Replace Voting Disk: crsctl replace css votedisk 

Backup and Recovery of Voting Disk: 

  • Oracle Clusterware automatically backs up voting disks whenever they are changed. These backups are stored in the Oracle Cluster Registry (OCR). 
  • In the event of failure, voting disks can be restored using these backups. 

 

Why is voting disk needed ?

The Voting Disk Files are used by Oracle Clusterware  by way of a health check .
 
– by CSS to determine which nodes are currently members of the cluster
 
– in concert with other Cluster components such as CRS to shut down, fence, or reboot either single or multiple nodes whenever network communication is lost between any node within the cluster, in order to prevent the dreaded split-brain condition in which two or more instances attempt to control the RAC database. It  thus protects the database information.
 
– It will be used by the CSS daemon to arbitrate with peers that it cannot see over the private interconnect in the event of an outage, allowing it to salvage the largest fully connected subcluster for further operation.  It checks the voting disk to determine if there is a failure on any other nodes in the cluster. During this operation, NM will make an entry in the voting disk to inform its vote on availability. Similar operations are performed by other instances in the cluster. The three voting disks configured also provide a method to determine who in the cluster should survive. For example, if eviction of one of the nodes is necessitated by an unresponsive action, then the node that has two voting disks will start evicting the other node. NM alternates its action between the heartbeat and the voting disk to determine the availability of other nodes in the cluster.
 
The Voting disk is the key communication mechanism within the Oracle Clusterware where all nodes in the cluster read and write heartbeat information. CSSD processes (Cluster Services Synchronization Daemon) monitor the health of  RAC nodes employing two distinct heart beats: Network heart beat and Disk heart beat. Healthy nodes will have continuous network and disk heartbeats exchanged between the  nodes. Break in heart beat indicates a possible error scenario. There are few different scenarios possible with missing heart beats:
1. Network heart beat is successful, but disk heart beat is missed.
2. Disk heart beat is successful, but network heart beat is missed.
3. Both heart beats failed.
In addition, with numerous nodes, there are other possible scenarios too. Few possible scenarios:
1. Nodes have split in to N sets of nodes, communicating within the set, but not with members in other set.
2. Just one node is unhealthy.
Nodes with quorum will maintain active membership of the cluster and other node(s) will be fenced/rebooted.

A node must be able to access more than half of the voting disks

A node must be able to access more than half of the voting disks at any time. For example, let’s have a two node cluster with an even number of let’s say 2 voting disks. Let Node1 is able to access voting disk1 and Node2 is able to access voting disk2 . This means that there is no common file where clusterware can check the heartbeat of both the nodes.  Hence, if we have 2 voting disks, all the nodes in the cluster should be able to access both the voting disks. If we have 3 voting disks and both the nodes are able to access more than half i.e. 2 voting disks, there will be at least on disk which will be accessible by both the nodes. The clusterware can use that disk to check the heartbeat of both the nodes. Hence, each  node should be  able to access more than half the number of voting disks. A node not able  to do so will have to be evicted from the cluster to maintain the integrity of the cluster  . After the cause of the failure has been corrected and access to the voting disks has been restored, you can instruct Oracle Clusterware to recover the failed node and restore it to the cluster.
 
 Loss of more than half your voting disks will cause the entire cluster to fail !!

Why should we have an odd number of voting disks?

Here is a table which represents the number of voting disks whose failure can be tolerated for different numbers of voting disks:
                                                    No. of voting disks
 Total                             Which should be accessible           Whose failure can be tolerated
      1                                                         1                                                                     0
      2                                                         2                                                                     0
      3                                                         2                                                                     1
      4                                                         3                                                                     1
      5                                                         3                                                                     2
      6                                                         4                                                                     2
 
It can be seen that number of voting disks whose failure can be tolerated is same for (2n-1) as well as 2n voting disks where n can be 1, 2 or 3. Hence to save a redundant voting disk, (2n-1) i.e. an odd number of voting disks are desirable.
Change Voting Disk Configuration :
    • Voting disk configuration can be changed dynamically.
    • To add a new voting disk:
 crsctl add css votedisk
  • To remove a voting disk: 
     crsctl delete css votedisk
If Oracle Clusterware is down on all nodes, use the force option 
crsctl add css votedisk -force <new voting disk path>
crsctl delete css votedisk -force <old voting disk path>
  • Backing up Voting Disks : Perform backup operation whenever there is change in the configuration like add/delete of new nodes or add/delete of voting disks.
Syntax : 
 dd if=voting_disk_name of=backup_file_name
example : 
[oracle@rac1 bin]$ dd if=/apps/oracle/oradata/votingdisk  of=/home/oracle/vote/vote.dmp bs=4k
  • Recovering Voting Disks : A Bad voting disk can be recovered using a backup copy.
Syntax: 
$ dd if=backup_file_name of=current_voting_disk
Adding an Oracle Cluster Registry Location : Oracle Clusterware can manage up to five redundant OCR locations. 
# ocrconfig -add +asm_disk_group | file_name
Removing an Oracle Cluster Registry Location : To remove an OCR location or a failed OCR location, at least one other OCR must be online.   
# ocrconfig -delete +ASM_disk_group | file_name
What is OLR ?
OCR (Oracle Local Registery) is installed on each node in the cluster. OLR is not shared by other nodes in the cluster. It is installed & configured at the time of clusterware installation. If OLR is missing or corrupted , clusterware can’t be started on that node.
The OLR file is location : 
$GRID_HOME/cdata/.olr
Location details Stored at : 
 /etc/oracle/olr.loc
list all the ocrfile related command 
[root~]#ocrconfig -show
Check OCR File location 
[root~]# ocrcheck
manual backup of OCR File 
ocrconfig -manualbackup
Restore OCR File from backup 
ocrconfig -restore $ORACLE_HOME/cdata/racscan/backup00.ocr
To view the status of the OLR file on each node. 
#ocrcheck -local
To export and import the OLR : 
#ocrconfig -local -export
#ocrconfig -local -import
To repair the OLR file : 
#ocrconfig -local -repair olr
To manually back up OLR: 
# ocrconfig –local –manualbackup
To view the contents of the OLR backup file: 
#ocrdump -local -backupfile olr_backup_file_name
To restore OLR: 
# crsctl stop crs
# ocrconfig -local -restore file_name
# ocrcheck -local
# crsctl start crs
$ cluvfy comp olr
To change the OLR backup location: 
#ocrconfig -local -backuploc new_olr_backup_path
Active Session History (ASH) Reports
Creating Deleting and Modifying Services in Oracle RAC