Lost one disk from OCR + VOTE in a Normal Redundancy configuration.

 

If I lost below highlighted disk from OCR + VOTE in a Normal Redundancy configuration, how to add the disk.

[root@rac09-p ~]# crsctl query css votedisk

##  STATE    File Universal Id                File Name Disk group

--  -----    -----------------                --------- ---------

 1. ONLINE   5d0f54a71b794fedbffe2bb21fa43ce7 (/dev/oracleasm/disks/OCR_VD01) [OCRVD]

 2. ONLINE   df053ca326a64f47bfa0a8620518b03f (/dev/oracleasm/disks/OCR_VD02) [OCRVD]

 3. ONLINE   662758cc818b4fe0bfe1251959af18b4 (/dev/oracleasm/disks/OCR_VD03) [OCRVD]

   

DISKGROUP_NAME  DISK_PATH                           REDUNDANCY      FAILGROUP_NAME

--------------  ----------------------------------- --------------- --------------

OCRVD           /dev/oracleasm/disks/OCR_VD01       NORMAL          OCRVD_0000

OCRVD           /dev/oracleasm/disks/OCR_VD02       NORMAL          OCRVD_0001

OCRVD           /dev/oracleasm/disks/OCR_VD03       NORMAL          OCRVD_0002

If you lose the /dev/oracleasm/disks/OCR_VD03 disk in a cluster with NORMAL redundancy, the cluster can still function because the data in the OCRVD disk group is mirrored across the remaining disks. 

NORMAL redundancy means that each piece of critical information (like OCR and voting disk) has two copies across different failgroups. 

Here's the impact and step-by-step recovery process:

---

Impact of Losing /dev/oracleasm/disks/OCR_VD03:

1. The cluster will continue to operate as long as at least one other failgroup (OCRVD_0000 or OCRVD_0001) is intact.
2. Alerts will be raised by Oracle ASM, Clusterware, and Grid Infrastructure for the missing disk.
3. If another disk in the same disk group fails before recovery, the cluster may halt due to insufficient quorum for voting disks or loss of OCR access.

---

Step-by-Step Resolution to Recover /dev/oracleasm/disks/OCR_VD03:

Step 1: Identify the Lost Disk and Acknowledge Alerts

• Check the status of the ASM disk group:

  
  SELECT group_number, name, state, mount_status FROM v$asm_disk
  WHERE path = '/dev/oracleasm/disks/OCR_VD03';
  

  The state will likely show MISSING or FORCING OFFLINE.

• Review ASM and Grid Infrastructure logs:

  cd $GRID_HOME/log/`hostname`/alert*.log

  Look for entries indicating that /dev/oracleasm/disks/OCR_VD03 is unavailable.

---

Step 2: Replace the Missing Disk

If the disk is permanently lost, add a new disk to the disk group to restore redundancy:

1. Replace the lost disk with a new device:

   • Prepare the new disk for ASM (e.g., /dev/oracleasm/disks/OCR_VD03_NEW):

     /etc/init.d/oracleasm createdisk OCR_VD03_NEW /dev/sdX

     Replace /dev/sdX with the actual device path.

2.  Drop the old disk if still listed:

   • SQL> ALTER DISKGROUP OCRVD DROP DISK 'OCR_VD03' FORCE;

3. Add the new disk to the disk group:                                                                                                                                                Use the following ASMCA (ASM Configuration Assistant) or SQL command

   SQL> ALTER DISKGROUP OCRVD ADD DISK '/dev/oracleasm/disks/OCR_VD03_NEW' NAME 'OCR_VD03';

---

Step 3: Monitor Disk Group Rebalance

After replacing the disk, ASM will automatically rebalance the data to restore redundancy. 

Monitor the rebalance operation:

SELECT * FROM v$asm_operation;

---

Step 4: Verify Disk Group and OCR/Voting Disk Health

• Confirm that the disk group is healthy and redundancy is restored:

  SELECT name, state, type FROM v$asm_diskgroup;

• Validate the OCR and voting disk:

  ocrcheck
  crsctl query css votedisk
  

---