当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配置磁盘。

  1. 不要卸载磁盘组

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

  1. 生成手动重新平衡

    如果在创建磁盘组时报告出问题,将会在执行命令的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 ”

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569