如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com
症状
运行RAC 和ASM的环境，在磁盘成为磁盘组一部分之前，必须验证它存在于群集的所有节中，验证失败会产生不同的结果，尤其对使用版本10.2.0.2及以下的环境而言。
10.2.0.2 及以下
磁盘群安装在执行操作的ASM 实例中，但是不安装在磁盘丢失群集的ASM 实例中
尝试安装磁盘群可能会产生类似错误:
ORA-15001: diskgroup “1” does not exist or is not mounted
ORA-15040: diskgroup is incomplete
ORA-15066: offlining disk “” may result in a data loss
ORA-15042: ASM disk “3” is missing
or
SQL> alter diskgroup test1 mount;
alter diskgroup test1 mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk “1” is missing
添加磁盘到磁盘组时:
SQL> alter diskgroup test1 add disk ‘/dev/asmdisk_KH5’ force;
alter diskgroup test1 add disk ‘/dev/asmdisk_KH5’ force
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15075: disk(s) are not visible cluster-wide
10.2.0.3 及以上
从10.2.0.3开始, 如果不能在群集的所有节中验证磁盘，将不会添加到磁盘组，在这个过程中,磁盘的头部被格式化为带有有效信息，看起来像是一个有效的ASM 磁盘。
尝试删除磁盘会失败，产生错误ORA-15032和ORA-15054
SQL> alter diskgroup test drop disk ‘/dev/raw/raw8’;
alter diskgroup test drop disk ‘/dev/raw/raw8’
*
ERROR at line 1:
ORA-15032 : not all alterations performed
ORA-15054 : disk “/DEV/RAW/RAW8” does not exist in diskgroup “TEST”
再次尝试添加磁盘会失败，产生错误ORA-15032和ORA-15020
SQL> alter diskgroup test add disk ‘/dev/raw/raw8’;
alter diskgroup TEST add disk ‘/dev/raw/raw8’
*
ERROR at line 1:
ORA-15032 : not all alterations performed
ORA-15020 : discovered duplicate ASM disk “TEST_0005”
原因
10.2.0.2及以下
当磁盘添加到磁盘组时，必须通过群集的所有节进行验证，如果盘不存在于一个节点，在命令被执行（主实例）ASM实例的alert.log文件中，将会产生下列信息:
SQL> ALTER DISKGROUP DG3_DBDATA ADD DISK ‘/dev/raw/raw8’ SIZE 25595M
Mon Dec 12 15:16:10 2005
NOTE: reconfiguration of group 1/0xfaa07f1e (DG3_DBDATA), full=1
Mon Dec 12 15:16:10 2005
NOTE: initializing header on grp 1 disk DG3_DBDATA_0003
NOTE: cache opening disk 3 of grp 1: DG3_DBDATA_0003 path:/dev/raw/raw8
NOTE: requesting all-instance disk validation for group=1
此时盘已被部分加入（接收姓名，号码，等等），它需要在所有的实例进行验证，群集中的其它实例将会触发磁盘浏览，读取磁盘头部，寻找新的添加的磁盘，如果在节中没有发现新磁盘，那么主实例(操作开始的地方)会在alert.log中产生下列信息:
NOTE: disk validation pending for group 1/0xfaa07f1e (DG3_DBDATA)
SUCCESS: validated disks for 1/0xfaa07f1e (DG3_DBDATA)
SUCCESS: refreshed PST for 1/0xfaa07f1e (DG3_DBDATA)
Received dirty detach msg from node 1 for dom 1
从最后一条信息，我们可以确定没有发现磁盘的节: from node 1.
审查特定节点的ASM实例的alert.log会发现这样的错误:
NOTE: reconfiguration of group 1/0xfaa064f3 (DG3_DBDATA), full=1
NOTE: disk validation pending for group 1/0xfaa064f3 (DG3_DBDATA)
ERROR: group 1/0xfaa064f3 (DG3_DBDATA): could not validate disk 3
SUCCESS: validated disks for 1/0xfaa064f3 (DG3_DBDATA)
SUCCESS: refreshed PST for 1/0xfaa064f3 (DG3_DBDATA)
ERROR: ORA-15040 thrown in RBAL for group number 1
Mon Dec 12 15:16:15 2005
Errors in file /oralog/+asm2_rbal_8654.trc:
ORA-15040: diskgroup is incomplete
ORA-15066: offlining disk “” may result in a data loss
ORA-15042: ASM disk “3” is missing
如果磁盘组使用外部冗余，它将在那里的新磁盘未发现的情况下卸载，安装磁盘组之前，磁盘必须在所有节点可用。
10.2.0.3 及以上
从10.2.0.3开始, 情况变化了，此时，磁盘是不会被添加到磁盘组。同时，在没有发现磁盘的实例中产生的信息，会有一些不同:
NOTE: reconfiguration of group 2/0xc9489bc5 (TEST), full=1
NOTE: disk validation pending for group 2/0xc9489bc5 (TEST)
ERROR: group 2/0xc9489bc5 (TEST): could not validate disk 3
解决方法
10.2.0.2 及以下
请不要操作磁盘头部。
请记住磁盘已经部分添加到磁盘组，这意味着它已经包括一个ASM头部和元数据, 磁盘组在一些节上可用，如果新盘的头部是在ASM外部改变，它不会让ASM配置磁盘。
- 不要卸载磁盘组
不要试图从它仍旧安装的ASM实例卸载磁盘组，同时，不要尝试重启节。
- 生成手动重新平衡
如果在创建磁盘组时报告出问题，将会在执行命令的ASM 实例上创建和安装它，但是在群集的其它节上安装磁盘组时，会报告一个错误，在安装磁盘组之前，验证磁盘存在于所有节中，紧跟着是步骤4和5的指导方针。
如果在添加磁盘到现存的磁盘组之后产生问题:
添加的磁盘处于“部分”状态，触发手动重新平衡将从磁盘组驱逐该磁盘，记住，磁盘组将会安装在执行命令的ASM 实例上。
SQL> alter diskgroup <DGNAME> rebalance power X;
查看V $ ASM_OPERATION，寻找与特定磁盘组有关的行，视图中没有行意味着没有重新平衡操作正在运行，要么没有运行，要么已经完成，尝试在没有安装的一个实例中安装磁盘组。
如果磁盘存在于所有节中，那么其它驱除磁盘的方式是执行下列命令:
SQL> alter diskgroup <DGNAME> drop disk <DISK_NAME>;
SQL> alter diskgroup <DGNAME> undrop disks;
它将触发一个重新平衡操作，移除不完整的磁盘。
在尝试再次添加磁盘之前，验证磁盘存在于群集中的所有节中。
10.2.0.3及以上
磁盘不是磁盘组的一部分,那么不要求它执行删除或重新平衡命令。
注意磁盘是如何显示在v$asm_disk上的。
在这个例子中, 磁盘正在使用ASMLIB
| 群号 | 磁盘号 | 路径 | HEADER STATUS |
STATE | NAME |
| 0 | 8 | ORCL:DISK4 | MEMBER | IGNORED | |
| 1 | 0 | ORCL:DISK1 | MEMBER | CACHED | DISK1 |
| 2 | 1 | ORCL:DISK2 | MEMBER | CACHED | DISK2 |
| 3 | 2 | ORCL:DISK3 | MEMBER | CACHED | DISK3 |
下面的列标识磁盘不是任何磁盘组的一部分:
MOUNT_STATUS = IGNORED
GROUP_NUMBER = 0. 当磁盘组不安装磁盘时，使用这个号。
在有问题的磁盘上使用 kfed不要困惑, 因为它会显示一个有效的ASM 磁盘头，记住在操作一开始就被格式化了，但是如果过程失败将不会改变。
在验证磁盘存在于所有的节之后，清空磁盘的内容或者重建asmlib 磁盘，将它添加到磁盘组。
如何验证磁盘存在于群集的所有节上。
不要求所有节上的所有磁盘有相同的名称，当有大量磁盘时，这只会使管理相对容易些，对ASM而言，相关的是可以发现所有的磁盘(asm_diskstring)，当磁盘在其它节得到验证时，ASM按顺序读取磁盘头部，以完成操作，在asm_diskstring 参数的基础上发现磁盘。
即便没有设置asm_diskstring 参数，也将浏览平台和那些目录的默认路径，将会发现有正确权限的设备。
导致磁盘不被发现的一些原因是:
* 如果使用ASMLIB,在群集剩下的节中不会执行/etc/init.d/oracleasm scandisk命令，
*不正确的权限。 Oracle用户不是拥有者，不能读取/写入。
* 磁盘不会存在任何名称之下。
* 在Linux中使用原连接时，原名称在节上是一致的，要么设备是不正确的（不同的磁盘），要么文件/proc/分区中有丢失的条目。
* 所有节的名称是一样的，但是它们不指向相同的设备。
* 在IBM AIX中，使用没有LVM的磁盘时, 磁盘有特定的属性 (表1).
| 存储类型 | ATTRIBUTE | VALUE |
| IBM STORAGE (ESS,FasTt,DSXXX) | reserve_policy | no_reserve |
| EMC STORAGE | reserve_lock | no |
表 1
例如,使用ESS磁盘，用reserve_policy=single_路径配置它们, 使得只能在一个节点上安装磁盘组，作为一个额外的配置, dd命令可用于在第二个节上从设备读取，在操作系统级别上该操作的失败证明原因和磁盘配置有关。
lsattr -E -l hdisk19|grep reser
reserve_policy no_reserve Reserve Policy True
lsattr -E -l hdisk21|grep reser
reserve_policy single_path Reserve Policy True
*********** Wont be discovered in a second node
如何验证磁盘在所有节上是相同的。
*如果使用ASMLIB,在所有节上运行 /etc/init.d/oracleasm listdisk ，验证输出是一样的，其他的选择是运行 ls -l /dev/oracleasm/disks
* 使用 kfed to 回顾头的内容。
在每个节点上执行:
$kfed read <devicename> text=name.txt
* 比较txt文件的输出，必须是一样的。
* In the node where the disk was discovered, this is part of the valid output:
fbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj: 2147483649 ; 0x008: TYPE=0x8 NUMB=0x1
kfbh.check: 3189683974 ; 0x00c: 0xbe1eb706
/* SOME DATA REMOVED INTENTIONALLY */
kfdhdb.dsknum: 1 ; 0x024: 0x0001
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: DATA_0001 ; 0x028: length=9
kfdhdb.grpname: DATA ; 0x048: length=4
kfdhdb.fgname: DATA_0001 ; 0x068: length=9
* In the failing node, if the disk is not the same, you will get different output or the operation will fail.
KFED-00303: unable to open file ”
Comment