如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]

应用于:

Oracle数据库- 企业版- 10.2.0.1版到11.1.0.7版[发行10.2版至11.1版]

本文档中的信息适用于任何平台。

***于2013年6月3日检测相关性***

症状

4个节点中的两个被逐出集群。这两个节点返回集群后，一些磁盘组被安装，但特定的磁盘组安装出错。在未受影响的节点上，所有的磁盘组都被安装。

尝试安装磁盘组时，会出现这些错误：

SQL> alter diskgroup datadg1 mount;
alter diskgroup datadg1 mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15063: ASM discovered an insufficient number of disks for diskgroup “DATADG1″
ORA-15038: disk ” size mismatch with diskgroup [1048576] [4096] [512]
ORA-15038: disk ” size mismatch with diskgroup [1048576] [4096] [512]
ORA-15038: disk ” size mismatch with diskgroup [1048576] [4096] [512]
关于错误 ORA-15038:

 ORA-15038 (ORA-15038) 
Text: disk ‘%s’ size mismatch with diskgroup [%s] [%s] [%s]
Cause: An attempt was made to mount into a diskgroup a disk whose recorded allocation unit size,
metadata block size, or physical sector size was inconsistent with the other diskgroup members.
Action: Check if the system configuration has changed.

错误 ORA-15038的调用堆栈

kfgrpJoin <- kfgDiscoverGroup  <- kfgFinalizeMount  <- kfgscFinalize <- kfgForEachKfgsc <- kfgsoFinalize <- kfgFinalize <- kfxdrvMount

表1.磁盘组datadg1使用的磁盘显示信息。

使用设备/dev/raw[345]对有关磁盘配置的重要细节进行验证：

1.磁盘路径和绑定与工作及出错节点上的相同。

2.Oracle用户在两个节点都有所有权和R / W权限。

3.两个节点上磁盘头的内容相同，通过KFED完成验证。

4.f盘命令在两个节点返回相同的配置。

5.磁盘组DATADG1仍然安装在工作节点上,使用原始设备RAW3，raw4和raw5。

6.有效节点上安装磁盘组所使用的完整的磁盘列表是从raw3到raw16。

变化

四节点中的两个被逐出群集后就会报错。

有从gv$asm_disk返回的附加行：

MOUNT_STATE值为IGNORED的设备列表是盘raw17到raw30。

原因

为ORA-15038激活事件错误堆栈后，下列信息会打印到跟踪文件：

Ignoring dsk due to grp time stamp mismatch
disk: num: 1/0 grp: 0/0 compat: 10.1.0.0.0 dbcompat:10.1.0.0.0
fg: path: /dev/raw/raw29
mnt: O hdr: M mode: N sta: N flg: 1
kfts: 2005/12/27 12:18:28.884000
kfts: 2007/12/08 14:33:42.678000
pcnt: 0 ()
kfkid: 0x659fcb28, kfknm: , status: IDENTIFIED
fob: (KSFD)66962bd0, magic: bebe ausize: 0
kfdds: dn=1 inc=0 dsk=0x659ef1e8 usrp=0x2a97d4dfd8
kfkds 0x2a97dd3b00, kfkid 0x659fcb28, magic abbe, libnum 0, bpau 0, fob 0x66967168

或者是

Ignoring disk because of the presence of a better disk 
disk: num: 10/180388626432 grp: 0/180388626432 compat: 10.1.0.0.0 dbcompat:10.1.0.0.0
fg: path: /dev/raw/raw20
mnt: O hdr: M mode: N sta: N flg: 1
kfts: 2005/12/27 12:16:51.110000
kfts: 2007/12/08 14:33:42.181000
pcnt: 0 ()
kfkid: 0x659fe340, kfknm: , status: IDENTIFIED
fob: (KSFD)66963c88, magic: bebe ausize: 0
kfdds: dn=10 inc=0 dsk=0x659f0d60 usrp=0x2a97d4da38
kfkds 0x2a97daf490, kfkid 0x659fe340, magic abbe, libnum 0, bpau 0, fob 0x66967948

