怎么修复ASM磁盘头信息损坏问题

这篇文章主要讲解了“怎么修复ASM磁盘头信息损坏问题”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么修复ASM磁盘头信息损坏问题”吧！

创新互联建站是一家集网站建设,神农架林区企业网站建设,神农架林区品牌网站建设,网站定制,神农架林区网站建设报价,网络营销,网络优化,神农架林区网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

KFED主要用来编辑和修复ASM metadata,可以在DiskGroup没有mount的情况下使用;因此在ASM无法启动、DiskGroup无法mount的时候可以尝试使用这个神器来修复。

kfed工具支持对于ASM信息的READ/WRITE/MERGE/NEW/ FORM/FIND/STRUCT等操作，11gR2之前需要手工编译.

一、编译kfed工具

1.编译

[oracle@node1 ~]$ cd $ORACLE_HOME/rdbms/lib

[oracle@node1 lib]$ make -f ins_rdbms.mk ikfed

2.配置环境变量

export PATH=$ORACLE_HOME/bin:$ORACLE_HOME/rdbms/lib:$PATH

3.查看帮助

[oracle@node1 ~]$ kfed -help

as/mlibASM Library [asmlib='lib']

aun/umAU number to examine or update [AUNUM=number]

aus/zAllocation Unit size in bytes [AUSZ=number]

blkn/umBlock number to examine or update [BLKNUM=number]

blks/zMetadata block size in bytes [BLKSZ=number]

ch/ksumUpdate checksum before each write [CHKSUM=YES/NO]

cn/tCount of AUs to process [CNT=number]

de/vASM device to examine or update [DEV=string]

dm/pallDon't suppress repeated lines when dumping corrupt blocks [DMPALL=YES/NO]

o/p KFED operation type [OP=READ/WRITE/MERGE/REPAIR/NEW/FORM/FIND/STRUCT]

p/rovnmName for provisioning purposes [PROVNM=string]

s/eekAU number to seek to [SEEK=number]

te/xtFile name for translated block text [TEXT=string]

ty/peASM metadata block type number [TYPE=number]

asm的每个磁盘上有存放有asm的元数据，元数据一般大小为4k。disk header一般在第0个au,第0个块上。

二、模拟损坏磁盘头信息

1. 备份磁盘头信息：

[root@axj-rac1 backup]#dd if=/dev/raw/raw5 of=/backup/raw5.bak bs=1M count=2

[root@axj-rac1 backup]#dd if=/dev/raw/raw6 of=/backup/raw6.bak bs=1M count=2

[root@axj-rac1 backup]#dd if=/dev/raw/raw7 of=/backup/raw7.bak bs=1M count=2

备份成txt格式

kfed read /dev/raw/raw6 text=/home/oracle/asmdisk_raw6.txt

2. 查看备份的磁盘头信息

[root@axj-rac1 oracle]# cat asmdisk_raw6.txt

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: 2147483649 ; 0x008: disk=1

kfbh.check: 3657275721 ; 0x00c: 0xd9fd9949

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: 186646528 ; 0x020: 0x0b200000

kfdhdb.dsknum: 1 ; 0x024: 0x0001

kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL --磁盘组冗余方式

kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER --磁盘组状态，3是可用状态

kfdhdb.dskname: DATADG01_0001 ; 0x028: length=13

kfdhdb.grpname: DATADG01 ; 0x048: length=8 --磁盘组名字

kfdhdb.fgname: DATADG01_0001 ; 0x068: length=13

kfdhdb.capname: ; 0x088: length=0

kfdhdb.crestmp.hi: 33026093 ; 0x0a8: HOUR=0xd DAYS=0x1 MNTH=0xc YEAR=0x7df

kfdhdb.crestmp.lo: 2356159488 ; 0x0ac: USEC=0x0 MSEC=0x9 SECS=0x7 MINS=0x23

kfdhdb.mntstmp.hi: 33032273 ; 0x0b0: HOUR=0x11 DAYS=0x2 MNTH=0x2 YEAR=0x7e0

kfdhdb.mntstmp.lo: 3209038848 ; 0x0b4: USEC=0x0 MSEC=0x183 SECS=0x34 MINS=0x2f

kfdhdb.secsize: 512 ; 0x0b8: 0x0200

kfdhdb.blksize: 4096 ; 0x0ba: 0x1000

kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000 --au的大小，单位是byte,大小是1M

kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80

kfdhdb.dsksize: 4008 ; 0x0c4: 0x00000fa8 --该disk的大小，单位是au，默认au是1m，所以大小为4008M

kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002

kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001

kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002

kfdhdb.f1b1locn: 0 ; 0x0d4: 0x00000000 --file directory所在的au位置

kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000

kfdhdb.redomirrors[1]: 0 ; 0x0da: 0x0000

kfdhdb.redomirrors[2]: 0 ; 0x0dc: 0x0000

kfdhdb.redomirrors[3]: 0 ; 0x0de: 0x0000

kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000

kfdhdb.grpstmp.hi: 33024790 ; 0x0e4: HOUR=0x16 DAYS=0x18 MNTH=0xa YEAR=0x7df

kfdhdb.grpstmp.lo: 258378752 ; 0x0e8: USEC=0x0 MSEC=0x1a3 SECS=0x36 MINS=0x3

kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000

kfdhdb.vfend: 0 ; 0x0f0: 0x00000000

kfdhdb.spfile: 0 ; 0x0f4: 0x00000000

kfdhdb.spfflg: 0 ; 0x0f8: 0x00000000

kfdhdb.ub4spare[0]: 0 ; 0x0fc: 0x00000000

kfdhdb.ub4spare[1]: 0 ; 0x100: 0x00000000

kfdhdb.ub4spare[2]: 0 ; 0x104: 0x00000000

kfdhdb.ub4spare[3]: 0 ; 0x108: 0x00000000

kfdhdb.ub4spare[4]: 0 ; 0x10c: 0x00000000

kfdhdb.ub4spare[5]: 0 ; 0x110: 0x00000000

kfdhdb.ub4spare[6]: 0 ; 0x114: 0x00000000

kfdhdb.ub4spare[7]: 0 ; 0x118: 0x00000000

kfdhdb.ub4spare[8]: 0 ; 0x11c: 0x00000000

kfdhdb.ub4spare[9]: 0 ; 0x120: 0x00000000

kfdhdb.ub4spare[10]: 0 ; 0x124: 0x00000000

kfdhdb.ub4spare[11]: 0 ; 0x128: 0x00000000

kfdhdb.ub4spare[12]: 0 ; 0x12c: 0x00000000

kfdhdb.ub4spare[13]: 0 ; 0x130: 0x00000000

kfdhdb.ub4spare[14]: 0 ; 0x134: 0x00000000

kfdhdb.ub4spare[15]: 0 ; 0x138: 0x00000000

kfdhdb.ub4spare[16]: 0 ; 0x13c: 0x00000000

kfdhdb.ub4spare[17]: 0 ; 0x140: 0x00000000

kfdhdb.ub4spare[18]: 0 ; 0x144: 0x00000000

kfdhdb.ub4spare[19]: 0 ; 0x148: 0x00000000

kfdhdb.ub4spare[20]: 0 ; 0x14c: 0x00000000

kfdhdb.ub4spare[21]: 0 ; 0x150: 0x00000000

kfdhdb.ub4spare[22]: 0 ; 0x154: 0x00000000

kfdhdb.ub4spare[23]: 0 ; 0x158: 0x00000000

kfdhdb.ub4spare[24]: 0 ; 0x15c: 0x00000000

kfdhdb.ub4spare[25]: 0 ; 0x160: 0x00000000

kfdhdb.ub4spare[26]: 0 ; 0x164: 0x00000000

kfdhdb.ub4spare[27]: 0 ; 0x168: 0x00000000

kfdhdb.ub4spare[28]: 0 ; 0x16c: 0x00000000

kfdhdb.ub4spare[29]: 0 ; 0x170: 0x00000000

kfdhdb.ub4spare[30]: 0 ; 0x174: 0x00000000

kfdhdb.ub4spare[31]: 0 ; 0x178: 0x00000000

kfdhdb.ub4spare[32]: 0 ; 0x17c: 0x00000000

kfdhdb.ub4spare[33]: 0 ; 0x180: 0x00000000

kfdhdb.ub4spare[34]: 0 ; 0x184: 0x00000000

kfdhdb.ub4spare[35]: 0 ; 0x188: 0x00000000

kfdhdb.ub4spare[36]: 0 ; 0x18c: 0x00000000

