Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to repair ASM disk head information damage problem", the content of the article is simple and clear, easy to learn and understand, the following please follow the editor's ideas slowly in depth, together to study and learn "how to repair ASM disk head information damage problem"!

KFED is mainly used to edit and repair ASM metadata, and can be used when DiskGroup does not have mount; therefore, you can try to use this artifact to fix it when ASM cannot be started and DiskGroup cannot mount.

The kfed tool supports operations such as READ/WRITE/MERGE/NEW/ FORM/FIND/STRUCT for ASM information, and 11gR2 needs to be compiled manually before.

I. compiling kfed tools

1. Compile

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

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

two。 Configure environment variables

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

3. View help

[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 metadata is stored on each disk of asm, and the size of metadata is generally 4k. Disk header is usually on the 0th au and 0th block.

Second, simulated damaged disk head information

1. Backup disk head information:

[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

Backup to txt format

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

two。 View backup disk head information

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

Kfbh.endian: 1; 0x000: 0x01

Kfbh.hard: 130,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-- disk group redundancy

Kfdhdb.hdrsts: 3; 0x027: KFDHDR_MEMBER-disk group status, 3 is available

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

Kfdhdb.grpname: DATADG01; 0x048: length=8-name of the disk group

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-the size of the au, in byte, is 1m

Kfdhdb.mfact: 113792; 0x0c0: 0x0001bc80

Kfdhdb.dsksize: 4008; 0x0c4: 0x00000fa8-the size of the disk (in au). The default au is 1m, so the size is 4008m.

Kfdhdb.pmcnt: 2; 0x0c8: 0x00000002

Kfdhdb.fstlocn: 1; 0x0cc: 0x00000001

Kfdhdb.altlocn: 2; 0x0d0: 0x00000002

Kfdhdb.f1b1locn: 0; 0x0d4: 0x00000000-- the au location where file directory is located

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. Destroy the metadata of the disk head, where I first destroyed the raw5, and later destroyed the following two to achieve the effect

[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. Check the status of the disk head

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

It's in a normal state.

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

Here is the state after destruction, and the raw state is CANDIDATE.

5. View the information of the disk head of raw5 with kfed after destruction

[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 [.]

Repeat 255 times

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

You can see that it has been reported wrong, which is different from the one above.

View the disk head information of raw6 and raw7 in turn

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

Version header information after 10.2.0.5 is protected and backed up, so where is the backup?

Also in the specific location of disk, this pair of au=1MB dg, the backup information is in the location 510blkn, we can look at the information of location 510:

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

Kfbh.type: 1; 0x002: KFBTYP_DISKHEAD

You can see that 510 is indeed a HEAD message. Read it out.

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

Kfbh.endian: 1; 0x000: 0x01

Kfbh.hard: 130,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

By comparison, we can find that the content of the raw5 disk head is the same as before.

6. Since the raw5 disk head information has been destroyed before, let's see if there is any error.

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

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

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to an idle instance.

SQL > startup-- restart the database and found an error

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

Check the asm log.

SQL > ALTER DISKGROUP DATADG01 MOUNT / * asm agent * / / * {2asm agent 10674 asm agent 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"

What you can see is that datadg01 cannot mount

Viewed through asmcmd, datadg01 disk groups are all gone.

[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/

Third, repair the disk head

Method 1: kfed repair disk head

[grid@s1-11g dev] $

Kfed repair / dev/raw/raw5

Kfed repair / dev/raw/raw6

Kfed repair / dev/raw/raw7

Method 2: dd repair, using the previous backup

[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

Method 3: use the kfed tool of oracle to back up, the format is text format, and use kfed merge to restore.

Backup:

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

Restore:

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

What I use here is the first method to fix it.

1. View the disk head information after the restore is complete:

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

Kfbh.type: 1; 0x002: KFBTYP_DISKHEAD

two。 Then successfully mount the disk group

3. If you check the dg status, you can see that it is mounted status.

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/

You can see that datadg02 has tied the knot with mount

3. Re-query disk groups and disk information

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

You can see that all the states are normal and the database starts normally.

Thank you for your reading, the above is the content of "how to repair the ASM disk head information damage problem". After the study of this article, I believe you have a deeper understanding of how to repair the ASM disk head information damage problem, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.