如何复原/维修/修复被覆盖的 (KFBTYP_INVALID) ASM 磁盘头 (First 4K) 10.2.0.5, 11.1.0.7, 11.2 及以后版本

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

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

服务热线 : 13764045638    QQ号:47079569    邮箱:service@parnassusdata.com

 

适用于:

Oracle Database – 企业版版本 10.2.0.5 12.1.0.1 [版本 10.2 12.1]
本文献中的所有信息适用于所有的平台。

目标

当前文献提供了一个例子,关于如何复原/维修/修复被覆盖的 (KFBTYP_INVALID) ASM 磁盘头 (First 4K) 10.2.0.5, 11.1.0.7, 11.2 及以后版本。

解决方法

ASM 磁盘头的复制 (first 4K)存在于版本 10.2.0.5, 11.1.0.7, 11.2 及以后中,它可以用来尝试复原一个有效的 ASM磁盘头 (假设只有磁盘的第一个4k 受到影响/覆盖),为了复原ASM 磁盘头(假设自动的ASM磁盘头备份处于良好的状态),请执行接下来的步骤:


1)
备份受影响的第一个50MB (该步骤是强制的):

$> dd if=<full path affected disk name> of=/tmp/<affected disk name>.dump bs=1048576 count=50

例如:

[grid@dbaasm ~]$ dd if=/dev/oracleasm/disks/ASMDISK2 of=/tmp/ASMDISK2.dump bs=1048576 count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 0.667474 seconds, 78.5 MB/s

这里: “/dev/oracleasm/disks/ASMDISK2是受影响的ASM磁盘成员。


2) 
从另一个正常的磁盘成员收集分配单元大小(kfdhdb.ausize)(从同一个受影响的磁盘组):

$> <ASM Oracle Home>/bin/kfed read <full path healthy disk name> | egrep ‘ausize|dsknum|dskname|grpname|fgname’

例如:

[grid@dbaasm ~]$ kfed read /dev/oracleasm/disks/ASMDISK1  | egrep ‘ausize|dsknum|dskname|grpname|fgname’

kfdhdb.dsknum:                        0 ; 0x024: 0x0000
kfdhdb.dskname:                ASMDISK1 ; 0x028: length=8
kfdhdb.grpname:                    DATA ; 0x048: length=4
kfdhdb.fgname:                 FG1_SAN1 ; 0x068: length=8
kfdhdb.ausize:                  2097152 ; 0x0bc: 0x00200000

注释: 在这个例子中, 使用AU_SIZE=2M (2097152 ) 创建磁盘组, /dev/oracleasm/disks/ASMDISK1″ 是正常的ASM 磁盘成员。


3)
然后从备份复原ASM 磁盘头,如下:

$> <ASM Oracle Home>/bin/kfed repair <full path affected disk name> ausz=<AU size from point #2>

例如:

[grid@dbaasm ~]$ kfed repair /dev/oracleasm/disks/ASMDISK2  ausz=2097152


4)
验证受影响的磁盘中的ASM 磁盘头被重建/复原:

$> <ASM Oracle Home>/bin/kfed read <full path affected disk name>  | head -40

例如:

[grid@dbaasm ~]$  kfed read /dev/oracleasm/disks/ASMDISK2  | head -40
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: blk=0
kfbh.block.obj:              2147483650 ; 0x008: disk=2
kfbh.check:                  4052202307 ; 0x00c: 0xf187b343
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: ORCLDISKASMDISK2 ; 0x000: length=16
kfdhdb.driver.reserved[0]:   1145918273 ; 0x008: 0x444d5341
kfdhdb.driver.reserved[1]:    843797321 ; 0x00c: 0x324b5349
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:                186647296 ; 0x020: 0x0b200300
kfdhdb.dsknum:                        2 ; 0x024: 0x0002
kfdhdb.grptyp:                        2 ; 0x026: KFDGTP_NORMAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:                ASMDISK2 ; 0x028: length=8
kfdhdb.grpname:                    DATA ; 0x048: length=4
kfdhdb.fgname:                 FG2_SAN2 ; 0x068: length=8
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             32974423 ; 0x0a8: HOUR=0x17 DAYS=0x12 MNTH=0x9 YEAR=0x7dc
kfdhdb.crestmp.lo:           1180930048 ; 0x0ac: USEC=0x0 MSEC=0xe4 SECS=0x26 MINS=0x11
kfdhdb.mntstmp.hi:             33003184 ; 0x0b0: HOUR=0x10 DAYS=0x15 MNTH=0x5 YEAR=0x7de
kfdhdb.mntstmp.lo:           1230240768 ; 0x0b4: USEC=0x0 MSEC=0xff SECS=0x15 MINS=0x12
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
kfdhdb.ausize:                  2097152 ; 0x0bc: 0x00200000
kfdhdb.mfact:                    228480 ; 0x0c0: 0x00037c80
kfdhdb.dsksize:                    9769 ; 0x0c4: 0x00002629
kfdhdb.pmcnt:                         2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001
kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn:                      0 ; 0x0d4: 0x00000000
kfdhdb.redomirrors[0]:                0 ; 0x0d8: 0x0000
.
.
.
.

5) 最后, 安装磁盘组:

SQL> alter diskgroup <diskgroup name> mount ;

例如:

SQL> alter diskgroup DATA mount;

Diskgroup altered.

注释

注释 1:如果下列条件是正确的,本文献中提供的方法就会起作用:

   a) 只有受影响的第一个4K 被覆盖/清除/重叠。

   b) ASM 磁盘头备份处于良好的状态。

注释2: 如果这种方法不能解决你的问题, 那么不要在受影响的磁盘组上尝试其他步骤/措施, 因此请通过新的服务请求寻求Oracle 支持,以确定问题的根源和可能的解决方法。

注释3:带有一个损坏的磁盘头ASM 磁盘会产生下列输出

[grid@dbaasm ~]$ kfed read /dev/oracleasm/disks/ASMDISK2

kfbh.endian:                          0 ; 0x000: 0x00

kfbh.hard:                            0 ; 0x001: 0x00

kfbh.type:                            0 ; 0x002: KFBTYP_INVALID

kfbh.datfmt:                          0 ; 0x003: 0x00

kfbh.block.blk:                       0 ; 0x004: blk=0

kfbh.block.obj:                       0 ; 0x008: file=0

kfbh.check:                           0 ; 0x00c: 0x00000000

kfbh.fcn.base:                        0 ; 0x010: 0x00000000

kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000

kfbh.spare1:                          0 ; 0x018: 0x00000000

kfbh.spare2:                          0 ; 0x01c: 0x00000000

000000000 00000000 00000000 00000000 00000000  […………….]

  Repeat 255 times

KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]

关注dbDao.com的新浪微博

扫码关注dbDao.com 微信公众号:

沪公网安备 31010802001379号

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