Resizing an ASM Diskgroup on Exadata When OCR/Voting Files Are on It

When you try to shrink an ASM diskgroup that holds Oracle Clusterware files (OCR and voting disks), you may hit errors like:

SQL> ALTER DISKGROUP DATA RESIZE ALL SIZE 520000M REBALANCE POWER 11;
ALTER DISKGROUP DATA RESIZE ALL SIZE 520000M REBALANCE POWER 11
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15313: Oracle ASM disk xxxxx cannot be resized under 546628 M

Why it happens

Even though Oracle bugs 24568147 and 37688474 mention fixes in newer releases (19.27 RU+), this issue still reproduces in 19.28 and 23.8.

The voting files are persisted in the ASM diskgroup and cannot be moved automatically by a rebalance.

The real reason is:

Voting disks cannot be relocated automatically during an ASM rebalance.
If your new disk size is smaller than what’s needed to hold the voting files, the resize fails.

Solution (high level)

Move OCR and voting disks to another diskgroup (e.g., +RECO).

Resize the DATA diskgroup and grid disks.

Move OCR and voting disks back to DATA.

1. Check and back up OCR

# Check current backups
ocrconfig -showbackup

# Take a manual backup
ocrconfig -manualbackup

# Export OCR to a file (extra safety)
ocrconfig -export /tmp/ocr_backup.bak

# Verify OCR status
ocrcheck

Status of Oracle Cluster Registry is as follows :
 Version                  : 4
 Total space (kbytes)     : 491684
 Used space (kbytes)      : 86280
 Available space (kbytes) : 405404
 Device/File Name         : +DATA
...
Cluster registry integrity check succeeded

2. Check current voting disks

crsctl query css votedisk

##  STATE    File Universal Id                File Name Disk group
--  -----    -----------------                --------- ---------
 1. ONLINE   e9c0a44e... (o/.../DATA_CD_02_cel03) [DATA]
 2. ONLINE   43b99921... (o/.../DATA_CD_04_cel04) [DATA]
 3. ONLINE   e1df469f... (o/.../DATA_CD_05_cel05) [DATA]
Located 3 voting disk(s).

3. Add OCR to the RECO diskgroup

ocrconfig -add +RECO
ocrcheck   # now you should see both +DATA and +RECO

Once you see OCR in +RECO, you can remove it from +DATA:

ocrconfig -delete +DATA

4. Move voting disks to RECO

crsctl replace votedisk +RECO

Check again:

crsctl query css votedisk

You should now see all voting disks online in [RECO].

5. Resize the DATA diskgroup

Now that DATA no longer holds OCR/voting files, you can safely resize.

SQL> ALTER DISKGROUP DATA RESIZE ALL SIZE 520000M REBALANCE POWER 11;
SQL> SELECT * FROM gv$asm_operation;  -- monitor rebalance progress

6. Shrink the Exadata grid disks

Run on each storage cell:

cellcli -e "alter griddisk DATA_CD_00_cel01,DATA_CD_01_cel01,DATA_CD_02_cel01,DATA_CD_03_cel01,DATA_CD_04_cel01,DATA_CD_05_cel01 size=520000M"

Make sure all grid disks for the DATA diskgroup are resized to the same size across cells.

7. Move OCR and voting disks back to DATA

Once resizing and rebalance complete:

# Add OCR back to DATA
ocrconfig -add +DATA
ocrcheck

# Remove OCR from RECO
ocrconfig -delete +RECO

# Move voting disks back
crsctl replace votedisk +DATA
crsctl query css votedisk

Your cluster should now have OCR and voting disks back on DATA at the new size.

Notes & Best Practices

• Always back up OCR before touching it. Both ocrconfig -manualbackup and ocrconfig -export are recommended.
• Voting disk move (crsctl replace votedisk) is online, but plan a maintenance window — if anything goes wrong you could lose quorum.
• Choose grid disk sizes carefully. On Exadata, sizes must be multiples of 16 MB.
• Monitor rebalance:
  
  SELECT * FROM gv$asm_operation;

Summary

If you get ORA-15313 while shrinking an ASM diskgroup on Exadata, check whether the diskgroup still holds OCR/voting disks.
Moving them to another diskgroup before resizing solves the problem and avoids the bug/limitation.