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

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

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

症状

四个节中的两个被从丛中驱除，两个节重新加入到丛之后，安装了相同的磁盘组，但是安装一个特别的磁盘组失败，在未受影响的节点上，所有的磁盘组都已安装。

尝试安装磁盘组时，报告下列错误:

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)
文本: 磁盘’%s’ 大小与磁盘组 [%s] [%s] [%s] 不匹配
原因:试图安装一个磁盘到一磁盘组，其记录的分配单元的大小，元数据块大小，或者物理扇区大小与其他磁盘组成员不一致。
措施:检查是否改变了系统配置。

为错误ORA-15038调用堆栈

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

表1. 显示有关磁盘组DATADG1使用的磁盘的信息

使用设备/dev/raw[345]验证了有关磁盘配置的重要细节:

1. 磁盘的路径和约束在工作和失败节点上是一样的。
2. 在两个节点上Oracle用户拥有所有权和权限RW。
3. 两个节点中的磁盘头的内容是一样的，通过kfed完成验证
4. 在两个节点上，fdisk命令返回相同的配置。
5. 使用原始设备原材料3,原材料4 和原材料5在工作节点上磁盘组DATADG1处于安装状态
6. 有效节点上安装的磁盘组所使用的完整的磁盘号是从原材料3到原材料16。

改变

两个节点从丛中驱除之后，报告问题。

从gv$asm_disk返回额外的行:

磁盘的带有 MOUNT_STATE值IGNORED 的设备列表是从原材料17到30。

原因

为错误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

上面显示的数据, 安装磁盘组时由每个发现的磁盘产生，列表是原材料17,原材料18,… 到原材料30，这些都不是目前的工作节点上使用的相同的设备，

所有这些设备中，使用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回顾了所有的设备,通过原材料19,原材料20,原材料27和原材料30 确认的磁盘对磁盘组DATADG1有有效的ASM 磁盘头。

产生问题的原因

磁盘扫描由asm_diskstring决定，如果没有定义，存在特定于OS平台的默认值。Oracle 用户有 R/W 特权的的所有设备会进行扫描，没有特定的顺序。

在退出的节点上,磁盘组正在为磁盘组DATADG1读取设备原材料19,原材料20,原材料27,原材料30, 然而在其他两个节点上, 同样的磁盘组正在读取磁盘原材料3,原材料4 和原材料5，在退出的节点上有不同的顺序。

在RAC环境中安装磁盘组时, 证明磁盘头部发现的数据属于同一个磁盘组，早已在该丛其它实例共享模式下安装，在这些验证的数据之间是磁盘号，创建和安装时间标记等等。

之前提到过在报告错误之前浏览的最后一个磁盘是原材料20，存储在那个磁盘上的信息属于磁盘DATADG1_0000，在其他两个节点上正确安装的同一个磁盘的OS 路径是原材料3，比较两个磁盘的头的内容，很明显由原材料20确认的磁盘和由原材料3确认的磁盘不是同一个。

注意在时间标记数据中的差异性(创建,安装):

解决方法

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.