kfdhdb.ub4spare[37]: 0 ; 0x190: 0x00000000

kfdhdb.ub4spare[38]: 0 ; 0x194: 0x00000000

kfdhdb.ub4spare[39]: 0 ; 0x198: 0x00000000

kfdhdb.ub4spare[40]: 0 ; 0x19c: 0x00000000

kfdhdb.ub4spare[41]: 0 ; 0x1a0: 0x00000000

kfdhdb.ub4spare[42]: 0 ; 0x1a4: 0x00000000

kfdhdb.ub4spare[43]: 0 ; 0x1a8: 0x00000000

kfdhdb.ub4spare[44]: 0 ; 0x1ac: 0x00000000

kfdhdb.ub4spare[45]: 0 ; 0x1b0: 0x00000000

kfdhdb.ub4spare[46]: 0 ; 0x1b4: 0x00000000

kfdhdb.ub4spare[47]: 0 ; 0x1b8: 0x00000000

kfdhdb.ub4spare[48]: 0 ; 0x1bc: 0x00000000

kfdhdb.ub4spare[49]: 0 ; 0x1c0: 0x00000000

kfdhdb.ub4spare[50]: 0 ; 0x1c4: 0x00000000

kfdhdb.ub4spare[51]: 0 ; 0x1c8: 0x00000000

kfdhdb.ub4spare[52]: 0 ; 0x1cc: 0x00000000

kfdhdb.ub4spare[53]: 0 ; 0x1d0: 0x00000000

kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000

kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000

kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000

kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000

3.破坏磁盘头的元数据，这里我开始破坏了raw5,后来为达到效果又破坏了下面两个

[root@axj-rac1 backup]# dd if=/dev/zero of=/dev/raw/raw5 bs=4096 count=1

[root@axj-rac1 backup]# dd if=/dev/zero of=/dev/raw/raw6 bs=4096 count=1

[root@axj-rac1 backup]# dd if=/dev/zero of=/dev/raw/raw7 bs=4096 count=1

4.查看一下磁盘头的状态

col group_number format a30

col disk_number format a30

col name format a30

col header_status format a30

col path format a30

col group_number clear

col disk_number clear

set linesize 200 pagesize 2000

SQL> select group_number,disk_number,name,header_status,path from v$asm_disk;

GROUP_NUMBER DISK_NUMBER NAMEHEADER_STATU PATH

---------------------- ---------------------------

2 0 OCR_VOTE_0000MEMBER /dev/raw/raw1

1 1 DATADG01_0001MEMBER /dev/raw/raw6

2 1 OCR_VOTE_0001MEMBER /dev/raw/raw2

2 2 OCR_VOTE_0002MEMBER /dev/raw/raw3

1 0 DATADG01_0000MEMBER /dev/raw/raw5

1 2 DATADG01_0002MEMBER /dev/raw/raw7

上面是正常的状态

SQL> select group_number,disk_number,name,header_status,path from v$asm_disk;

GROUP_NUMBER DISK_NUMBER NAMEHEADER_STATUS PATH

------------ ---------------------------------------

2 0 OCR_VOTE_0000MEMBER /dev/raw/raw1

1 1 DATADG01_0001MEMBER /dev/raw/raw6

2 1 OCR_VOTE_0001MEMBER /dev/raw/raw2

2 2 OCR_VOTE_0002MEMBER /dev/raw/raw3

1 0 DATADG01_0000CANDIDATE /dev/raw/raw5

1 2 DATADG01_0002MEMBER /dev/raw/raw7

这里是破坏后的状态，raw状态为CANDIDATE

5.破坏后查看用kfed查看raw5的磁盘头的信息

[root@axj-rac1 oracle]# kfed read /dev/raw/raw5 aun=0 blkn=0

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

7F5595918400 00000000 00000000 00000000 00000000 [................]

Repeat 255 times

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

可以看到已经报错了，跟上面的不一样了。

依次查看raw6和raw7的磁盘头信息

kfed read /backup/raw6.bak aun=1 blkn=254

kfed read /backup/raw7.bak aun=1 blkn=254

[root@axj-rac1 backup]# kfed read /backup/raw5.bak aun=1 blkn=254|grep kfbh.type

kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD

从10.2.0.5开始之后的版本header信息是有额外保护和备份的，那么备份在哪个位置