上面显示的数据，是安装磁盘组时发现的磁盘上产生的。该列表是raw17，raw18，…一直到raw30。这些与目前工作节点上使用的设备并不相同。

使用kfed检查ASM头，发现所有这些设备都拥有一个有效的盘头，并且属于磁盘组DATADG1。比如，我们只检查扫描的最后一个设备， /dev/raw/raw20,它属于盘DATADG1_0000：

Disk Number          –> kfdhdb.dsknum: 0 ; 0x024: 0x0000
Header Status        –> kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
Disk name              –> kfdhdb.dskname: DATADG1_0000 ; 0x028: length=12
Diskgroup Name  –> kfdhdb.grpname: DATADG1 ; 0x048: length=7

================================== 
DUMPING DISK : raw20 
==================================
kfbh.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: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 1395508641 ; 0x00c: 0x532dc5a1
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000
kfdhdb.compat: 168820736 ; 0x020: 0x0a100000
kfdhdb.dsknum: 0 ; 0x024: 0x0000 
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL 
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER 
kfdhdb.dskname: DATADG1_0000 ; 0x028: length=12 
kfdhdb.grpname: DATADG1 ; 0x048: length=7 
kfdhdb.fgname: DATADG1_0000 ; 0x068: length=12 
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32863084 ; 0x0a8: HOUR=0xc DAYS=0x1b MNTH=0xc YEAR=0x7d5 
kfdhdb.crestmp.lo: 1127331840 ; 0x0ac: USEC=0x0 MSEC=0x6e SECS=0x33 MINS=0x10 
kfdhdb.mntstmp.hi: 32895246 ; 0x0b0: HOUR=0xe DAYS=0x8 MNTH=0xc YEAR=0x7d7 
kfdhdb.mntstmp.lo: 2258818048 ; 0x0b4: USEC=0x0 MSEC=0xb5 SECS=0x2a MINS=0x21

一旦所有的设备都通过kfed检查， raw19,raw20,raw27 and raw30确定磁盘拥有有效的 ASM 盘头，所属磁盘组为datadg1。

问题原因

盘扫描由参数asm_diskstring决定。如果没有限定，OS平台上会有特定的默认值。Oracle用户拥有R / W权限的所有设备都将被扫描，没有特定的顺序。

在退出的节点，磁盘组读取设备raw19，raw20，raw27，raw30，所属磁盘组为DATADG1，而在另外2个节点上，同一个磁盘组读取磁盘RAW3，raw4和raw5。在退出的节点上选择不同的顺序。

在RAC环境中安装磁盘组时，磁盘头上的数据属于已经安装在集群内其他实例上共享模式中的同一磁盘组，这是有效数据。有效数据包括磁盘数量，创建和安装时间戳等。

如之前所述，报错前扫描的最后一个磁盘是raw20。存储在磁盘上的信息属于磁盘DATADG1_0000。正确安装在其他两个节点上的同一磁盘的OS操作系统路径是raw3。比较两个磁盘头的内容，很明显，raw20识别的磁盘与RAW3识别的磁盘不是同一个。

请注意时间戳数据的区别（创建，安装）:

解决方案

1. 在退出的节点上，或是磁盘集不能安装的节点，修改参数asm_diskstring的值，以便能够发现工作节点已经发现的相同设备。 强制排除磁盘发现的不正确的设备。

sql>alter system set asm_diskstring=’/dev/raw/raw3′,’/dev/raw/raw5′,’/dev/raw/raw4′;

其他替代解决方案是改变不正确的设备的所有权和权限（raw17，raw18… raw30）。如果Oracle进程无法读取它们，就不会被ASM发现。

最后，如果不需要“不正确”的设备的内容，那么清除ASM头：

$dd if=/dev/zero of=/dev/raw/raw17 bs=1M count=1 conv=notrunc

NOTE:  This syntax is different across platforms, specifically the value specified for bs, where the numeric value is required.