如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
症状
四个节中的两个被从丛中驱除,两个节重新加入到丛之后,安装了相同的磁盘组,但是安装一个特别的磁盘组失败,在未受影响的节点上,所有的磁盘组都已安装。
尝试安装磁盘组时,报告下列错误:
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使用的磁盘的信息
PATH | GROUP# | NAME | MOUNT_STATE | HEADER_STATUS | MODE_STATE | STATE | INST_ID |
/dev/raw/raw3 | 2 | DATADG1_0000 | CACHED | MEMBER | ONLINE | NORMAL | 1 |
/dev/raw/raw3 | 2 | DATADG1_0000 | CACHED | MEMBER | ONLINE | NORMAL | 4 |
/dev/raw/raw4 | 2 | DATADG1_0001 | CACHED | MEMBER | ONLINE | NORMAL | 1 |
/dev/raw/raw4 | 2 | DATADG1_0001 | CACHED | MEMBER | ONLINE | NORMAL | 4 |
/dev/raw/raw5 | 2 | DATADG1_0002 | CACHED | MEMBER | ONLINE | NORMAL | 1 |
/dev/raw/raw5 | 2 | DATADG1_0002 | CACHED | MEMBER | ONLINE | NORMAL | 4 |
使用设备/dev/raw[345]验证了有关磁盘配置的重要细节:
- 磁盘的路径和约束在工作和失败节点上是一样的。
- 在两个节点上Oracle用户拥有所有权和权限RW。
- 两个节点中的磁盘头的内容是一样的,通过kfed完成验证
- 在两个节点上,fdisk命令返回相同的配置。
- 使用原始设备原材料3,原材料4 和原材料5在工作节点上磁盘组DATADG1处于安装状态
- 有效节点上安装的磁盘组所使用的完整的磁盘号是从原材料3到原材料16。
改变
两个节点从丛中驱除之后,报告问题。
从gv$asm_disk返回额外的行:
PATH | GROUP# | NAME | MOUNT_STATE | HEADER_STATUS | MODE_STATE | STATE | INST_ID |
/dev/raw/raw17 | 0 | IGNORED | MEMBER | ONLINE | NORMAL | 1 | |
/dev/raw/raw17 | 0 | IGNORED | MEMBER | ONLINE | NORMAL | 2 | |
/dev/raw/raw17 | 0 | IGNORED | MEMBER | ONLINE | NORMAL | 3 | |
/dev/raw/raw17 | 0 | IGNORED | MEMBER | ONLINE | NORMAL | 4 | |
磁盘的带有 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确认的磁盘不是同一个。
注意在时间标记数据中的差异性(创建,安装):
raw3 | raw20 |
kfdhdb.crestmp.hi: 32873168 ; 0x0a8: HOUR=0x10 DAYS=0x16 MNTH=0x6 YEAR=0x7d6 kfdhdb.crestmp.lo: 3423030272 ; 0x0ac: USEC=0x0 MSEC=0x1d3 SECS=0x0 MINS=0x33 kfdhdb.mntstmp.hi: 32894322 ; 0x0b0: HOUR=0x12 DAYS=0xb MNTH=0xb YEAR=0x7d7 kfdhdb.mntstmp.lo: 182945792 ; 0x0b4: USEC=0x0 MSEC=0x1e2 SECS=0x2e MINS=0x2 |
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 |
解决方法
- 在退出的节点上或是在不能安装磁盘组的节点上, 修改参数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.
Comment