也是在disk的特定位置，这对au=1MB的dg，备份信息是在第510blkn的位置，我们可以看下位置510的信息：

[root@axj-rac1 backup]# kfed read /dev/raw/raw5 aun=0 blkn=510 | grep kfbh.type

kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD

可以看到510确实也是HEAD信息把它读出来看看

[root@axj-rac1 backup]# kfed read /dev/raw/raw5 blkn=510

kfbh.endian: 1 ; 0x000: 0x01

kfbh.hard: 130 ; 0x001: 0x82

kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD

kfbh.datfmt: 1 ; 0x003: 0x01

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

kfbh.block.obj: 2147483648 ; 0x008: disk=0

kfbh.check: 323429756 ; 0x00c: 0x1347257c

kfbh.fcn.base: 16403 ; 0x010: 0x00004013

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: 186646528 ; 0x020: 0x0b200000

kfdhdb.dsknum: 0 ; 0x024: 0x0000

kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL

kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER

kfdhdb.dskname: DATADG01_0000 ; 0x028: length=13

kfdhdb.grpname: DATADG01 ; 0x048: length=8

kfdhdb.fgname: DATADG01_0000 ; 0x068: length=13

kfdhdb.capname: ; 0x088: length=0

kfdhdb.crestmp.hi: 33024790 ; 0x0a8: HOUR=0x16 DAYS=0x18 MNTH=0xa YEAR=0x7df

kfdhdb.crestmp.lo: 258502656 ; 0x0ac: USEC=0x0 MSEC=0x21c SECS=0x36 MINS=0x3

kfdhdb.mntstmp.hi: 33032273 ; 0x0b0: HOUR=0x11 DAYS=0x2 MNTH=0x2 YEAR=0x7e0

kfdhdb.mntstmp.lo: 3209038848 ; 0x0b4: USEC=0x0 MSEC=0x183 SECS=0x34 MINS=0x2f

kfdhdb.secsize: 512 ; 0x0b8: 0x0200

kfdhdb.blksize: 4096 ; 0x0ba: 0x1000

kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000

kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80

kfdhdb.dsksize: 2008 ; 0x0c4: 0x000007d8

kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002

kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001

kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002

kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002

kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000

kfdhdb.redomirrors[1]: 65535 ; 0x0da: 0xffff

kfdhdb.redomirrors[2]: 65535 ; 0x0dc: 0xffff

kfdhdb.redomirrors[3]: 65535 ; 0x0de: 0xffff

kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000

kfdhdb.grpstmp.hi: 33024790 ; 0x0e4: HOUR=0x16 DAYS=0x18 MNTH=0xa YEAR=0x7df

kfdhdb.grpstmp.lo: 258378752 ; 0x0e8: USEC=0x0 MSEC=0x1a3 SECS=0x36 MINS=0x3

kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000

kfdhdb.vfend: 0 ; 0x0f0: 0x00000000

kfdhdb.spfile: 0 ; 0x0f4: 0x00000000

kfdhdb.spfflg: 0 ; 0x0f8: 0x00000000

kfdhdb.ub4spare[0]: 0 ; 0x0fc: 0x00000000

kfdhdb.ub4spare[1]: 0 ; 0x100: 0x00000000

kfdhdb.ub4spare[2]: 0 ; 0x104: 0x00000000

kfdhdb.ub4spare[3]: 0 ; 0x108: 0x00000000

kfdhdb.ub4spare[4]: 0 ; 0x10c: 0x00000000

kfdhdb.ub4spare[5]: 0 ; 0x110: 0x00000000

kfdhdb.ub4spare[6]: 0 ; 0x114: 0x00000000

kfdhdb.ub4spare[7]: 0 ; 0x118: 0x00000000

kfdhdb.ub4spare[8]: 0 ; 0x11c: 0x00000000

kfdhdb.ub4spare[9]: 0 ; 0x120: 0x00000000

kfdhdb.ub4spare[10]: 0 ; 0x124: 0x00000000

kfdhdb.ub4spare[11]: 0 ; 0x128: 0x00000000

kfdhdb.ub4spare[12]: 0 ; 0x12c: 0x00000000

kfdhdb.ub4spare[13]: 0 ; 0x130: 0x00000000

kfdhdb.ub4spare[14]: 0 ; 0x134: 0x00000000

