Recently, I encountered a situation in a 2-node Windows RAC 19c environment running the latest 19.27 Grid Infrastructure version.
I had added a disk back using the force option. However, I mistakenly did not specify the disk name, which resulted in the creation of a duplicate disk associated with a new disk group (Group Number 0).

I now need to remove the unintended disk group and re-add the disk back to its original disk group correctly.

Based on our analysis, we found that the dropped disk, which was previously added using the force option, got associated with Group 0.
This indicates that the disk is not currently part of any valid disk group and was unintentionally added as a standalone entry.

In the ASM alert log file, I found the following error:

2025-06-17T11:41:25.349104-04:00
SQL> alter diskgroup DATA ADD FAILGROUP T1 DISK '\\.\DISK_A1' NAME "_B1" FORCE 
2025-06-17T11:41:25.484229-04:00
NOTE: cache closing disk 3 of grp 1: (not open) _B1
2025-06-17T11:41:25.568609-04:00
NOTE: Assigning number (1,9) to disk (\\.\DISK_A1)
ORA-15032: not all alterations performed
ORA-15020: discovered duplicate ASM disk "_B1"

2025-06-17T11:41:25.568609-04:00
ERROR: alter diskgroup DATA1 ADD FAILGROUP T1 DISK '\\.\DISK_A1' NAME "_B1" FORCE

Also the Metadata showing as per below:

0 0 CLOSED MEMBER ONLINE NORMAL 381537 0 0 \\.\DISK_A1 

Solution:

We performed the following steps to add the disk back to the disk group, ensuring that the system continues to operate normally and without any issues:

Dropped the disk _D1_3 using the following command:

ALTER DISKGROUP DATA DROP DISK “_B1”;
The above command threw an error, so I used the FORCE option to proceed:

Then, the correct command I used was:

ALTER DISKGROUP DATA DROP DISK “_B1” FORCE;

Monitored the rebalance operation using the following.Also reviewed the ASM alert log file for progress and issues.

SELECT * FROM v$asm_operation;

Once the rebalance operation completed successfully, I added the disk back to DATA1 using:

ALTER DISKGROUP DATA ADD FAILGROUP T1 DISK ‘\.\DISK_A1’ NAME “_B1” FORCE;

SELECT * FROM v$asm_operation;

Also check the ASM alert log file for any error.

The issue occurred because the disk was re-added without specifying the correct disk name, which led to the creation of an unintended disk group (Group 0). After identifying the problem through ASM alert logs and v$asm_operation, we successfully dropped and re-added the disk using the correct syntax and FORCE option.

Following a successful rebalance, the disk was correctly integrated back into the intended disk group (DATA1), and the system is now functioning as expected.