ORA-15063:ASMdiscoveredaninsufficientnumberofdisksfo

ORA-15063: ASM discovered an insufficient number of disks for diskgroup DATAORA-15063这个报错的原因层出不穷，搜了好一阵

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

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

操作系统无法识别ASM磁盘或权限设置不当

在故障主机上执行

#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_diskstring没有正确配置
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 content in production server
$ kfed read WRADK003.dmp ausz=4194304 aunum=1 blknum=0

kfbh.endian: 0 ; 0x000: 0x00
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 17 ; 0x002: KFBTYP_PST_META
kfbh.datfmt: 2 ; 0x003: 0x02
kfbh.block.blk: 262144 ; 0x004: T=0 NUMB=0x40000
kfbh.block.obj: 16777344 ; 0x008: TYPE=0x0 NUMB=0x80
kfbh.check: 1240136211 ; 0x00c: 0x49eafa13
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
-- Disk content on target (backup) storage
$ kfed read WRADK003.dmp ausz=4194304 aunum=1 blknum=0

kfbh.endian: 0 ; 0x000: 0x00
kfbh.hard: 0 ; 0x001: 0x00
kfbh.type: 0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt: 0 ; 0x003: 0x00
kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj: 0 ; 0x008: TYPE=0x0 NUMB=0x0
...

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.