kfdhdb.ub4spare[15]: 0 ; 0x138: 0x00000000

kfdhdb.ub4spare[16]: 0 ; 0x13c: 0x00000000

kfdhdb.ub4spare[17]: 0 ; 0x140: 0x00000000

kfdhdb.ub4spare[18]: 0 ; 0x144: 0x00000000

kfdhdb.ub4spare[19]: 0 ; 0x148: 0x00000000

kfdhdb.ub4spare[20]: 0 ; 0x14c: 0x00000000

kfdhdb.ub4spare[21]: 0 ; 0x150: 0x00000000

kfdhdb.ub4spare[22]: 0 ; 0x154: 0x00000000

kfdhdb.ub4spare[23]: 0 ; 0x158: 0x00000000

kfdhdb.ub4spare[24]: 0 ; 0x15c: 0x00000000

kfdhdb.ub4spare[25]: 0 ; 0x160: 0x00000000

kfdhdb.ub4spare[26]: 0 ; 0x164: 0x00000000

kfdhdb.ub4spare[27]: 0 ; 0x168: 0x00000000

kfdhdb.ub4spare[28]: 0 ; 0x16c: 0x00000000

kfdhdb.ub4spare[29]: 0 ; 0x170: 0x00000000

kfdhdb.ub4spare[30]: 0 ; 0x174: 0x00000000

kfdhdb.ub4spare[31]: 0 ; 0x178: 0x00000000

kfdhdb.ub4spare[32]: 0 ; 0x17c: 0x00000000

kfdhdb.ub4spare[33]: 0 ; 0x180: 0x00000000

kfdhdb.ub4spare[34]: 0 ; 0x184: 0x00000000

kfdhdb.ub4spare[35]: 0 ; 0x188: 0x00000000

kfdhdb.ub4spare[36]: 0 ; 0x18c: 0x00000000

kfdhdb.ub4spare[37]: 0 ; 0x190: 0x00000000

kfdhdb.ub4spare[38]: 0 ; 0x194: 0x00000000

kfdhdb.ub4spare[39]: 0 ; 0x198: 0x00000000

kfdhdb.ub4spare[40]: 0 ; 0x19c: 0x00000000

kfdhdb.ub4spare[41]: 0 ; 0x1a0: 0x00000000

kfdhdb.ub4spare[42]: 0 ; 0x1a4: 0x00000000

kfdhdb.ub4spare[43]: 0 ; 0x1a8: 0x00000000

kfdhdb.ub4spare[44]: 0 ; 0x1ac: 0x00000000

kfdhdb.ub4spare[45]: 0 ; 0x1b0: 0x00000000

kfdhdb.ub4spare[46]: 0 ; 0x1b4: 0x00000000

kfdhdb.ub4spare[47]: 0 ; 0x1b8: 0x00000000

kfdhdb.ub4spare[48]: 0 ; 0x1bc: 0x00000000

kfdhdb.ub4spare[49]: 0 ; 0x1c0: 0x00000000

kfdhdb.ub4spare[50]: 0 ; 0x1c4: 0x00000000

kfdhdb.ub4spare[51]: 0 ; 0x1c8: 0x00000000

kfdhdb.ub4spare[52]: 0 ; 0x1cc: 0x00000000

kfdhdb.ub4spare[53]: 0 ; 0x1d0: 0x00000000

kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000

kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000

kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000

kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000

通过对比我们可以发现与之前的raw5磁盘头的内容是一摸一样的。

6.由于之前破坏掉了raw5磁盘头信息，看看有啥报错

[oracle@axj-rac1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Wed Mar 9 15:09:17 2016

Connected to an idle instance.

SQL> startup --重启数据库发现报错了

ORA-01078: failure in processing system parameters

ORA-01565: error in identifying file '+DATADG01/rac11g/spfilerac11g.ora'

ORA-17503: ksfdopn:2 Failed to open file +DATADG01/rac11g/spfilerac11g.ora

ORA-15077: could not locate ASM instance serving a required diskgroup

看看asm日志

SQL> ALTER DISKGROUP DATADG01 MOUNT /* asm agent *//* {2:10674:2} */

NOTE: cache registered group DATADG01 number=1 incarn=0xbec84ee5

NOTE: cache began mount (first) of group DATADG01 number=1 incarn=0xbec84ee5

Wed Mar 09 15:10:28 2016

ERROR: no read quorum in group: required 2, found 0 disks

NOTE: cache dismounting (clean) group 1/0xBEC84EE5 (DATADG01)

NOTE: messaging CKPT to quiesce pins Unix process pid: 3711, image: oracle@axj-rac1 (TNS V1-V3)

NOTE: dbwr not being msg'd to dismount

NOTE: lgwr not being msg'd to dismount

NOTE: cache dismounted group 1/0xBEC84EE5 (DATADG01)

NOTE: cache ending mount (fail) of group DATADG01 number=1 incarn=0xbec84ee5

NOTE: cache deleting context for group DATADG01 1/0xbec84ee5

GMON dismounting group 1 at 7 for pid 29, osid 3711

ERROR: diskgroup DATADG01 was not mounted

ORA-15032: not all alterations performed

ORA-15017: diskgroup "DATADG01" cannot be mounted

ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATADG01"

可以看到的是datadg01无法mount

通过asmcmd查看,datadg01磁盘组都没了

[grid@axj-rac1 trace]$ asmcmd

ASMCMD> lsdg

State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name

MOUNTED EXTERN N 512 4096 1048576 6024 5623 0 5623 0 Y OCR_VOTE/

三、修复磁盘头

方法一：kfed修复磁盘头

[grid@s1-11g dev]$

kfed repair /dev/raw/raw5

kfed repair /dev/raw/raw6

kfed repair /dev/raw/raw7

方法二: dd修复，用之前的备份

[grid@s1-11g dev]$

dd if=/backup/raw5 of=/dev/raw/raw5

dd if=/backup/raw6 of=/dev/raw/raw6

dd if=/backup/raw7 of=/dev/raw/raw7

方法三：利用oracle的kfed工具来备份,格式是文本格式，恢复时使用kfed merge进去

备份：

kfed read /dev/raw/raw5 aunum=0 blknum=0 text=/home/oracle/raw5.txt

kfed read /dev/raw/raw6 aunum=0 blknum=0 text=/home/oracle/raw6.txt

kfed read /dev/raw/raw7 aunum=0 blknum=0 text=/home/oracle/raw7.txt

恢复：

kfed write /dev/raw/raw5 aunum=0 blknum=0 text=raw5.txt

kfed write /dev/raw/raw6 aunum=0 blknum=0 text=raw6.txt

kfed write /dev/raw/raw7 aunum=0 blknum=0 text=raw7.txt

这里我用的是方法一修复的

1.恢复完成后查看磁盘头信息：

[root@axj-rac1 oracle]# kfed read /dev/raw/raw5 aun=0 blkn=0|grep kfbh.type

kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD

2.然后成功mount磁盘组

3.查看dg状态可以看到是mounted状态

ASMCMD> lsdg

State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name

MOUNTED EXTERN N 512 4096 1048576 10024 6581 0 6581 0 N DATADG01/

MOUNTED EXTERN N 512 4096 1048576 6024 5623 0 5623 0 Y OCR_VOTE/

可以看到datadg02已结mount了

3.重新查询磁盘组以及磁盘信息

col group_number format a30

col disk_number format a30

col name format a30

col header_status format a30

col path format a30

col group_number clear

col disk_number clear

set linesize 200 pagesize 2000

SQL>select group_number,disk_number,name,header_status,path from v$asm_disk;

GROUP_NUMBER DISK_NUMBER NAMEHEADER_STATUS PATH

------------ ----------- -----------------------------

1 1 DATADG01_0001MEMBER /dev/raw/raw6

1 0 DATADG01_0000MEMBER /dev/raw/raw5

2 1 OCR_VOTE_0001MEMBER /dev/raw/raw2

2 0 OCR_VOTE_0000MEMBER /dev/raw/raw1

1 2 DATADG01_0002MEMBER /dev/raw/raw7

2 2 OCR_VOTE_0002MEMBER /dev/raw/raw3

可以看到所有状态已经正常,数据库也正常启动。

感谢各位的阅读，以上就是“怎么修复ASM磁盘头信息损坏问题”的内容了，经过本文的学习后，相信大家对怎么修复ASM磁盘头信息损坏问题这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！

当前题目：怎么修复ASM磁盘头信息损坏问题
当前路径：http://scyanting.com/article/jegehc.html

怎么修复ASM磁盘头信息损坏问题

其他资讯