Maybe you can mount the ASM diskgroup through ASMCA if you decide to ignore the error, but you will still meet failure in the successive database installation.
At this moment, please recheck your candidate disks are clean or not , you may try "pvcreate" or "fdisk", but they won't save you out of the trap. The problem is still there.
If you ask OS administrator the same question again, and his answer could be the same. He could say: "They are clean, very clean. I use pvcreate to create the volumes, although the OS is reconstructed from an old machine."
Did you see the clues?
- The host was reconstructed from an old machine: the disks could have ever been used and still contain data.
- He created the physical volumes by pvcreate: obviously, the command does not scrub these disks, only labels them.
# dd if=/dev/zero of=/dev/rdisk/disk01 bs=1024k count=5000
# dd if=/dev/zero of=/dev/rdisk/disk02 bs=1024k count=5000
# dd if=/dev/zero of=/dev/rdisk/disk03 bs=1024k count=5000
# dd if=/dev/zero of=/dev/rdisk/disk04 bs=1024k count=5000
In this case, every candidate disk is near 120GB, but you don't need to set the count too large, just clean the front part of every disks, in which it is usually problematic.
With the same logic, if you want to reinstall ASM, dd the candidate disks before installation.