当ASM 磁盘不存在于Rac Cluster 的所有节中时出现错误ORA-15040, ORA-15066, ORA-15042，添加磁盘到磁盘组失败

如果自己搞不定可以找诗檀软件专业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 及以下

1. 请不要操作磁盘头部。

请记住磁盘已经部分添加到磁盘组，这意味着它已经包括一个ASM头部和元数据, 磁盘组在一些节上可用，如果新盘的头部是在ASM外部改变，它不会让ASM配置磁盘。

2. 不要卸载磁盘组

不要试图从它仍旧安装的ASM实例卸载磁盘组，同时，不要尝试重启节。

3. 生成手动重新平衡 如果在创建磁盘组时报告出问题，将会在执行命令的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 下面的列标识磁盘不是任何磁盘组的一部分: 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). 表 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 ''