ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA"

ORA-15063这个报错的原因层出不穷，搜了好一阵各种试过各种方法后最终判定为bug，有点郁闷，这里对网上和metalink的方法进行各总结，以便日后查看。具体原因和解决方法如下

在故障主机上执行

#Oracleasm scandisks

#oracleasm scandisks

确保ls -lASM磁盘的输出如下
#ls -l /dev/oracleasm/disks/
total 0
brw-rw---- 1 oracle dba 8, 33 Nov 25 14:35 VOL1

如果依然无法解决，且是11.1或者之后的版本，可以采用如下语句,然后再重新创建磁盘组
drop diskgroup including contents force;
INCLUDING CONTENTS:删除掉磁盘组中的所有文件。
FORCE:清除磁盘头的相关信息。
在集群环境下如果操作的磁盘组正在使用或者在其他节点上挂载，则该语句将失败。

ASM_DISKGROUPS指定了ASM实例启动或者ALTER DISKGROUP ALL MOUNT命令时自动挂载的磁盘组。当磁盘组创建、挂载或者被删除时，ASM实例都会自动更新该参数
ASM_DISKSTRING指定了ASM实例发现磁盘的路径，也就是说ASM实例只会在该参数指定的路径下发现ASM磁盘。该参数支持通配符。ASM_DISKSTRING默认值为null，表示ASM实例查找所有与操作系统向连的可读写磁盘以确认哪些是真正的ASM磁盘。虽然官方文档上说该参 数支持通配符，但有时候只有明确指定后才会成功修复ORA-15063，估计又是个bug。
解决步骤如下
1、先讲所有已经挂载的磁盘dismout
SQL>alter diskgroup all dismount
2、重新指定asm_diskstring:
SQL> alter system set asm_diskstring='/dev/mapper/datap1','/dev/mapper/frap1';

SQL> alter system set asm_diskgroups='/dev/oracleasm/disks/ASMGROUP3','/dev/oracleasm/disks/ASMGROUP4';
3、dbca 继续挂载，当然也可以手工的创建磁盘组。
如果依然不行可以执行如下操作
/etc/init.d/init.cssd stop
/etc/init.d/init.cssd start
sleep 90
restart ASM instance and shutdown immediate
again restart ASM instance

可以查看官方文档

ORA-15063 When Mounting a Diskgroup After Storage Cloning ( BCV / Split Mirror / SRDF / HDS / Flash Copy ) [ID 784776.1]

Cause

Storage cloning doesn't create a consistent image during split copy.
There is a problem in other disk metadata structures (PST block, listheader f1b1locn, disk directory, etc.)
Header status is MEMBER but diskgroup can't be mounted.

Disk WRADK003.dmp contains Partner Status Table in the source storage. However, its content is all zero in the backup storage after the split copy. Storage cloning doesn't create a consistent image of ASM LUNs.
Allocation unit containing PST block is apperantly not copied from production to backup disks.

In this particular case, we see the PST is corrupted. But basically the issue here is that the clone was not consistent, and the invalid ASM Metadata could be on anywhere on the disk(s), and could prohibit mount of the diskgroup.

Solution

The problem could be with the incorrect initial configuration of the clones on the storage array. The first time copy must be the full sync. After only having a full first copy, it is possible to do incremental clone.

There is various storage cloning methods and technologies used by different storage vendors. As long as the cloning techology creates consistent snapshots of all the disks in an ASM disk group then the diskgroup based on the copied LUNs can be mounted at an alternate site.

- EMC CLARiiON SnapView and MirrorView (also known as BCV copy)
- Hitachi Data Systems (HDS): Universal Storage Platform Replication Software
- IBM FlashCopy

Most common disk cloning technologies is mentioned in the following link. The documents specific for each vendor also explains the best practices when creating the disk copies.

虽然文档上没有对虚拟机的克隆技术进行描述，不过根据笔者过在虚拟机上搭建HA环境的经验，使用 虚拟机的克隆技术往往会带来莫名其妙的错误，笔者在利用VMWARE的克隆技术搭建RAC时就报了ORA-15063。奉劝大家一句，如果要搭建HA环 境，最好不要利用克隆技术，建个系统废不了多少工夫，不然到头来无穷无尽的bug会折磨得你想死，呵呵。

您可能感兴趣的文章: