ASM磁盘头损坏修复
ASM磁盘头损坏修复
- 查看正常ASM磁盘磁盘头信息
- od
- bbed
- UE
- 磁盘头损坏检查
- kfed查看
- kfed find
- 磁盘头损坏修复
- kfed repair
- dd
- 手工重构磁盘头
- 补充---2号元数据文件disk directory
- 结论
asm disk header，顾名思义就是磁盘头块，那显然就是在disk的第一个block中。这里需要注意的是，操作系统block是4k，而不是常见的数据库block_size 8k。
命令介绍：
kfed read
使用kfed来可以读取一个ASM元数据块（4K大小），它的语法是：
$ kfed read [aun=ii aus=jj blkn=kk dev=]asm_disk_name
命令行参数的介绍：
aun-读取的AU号，如果不提供值，默认为AU 0
aus-AU的大小，默认为1048576字节（1MB），如果磁盘组不是默认的AU大小，那么需要在命令行中显式的指定AU的大小
blkn-读取的块号，默认为块0或者是AU的第一个block
dev-ASM磁盘或设备名称。注意dev关键字可省略，但是磁盘名是必须输入的
kfed的find命令会检查一个AU上的所有块，然后返回每一个块的类型：
$ kfed find [aun=ii aus=jj dev=]asm_disk_name
find命令一定程度上跟之前的read命令很想象，但是find命令会对指定AU上的所有块进行读取操作。（read只会操作一个块）
，kfed的find命令只能查看ASM元数据块的类型，不能查看实际的元数据块的内容，一些ASM元数据块的损坏其实是块内容的损坏，例如块类型是正确的，但是块的内容已经损坏。这种毁坏只能在ASM读取的时候才能检测到
查看正常ASM磁盘磁盘头信息
od
[grid@11gasm ~]$ dd if=/dev/asm_data01 of=/tmp/header bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.00012092 s, 33.9 MB/s
[root@11gasm ~]# od -x /tmp/header
0000000 8201 0101 0000 0000 0000 8000 450c b4d0
0000020 0000 0000 0000 0000 0000 0000 0000 0000
0000040 524f 4c43 4944 4b53 0000 0000 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
0000100 0000 0b20 0000 0301 4144 4154 4744 305f
0000120 3030 0030 0000 0000 0000 0000 0000 0000
0000140 0000 0000 0000 0000 4144 4154 4744 0000
0000160 0000 0000 0000 0000 0000 0000 0000 0000
0000200 0000 0000 0000 0000 4144 4154 4744 305f
0000220 3030 0030 0000 0000 0000 0000 0000 0000
0000240 0000 0000 0000 0000 0000 0000 0000 0000
*
0000300 0000 0000 0000 0000 ebf7 01f8 4800 1ee6
0000320 1b8e 01f9 5800 6018 0200 1000 0000 0040
0000340 ee80 0006 0500 0000 0002 0000 0001 0000
0000360 0002 0000 0002 0000 0000 0000 0000 0000
0000400 0000 0a10 ebf7 01f8 3800 1ee5 0000 0000
0000420 0000 0000 000a 0000 0001 0000 0000 0000
0000440 0000 0000 0000 0000 0000 0000 0000 0000
*
0010000
bbed
BBED> set FILENAME '/tmp/header'FILENAME /tmp/headerBBED> show allFILE# 0BLOCK# 1OFFSET 0DBA 0x00000000 (0 0,1)FILENAME /tmp/headerBIFILE bifile.bbdLISTFILE BLOCKSIZE 512MODE BrowseEDIT UnrecoverableIBASE DecOBASE DecWIDTH 80COUNT 512LOGFILE log.bbdSPOOL NoBBED> map /vFile: /tmp/header (0)Block: 1 Dba:0x00000000Undo Segment Headerstruct kcbh, 20 bytes @0 ub1 type_kcbh @0 ub1 frmt_kcbh @1 ub1 spare1_kcbh @2 ub1 spare2_kcbh @3 ub4 rdba_kcbh @4 ub4 bas_kcbh @8 ub2 wrp_kcbh @12 ub1 seq_kcbh @14 ub1 flg_kcbh @15 ub2 chkval_kcbh @16 ub2 spare3_kcbh @18 struct ktect, 44 bytes @20 ub4 ktectspare @20 sword ktecttsn @24 ub4 ktectobj @28 ub4 ktectnex @32 ub2 ktecttbe @36 ub4 ktectcex @40 ub4 ktectces @44 ub4 ktectcbk @48 struct ktectxid, 8 bytes @52 ub1 ktectlck @60 struct ktetb[1], 8 bytes @64 ub4 ktetbdba @64 ub4 ktetbnbk @68 struct ktuxc, 104 bytes @18776 struct ktuxcscn, 8 bytes @18776 struct ktuxcuba, 8 bytes @18784 sb2 ktuxcflg @18792 ub2 ktuxcseq @18794 sb2 ktuxcnfb @18796 ub4 ktuxcinc @18800 sb2 ktuxcchd @18804 sb2 ktuxcctl @18806 ub2 ktuxcmgc @18808 ub4 ktuxcopt @18816 struct ktuxcfbp[5], 60 bytes @18820 struct ktuxe[0], 0 bytes @18880 ub4 ktuxexid @18880 ub4 ktuxebrb @18884 struct ktuxescn, 8 bytes @18888 sb4 ktuxesta @18896 ub1 ktuxecfl @18897 sb2 ktuxeuel @18898 ub4 tailchk @508 BBED> d /v count 4096File: /tmp/header (0)Block: 1 Offsets: 0 to 511 Dba:0x0000000001820101 00000000 00000080 0c45d0b4 l .............Eд00000000 00000000 00000000 00000000 l ................4f52434c 4449534b 00000000 00000000 l ORCLDISK........00000000 00000000 00000000 00000000 l ................0000200b 00000103 44415441 44475f30 l .. .....DATADG_030303000 00000000 00000000 00000000 l 000.............00000000 00000000 44415441 44470000 l ........DATADG..00000000 00000000 00000000 00000000 l ................00000000 00000000 44415441 44475f30 l ........DATADG_030303000 00000000 00000000 00000000 l 000.............00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 f7ebf801 0048e61e l .........H 8e1bf901 00581860 00020010 00004000 l ...`......@.80ee0600 00050000 02000000 01000000 l ............02000000 02000000 00000000 00000000 l ................0000100a f7ebf801 0038e51e 00000000 l .....8..00000000 0a000000 01000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................00000000 00000000 00000000 00000000 l ................<16 bytes per line>
UE
我使用的是Linux 64位，所以顺序是颠倒的，那以上三种方法，到底那种看到的才是正确的字节序。
[grid@11gasm ~]$ kfed read /tmp/header
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: 2147483648 ; 0x008: disk=0
kfbh.check: 3033548044 ; 0x00c: 0xb4d0450c
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: 0 ; 0x024: 0x0000
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: DATADG_0000 ; 0x028: length=11
kfdhdb.grpname: DATADG ; 0x048: length=6
kfdhdb.fgname: DATADG_0000 ; 0x068: length=11
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 33090551 ; 0x0a8: HOUR=0x17 DAYS=0x1f MNTH=0xa YEAR=0x7e3 2019-10-31 23:
kfdhdb.crestmp.lo: 518408192 ; 0x0ac: USEC=0x0 MSEC=0x192 SECS=0x2e MINS=0x7 7:46:402:00
kfdhdb.mntstmp.hi: 33102734 ; 0x0b0: HOUR=0xe DAYS=0x1c MNTH=0x6 YEAR=0x7e4 2020-6-28 14:
kfdhdb.mntstmp.lo: 1612208128 ; 0x0b4: USEC=0x0 MSEC=0x216 SECS=0x1 MINS=0x18 24:01:534:00
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 4194304 ; 0x0bc: 0x00400000
kfdhdb.mfact: 454272 ; 0x0c0: 0x0006ee80
kfdhdb.dsksize: 1280 ; 0x0c4: 0x00000500
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]: 0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]: 0 ; 0x0dc: 0x0000
kfdhdb.redomirrors[3]: 0 ; 0x0de: 0x0000
kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi: 33090551 ; 0x0e4: HOUR=0x17 DAYS=0x1f MNTH=0xa YEAR=0x7e3
kfdhdb.grpstmp.lo: 518338560 ; 0x0e8: USEC=0x0 MSEC=0x14e SECS=0x2e MINS=0x7
。。。。。
我们知道kfed read阅读到的肯定是人类正常能阅读的字节序，通过字段kfbh.check和kfdhdb.compa三种方式比较，可以查出来
只有od -x读取的为正常的字节序，而bbed和ue看到的都为反过来的字节序。
当磁盘头有问题的时候，我们用上面两种方法观察，修改可能比较麻烦，首选kfed repair，如果备份损坏，可以直接在txt按照好的编辑好，然后kfed merge进去即可。
bbed修改比较麻烦。
磁盘头损坏检查
kfed查看
[grid@11gasm tmp]$ kfed read /dev/asm_data02 aus=4194304|more
[grid@11gasm tmp]$ kfed read /dev/asm_data01 aus=4194304|more
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
7FFFF3C3D400 00000000 00000000 00000000 00000000 […]
Repeat 255 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
kfbh.type=KFBTYP_INVALID,表示磁盘头损坏，正常的为KFBTYP_DISKHEAD
kfed find
kfed find命令检验AU[0]所有块的元数据类型是否正常
[grid@11gasm tmp]$ kfed find /dev/asm_data01 aus=4194304 aun=0|more
Block 1 has type 2 ----《《《正常的Block 0 has type 1，这里都没有显示blkn0的类型。所以磁盘头损坏
Block 2 has type 3
Block 3 has type 3
Block 4 has type 3
Block 5 has type 3
Block 6 has type 3
Block 7 has type 3
。。。。。。
Block 1021 has type 3
Block 1022 has type 3
Block 1023 has type 3
磁盘头损坏修复
破坏磁盘组中一块磁盘的盘头
[grid@11gasm tmp]$ dd if=/dev/zero of=/dev/asm_data01 count=1 bs=4096 conv=notrunc
mount磁盘组报错
SQL> alter diskgroup datadg mount;
alter diskgroup datadg mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15017: diskgroup “DATADG” cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup “DATADG”
kfed repair
此方法有局限性。版本必须为10.2.0.5、11.1.0.7、11.2之后。
12c之后，会有3个磁盘头的备份，具体参加另一篇文章。
[grid@11gasm tmp]$ kfed repair /dev/asm_data01
KFED-00320: Invalid block num1 = [3], num2 = [1], error = [type_kfbh] —不是默认AU=1M，必须加AU大小
[grid@11gasm tmp]$ kfed repair /dev/asm_data01 aus=4194304
[grid@11gasm tmp]$ kfed read /dev/asm_data01 aus=4194304|more
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: 2147483648 ; 0x008: disk=0
kfbh.check: 3628496147 ; 0x00c: 0xd8467513
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
。。。。。。。
SQL> alter diskgroup datadg mount;
Diskgroup altered.
此方法可以用strace具体跟踪来观察修复的过程。
strace -fr -o /tmp/repair kfed repair /dev/asm_data01 aus=4194304
函数lseek的用法：
lseek(int fd, off_t offset, int whence);
offset为正则向文件末尾移动（向前移），为负数则向文件头部（向后移）。
lseek()函数会重新定位被打开文件的位移量，根据参数offset以及whence的组合来决定：
SEEK_SET:
从文件头部开始偏移offset个字节。
SEEK_CUR：
从文件当前读写的指针位置开始，增加offset个字节的偏移量。
SEEK_END：
文件偏移量设置为文件的大小加上偏移量字节。
8380416/4096=2046 lseek函数是得到操作的偏移量，即后面的操作基于lseek函数的值，操作文件第2046个块。从2046个块这读4096字节，然后偏移量为0，即从0号块开始，写4096字节。
如下脚本可以判断具体磁盘头备份在哪个位置：
$ ausize=kfed read /dev/sde | grep ausize | tr -s ' ' | cut -d' ' -f2
$ blksize=kfed read /dev/sde | grep blksize | tr -s ' ' | cut -d' ' -f2
$ let n=ausize/ausize/ausize/blksize-2
$ echo $n
dd
此方法也有局限性，必须定期备份磁盘头信息。
[grid@11gasm tmp]$ dd if=/dev/asm_data01 of=/tmp/data.bak bs=4096 count=1
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000203481 s, 20.1 MB/s
破坏磁盘头并检测
[grid@11gasm tmp]$ dd if=/dev/zero of=/dev/asm_data01 count=1 bs=4096 conv=notrunc
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.000593233 s, 6.9 MB/s
[grid@11gasm tmp]$ kfed read /dev/asm_data01
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
7FFFF3C3D400 00000000 00000000 00000000 00000000 […]
Repeat 255 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
mount报错：
SQL> alter diskgroup datadg mount;
alter diskgroup datadg mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15017: diskgroup “DATADG” cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup
“DATADG”
修复：
[grid@11gasm tmp]$ dd if=/tmp/data.bak of=/dev/asm_data01 bs=4096 count=1 conv=notrunc
1+0 records in
1+0 records out
4096 bytes (4.1 kB) copied, 0.00137266 s, 3.0 MB/s
[grid@11gasm tmp]$ kfed read /dev/asm_data01 |more
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: 2147483648 ; 0x008: disk=0
kfbh.check: 1941860642 ; 0x00c: 0x73be7122
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
。。。。。
SQL> alter diskgroup datadg mount;
Diskgroup altered.
手工重构磁盘头
1）磁盘头中各字段含义
2)验证上面个字段的意义，从哪里可以获取：
1、磁盘头兼容性参数字段验证
SQL> create diskgroup testdg external redundancy disk ‘/dev/asm_arch03’ ATTRIBUTE ‘AU_SIZE’=‘4M’,‘compatible.asm’=‘11.2’,‘compatible.rdbms’=‘11.2’;
Diskgroup created.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Automatic Storage Management option
[grid@11gasm ~]$ kfed read /dev/asm_arch03 aus=4194304|grep comp
kfdhdb.compat: 186646528 ; 0x020: 0x0b200000
kfdhdb.dbcompat: 186646528 ; 0x0e0: 0x0b200000
注意：我们按照16进制来计算。b=11 2=2，所以兼容性参数均为11.2.0.0.0
[grid@11gasm ~]$ asmcmd lsattr -G testdg -l
Name Value
access_control.enabled FALSE
access_control.umask 066
au_size 4194304
cell.smart_scan_capable FALSE
compatible.asm 11.2.0.0.0
compatible.rdbms 11.2.0.0.0
disk_repair_time 3.6h
sector_size 512
2、创建时间
SQL> select CREATE_DATE,MOUNT_DATE,name from v$asm_disk;
CREATE_DATE MOUNT_DATE NAME
2020-06-28 16:36:36 2020-06-29 03:59:35
2019-10-31 23:07:46 2020-06-29 03:59:35 DATADG_0001
2019-10-31 23:07:46 2020-06-29 03:59:35 DATADG_0000
2020-06-29 04:42:14 2020-06-29 04:42:21 TESTDG_0000
创建时间也可以从asm alert日志中得出，但是要自己转化，转化的算法目前不清楚，可以在测试环境修改主机时间，然后创建磁盘组，看创建字段是多少。
3、状态
SQL> select HEADER_STATUS,name from v$asm_disk;
HEADER_STATU NAME
CANDIDATE
FORMER
MEMBER DATADG_0001
MEMBER DATADG_0000
MEMBER TESTDG_0000
4、VF的位置，3个磁盘都有：
[root@11grac1 bin]# ./crsctl query css votedisk
STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------1. ONLINE 109bc17b017c4fddbf60976672b81a14 (/dev/asm_ocr1) [OCRDG]2. ONLINE 289996ace5524fc6bfbc0492c715eab9 (/dev/asm_ocr2) [OCRDG]3. ONLINE 05243aa3336d4fc1bf25f6e61fce62b7 (/dev/asm_ocr3) [OCRDG]
Located 3 voting disk(s).
[grid@11grac1 ~]$ kfed read /dev/asm_ocr1 aus=4194304|grep vf
kfdhdb.vfstart: 72 ; 0x0ec: 0x00000048
kfdhdb.vfend: 80 ; 0x0f0: 0x00000050
5、磁盘和磁盘组的名称，可以通过asm alert日志看出kfdhdb.dskname，kfdhdb.grpname，kfdhdb.fgname：
[grid@11gasm trace]$ cat alert_+ASM.log |grep -i -A 20 “create diskgroup datadg”
SQL> CREATE DISKGROUP datadg EXTERNAL REDUNDANCY DISK ‘/dev/asm_data01’,
‘/dev/asm_data02’ ATTRIBUTE ‘compatible.asm’=‘11.2.0.0.0’,‘au_size’=‘4M’ /* ASMCA */
NOTE: Assigning number (1,0) to disk (/dev/asm_data01)
NOTE: Assigning number (1,1) to disk (/dev/asm_data02)
NOTE: initializing header on grp 1 disk DATADG_0000
NOTE: initializing header on grp 1 disk DATADG_0001
NOTE: initiating PST update: grp = 1
GMON updating group 1 at 1 for pid 17, osid 33776
NOTE: group DATADG: initial PST location: disk 0000 (PST copy 0)
NOTE: PST update grp = 1 completed successfully
NOTE: cache registered group DATADG number=1 incarn=0x1f9a1145
NOTE: cache began mount (first) of group DATADG number=1 incarn=0x1f9a1145
NOTE: cache opening disk 0 of grp 1: DATADG_0000 path:/dev/asm_data01 ----<<</dev/asm_data01内部命名为DATADG_0000
NOTE: cache opening disk 1 of grp 1: DATADG_0001 path:/dev/asm_data02 ----<<</dev/asm_data02内部命名为DATADG_0001
。。。。。。。。。。。。
7、1、FST/AT位置
[grid@11gasm ~]$ kfed read /dev/asm_data02 aun=0 blkn=0 aus=4194304|grep fst
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000
[grid@11gasm ~]$ kfed read /dev/asm_data02 aun=0 blkn=0 aus=4194304|grep alt
kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002
8、asm spfile的位置
[grid@11gasm ~]$ kfed read /dev/asm_data01 aun=0 blkn=0 aus=4194304|grep spf
kfdhdb.spfile: 10 ; 0x0f4: 0x0000000a
kfdhdb.spfflg: 1 ; 0x0f8: 0x00000001
9、1号元数据文件 file directory的位置
[grid@11gasm ~]$ kfed read /dev/asm_data01 aun=0 blkn=0 aus=4194304|grep f1
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
10、磁盘组大小kfdhdb.dsksize：
SQL> select 5*1024 from dual;5*1024
----------5120SQL> select 5120/4 from dual;5120/4
----------1280
5G的一个asm磁盘。
11、kfbh.block.obj
[grid@11gasm ~]$ kfed read /dev/asm_arch01 aus=4194304|egrep “obj|num”
kfbh.block.obj: 2147483648 ; 0x008: disk=0
kfdhdb.dsknum: 0 ; 0x024: 0x0000
[grid@11gasm ~]$ kfed read /dev/asm_arch02 aus=4194304|egrep “obj|num”
kfbh.block.obj: 2147483649 ; 0x008: disk=1
kfdhdb.dsknum: 1 ; 0x024: 0x0001
[grid@11gasm ~]$ kfed read /dev/asm_arch03 aus=4194304|egrep “obj|num”
kfbh.block.obj: 2147483650 ; 0x008: disk=2
kfdhdb.dsknum: 2 ; 0x024: 0x0002
block object id disk header的type为8，num表示asm disk在diskgroup中的编号，即kfdhdb.dsknum，TYPE=0X80 NUMB=0X0 表示为80000000，十进制就为2147483648。
TYPE=0X80 NUMB=0X1表示为80000001，十进制就为2147483649。
TYPE=0X80 NUMB=0X2 表示为80000002，十进制就为2147483650。
也可以看出来，10进制是从2147483648开始，每增加一块盘，数字就会加1。以此为修改标准
3）手工重建
尽量拷贝同一个磁盘组中的磁盘。本次我们拷贝datadg中的02到01来进行修复。
先生成一个好的磁盘头：
[grid@11gasm ~]$ kfed read /dev/asm_data02 aus=4194304 text=/tmp/good.txt
1、修改必要的值
2、merge修改
[grid@11gasm ~]$ kfed merge /dev/asm_data01 aus=4194304 text=/tmp/good.txt
3、mount磁盘组
SQL> conn / as sysasm
Connected.
SQL> alter diskgroup datadg mount;
Diskgroup altered.
SQL> shutdown abort;
ASM instance shutdown
SQL> startup
ORA-00099: warning: no parameter file specified for ASM instance
ASM instance started
Total System Global Area 1135747072 bytes
Fixed Size 2260728 bytes
Variable Size 1108320520 bytes
ASM Cache 25165824 bytes
ORA-15110: no diskgroups mounted
SQL> select name,state from v$asm_diskgroup;
NAME STATE
DATADG DISMOUNTED
TESTDG DISMOUNTED
SQL> alter diskgroup testdg mount;
Diskgroup altered.
SQL> alter diskgroup datadg mount;
Diskgroup altered.
缺少asm spfile
4、处理spfile
[grid@11gasm tmp]$ for disk in `asmcmd lsdsk -G datadg --suppressheader`
> do
> echo $disk
> kfed read $disk aus=4194304 | grep spf
> done
/dev/asm_data01
kfdhdb.spfile: 0 ; 0x0f4: 0x00000000
kfdhdb.spfflg: 0 ; 0x0f8: 0x00000000
/dev/asm_data02
kfdhdb.spfile: 0 ; 0x0f4: 0x00000000
kfdhdb.spfflg: 0 ; 0x0f8: 0x00000000
磁盘组中没有一块盘上面记录spfile的信息，所以asm实例启动的时候会报没有spfile参数文件。
手工编辑asm spfile（以下为asm standalone，rac的话，参考正常环境修改）：
[grid@11gasm ~]$ cat /tmp/asm.ora
+ASM.asm_diskgroups='DATADG','TESTDG'#Manual Dismount
*.asm_diskstring='/dev/asm*'
*.asm_power_limit=1
*.diagnostic_dest='/u01/app/grid'
*.instance_type='asm'
*.large_pool_size=12M
*.remote_login_passwordfile='EXCLUSIVE'SQL> shutdown immediate;
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup pfile='/tmp/asm.ora';
ASM instance startedTotal System Global Area 1135747072 bytes
Fixed Size 2260728 bytes
Variable Size 1108320520 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted
SQL> create spfile from pfile='/tmp/asm.ora';
create spfile from pfile='/tmp/asm.ora'
*
ERROR at line 1:
ORA-17502: ksfdcre:4 Failed to create file
+DATADG/asm/asmparameterfile/registry.253.1023145675
ORA-15177: cannot operate on system aliasesSQL> create spfile='+DATADG' from pfile='/tmp/asm.ora';File created.SQL> shutdown immediate;
ASM diskgroups dismounted
ASM instance shutdown
SQL> startup
ASM instance startedTotal System Global Area 1135747072 bytes
Fixed Size 2260728 bytes
Variable Size 1108320520 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted
SQL> show parameter spfile;NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string +DATADG/asm/asmparameterfile/registry.253.1044330885
asm会自动使用新创建的asm spfile，原来老的spfile被覆盖。
[grid@11gasm tmp]$ 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 4194304 10240 3120 0 3120 0 N DATADG/
MOUNTED EXTERN N 512 4096 4194304 3072 2992 0 2992 0 N TESTDG/
ASMCMD> cd datadg
ASMCMD> ls
ASM/
ORCL/
ASMCMD> cd asm
ASMCMD> ls
ASMPARAMETERFILE/
ASMCMD> cd asm*
ASMCMD> ls
REGISTRY.253.1023145675
补充—2号元数据文件disk directory
定位2号文件位置：
[grid@11gasm ~]$ kfed read /dev/asm_data01 aus=4194304 aun=2 blkn=2|more
。。。。。。
kfffde[0].xptr.au: 2 ; 0x4a0: 0x00000002
kfffde[0].xptr.disk: 1 ; 0x4a4: 0x0001
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 41 ; 0x4a7: 0x29
kfffde[1].xptr.au: 4294967295 ; 0x4a8: 0xffffffff
kfffde[1].xptr.disk: 65535 ; 0x4ac: 0xffff
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 42 ; 0x4af: 0x2a
。。。。。。
查看2号文件内容：
[grid@11gasm ~]$ kfed read /dev/asm_data02 aus=4194304 aun=2 blkn=0|more
[grid@11gasm ~]$ kfed read /dev/asm_data02 aus=4194304 aun=2 blkn=0|more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 6 ; 0x002: KFBTYP_DISKDIR --type类型为磁盘目录
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: blk=0 ---块号为0，因为查看的就是1号块
kfbh.block.obj: 2 ; 0x008: file=2
kfbh.check: 17203383 ; 0x00c: 0x010680b7
kfbh.fcn.base: 689 ; 0x010: 0x000002b1
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0
kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff
kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff
kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0
kffdnd.parent.number: 0 ; 0x014: 0x00000000
kffdnd.parent.incarn: 1 ; 0x018: A=1 NUMM=0x0
kffdnd.fstblk.number: 0 ; 0x01c: 0x00000000
kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0
kfddde[0].entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 ---结构体kfddde，asm磁盘信息就存储在这个结构体里面
kfddde[0].entry.hash: 0 ; 0x028: 0x00000000
kfddde[0].entry.refer.number:4294967295 ; 0x02c: 0xffffffff
kfddde[0].entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0
kfddde[0].dsknum: 0 ; 0x034: 0x0000 ----diskgroup中，该disk的disk编号，从0开始排序，该值为0，说明该disk是这个磁盘组中的第一个disk
kfddde[0].state: 2 ; 0x036: KFDSTA_NORMAL ---disk状态。其中2表示normal。在asm中，该值对应v$asm_disk.state，
kfddde[0].ddchgfl: 132 ; 0x037: 0x84
kfddde[0].dskname: DATADG_0000 ; 0x038: length=11 ---磁盘名称，这是asm中定义的diskname.
kfddde[0].fgname: DATADG_0000 ; 0x058: length=11 ---这表示failgroup diskname，由于我这里是external冗余，所以failgroup就是本身。
kfddde[0].crestmp.hi: 33090551 ; 0x078: HOUR=0x17 DAYS=0x1f MNTH=0xa YEAR=0x7e3 ---这里表示该disk的创建时间戳
kfddde[0].crestmp.lo: 518408192 ; 0x07c: USEC=0x0 MSEC=0x192 SECS=0x2e MINS=0x7
kfddde[0].failstmp.hi: 0 ; 0x080: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 ---这里表示该disk的失败时间戳
kfddde[0].failstmp.lo: 0 ; 0x084: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfddde[0].timer: 0 ; 0x088: 0x00000000
kfddde[0].size: 1280 ; 0x08c: 0x00000500 --disk大小,由于au是4m,所以这里是1280个AU
kfddde[0].srRloc.super.hiStart: 0 ; 0x090: 0x00000000
kfddde[0].srRloc.super.loStart: 0 ; 0x094: 0x00000000
kfddde[0].srRloc.super.length: 0 ; 0x098: 0x00000000
kfddde[0].srRloc.incarn: 0 ; 0x09c: 0x00000000
kfddde[0].dskrprtm: 0 ; 0x0a0: 0x00000000
kfddde[0].start0: 0 ; 0x0a4: 0x00000000
kfddde[0].size0: 1280 ; 0x0a8: 0x00000500
kfddde[0].used0: 10 ; 0x0ac: 0x0000000a
kfddde[0].slot: 0 ; 0x0b0: 0x00000000
kfddde[0].imbal00[0]: 8 ; 0x0b4: 0x00000008
kfddde[0].imbal00[1]: 0 ; 0x0b8: 0x00000000
kfddde[0].imbal00[2]: 0 ; 0x0bc: 0x00000000
kfddde[0].imbal00[3]: 0 ; 0x0c0: 0x00000000
kfddde[0].imbal01[0]: 0 ; 0x0c4: 0x00000000
kfddde[0].imbal01[1]: 0 ; 0x0c8: 0x00000000
kfddde[0].imbal01[2]: 0 ; 0x0cc: 0x00000000
kfddde[0].imbal01[3]: 0 ; 0x0d0: 0x00000000
kfddde[0].imbal02[0]: 0 ; 0x0d4: 0x00000000
kfddde[0].imbal02[1]: 0 ; 0x0d8: 0x00000000
kfddde[0].imbal02[2]: 0 ; 0x0dc: 0x00000000
kfddde[0].imbal02[3]: 0 ; 0x0e0: 0x00000000
kfddde[0].imbal03[0]: 0 ; 0x0e4: 0x00000000
kfddde[0].imbal03[1]: 0 ; 0x0e8: 0x00000000
kfddde[0].imbal03[2]: 0 ; 0x0ec: 0x00000000
kfddde[0].imbal03[3]: 0 ; 0x0f0: 0x00000000
kfddde[0].start1: 0 ; 0x0f4: 0x00000000
kfddde[0].size1: 0 ; 0x0f8: 0x00000000
kfddde[0].used1: 0 ; 0x0fc: 0x00000000
kfddde[0].spare1: 0 ; 0x100: 0x00000000
kfddde[0].imbal10[0]: 0 ; 0x104: 0x00000000
kfddde[0].imbal10[1]: 0 ; 0x108: 0x00000000
kfddde[0].imbal10[2]: 0 ; 0x10c: 0x00000000
kfddde[0].imbal10[3]: 0 ; 0x110: 0x00000000
kfddde[0].imbal11[0]: 0 ; 0x114: 0x00000000
kfddde[0].imbal11[1]: 0 ; 0x118: 0x00000000
kfddde[0].imbal11[2]: 0 ; 0x11c: 0x00000000
kfddde[0].imbal11[3]: 0 ; 0x120: 0x00000000
kfddde[0].imbal12[0]: 0 ; 0x124: 0x00000000
kfddde[0].imbal12[1]: 0 ; 0x128: 0x00000000
kfddde[0].imbal12[2]: 0 ; 0x12c: 0x00000000
kfddde[0].imbal12[3]: 0 ; 0x130: 0x00000000
kfddde[0].imbal13[0]: 0 ; 0x134: 0x00000000
kfddde[0].imbal13[1]: 0 ; 0x138: 0x00000000
kfddde[0].imbal13[2]: 0 ; 0x13c: 0x00000000
kfddde[0].imbal13[3]: 0 ; 0x140: 0x00000000
kfddde[0].start2: 0 ; 0x144: 0x00000000
kfddde[0].size2: 0 ; 0x148: 0x00000000
kfddde[0].used2: 0 ; 0x14c: 0x00000000
kfddde[0].spare2: 0 ; 0x150: 0x00000000
kfddde[0].imbal20[0]: 0 ; 0x154: 0x00000000
kfddde[0].imbal20[1]: 0 ; 0x158: 0x00000000
kfddde[0].imbal20[2]: 0 ; 0x15c: 0x00000000
kfddde[0].imbal20[3]: 0 ; 0x160: 0x00000000
kfddde[0].imbal21[0]: 0 ; 0x164: 0x00000000
kfddde[0].imbal21[1]: 0 ; 0x168: 0x00000000
kfddde[0].imbal21[2]: 0 ; 0x16c: 0x00000000
kfddde[0].imbal21[3]: 0 ; 0x170: 0x00000000
kfddde[0].imbal22[0]: 0 ; 0x174: 0x00000000
kfddde[0].imbal22[1]: 0 ; 0x178: 0x00000000
kfddde[0].imbal22[2]: 0 ; 0x17c: 0x00000000
kfddde[0].imbal22[3]: 0 ; 0x180: 0x00000000
kfddde[0].imbal23[0]: 0 ; 0x184: 0x00000000
kfddde[0].imbal23[1]: 0 ; 0x188: 0x00000000
kfddde[0].imbal23[2]: 0 ; 0x18c: 0x00000000
kfddde[0].imbal23[3]: 0 ; 0x190: 0x00000000
kfddde[0].start3: 0 ; 0x194: 0x00000000
kfddde[0].size3: 0 ; 0x198: 0x00000000
kfddde[0].used3: 0 ; 0x19c: 0x00000000
kfddde[0].spare3: 0 ; 0x1a0: 0x00000000
kfddde[0].imbal30[0]: 0 ; 0x1a4: 0x00000000
kfddde[0].imbal30[1]: 0 ; 0x1a8: 0x00000000
kfddde[0].imbal30[2]: 0 ; 0x1ac: 0x00000000
kfddde[0].imbal30[3]: 0 ; 0x1b0: 0x00000000
kfddde[0].imbal31[0]: 0 ; 0x1b4: 0x00000000
kfddde[0].imbal31[1]: 0 ; 0x1b8: 0x00000000
kfddde[0].imbal31[2]: 0 ; 0x1bc: 0x00000000
kfddde[0].imbal31[3]: 0 ; 0x1c0: 0x00000000
kfddde[0].imbal32[0]: 0 ; 0x1c4: 0x00000000
kfddde[0].imbal32[1]: 0 ; 0x1c8: 0x00000000
kfddde[0].imbal32[2]: 0 ; 0x1cc: 0x00000000
kfddde[0].imbal32[3]: 0 ; 0x1d0: 0x00000000
kfddde[0].imbal33[0]: 0 ; 0x1d4: 0x00000000
kfddde[0].imbal33[1]: 0 ; 0x1d8: 0x00000000
kfddde[0].imbal33[2]: 0 ; 0x1dc: 0x00000000
kfddde[0].imbal33[3]: 0 ; 0x1e0: 0x00000000
kfddde[1].entry.incarn: 1 ; 0x1e4: A=1 NUMM=0x0
kfddde[1].entry.hash: 1 ; 0x1e8: 0x00000001
kfddde[1].entry.refer.number:4294967295 ; 0x1ec: 0xffffffff
kfddde[1].entry.refer.incarn: 0 ; 0x1f0: A=0 NUMM=0x0
kfddde[1].dsknum: 1 ; 0x1f4: 0x0001
kfddde[1].state: 2 ; 0x1f6: KFDSTA_NORMAL
kfddde[1].ddchgfl: 132 ; 0x1f7: 0x84
kfddde[1].dskname: DATADG_0001 ; 0x1f8: length=11
kfddde[1].fgname: DATADG_0001 ; 0x218: length=11
kfddde[1].crestmp.hi: 33090551 ; 0x238: HOUR=0x17 DAYS=0x1f MNTH=0xa YEAR=0x7e3
kfddde[1].crestmp.lo: 518408192 ; 0x23c: USEC=0x0 MSEC=0x192 SECS=0x2e MINS=0x7
kfddde[1].failstmp.hi: 0 ; 0x240: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0
kfddde[1].failstmp.lo: 0 ; 0x244: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfddde[1].timer: 0 ; 0x248: 0x00000000
kfddde[1].size: 1280 ; 0x24c: 0x00000500
kfddde[1].srRloc.super.hiStart: 0 ; 0x250: 0x00000000
kfddde[1].srRloc.super.loStart: 0 ; 0x254: 0x00000000
kfddde[1].srRloc.super.length: 0 ; 0x258: 0x00000000
kfddde[1].srRloc.incarn: 0 ; 0x25c: 0x00000000
kfddde[1].dskrprtm: 0 ; 0x260: 0x00000000
kfddde[1].start0: 0 ; 0x264: 0x00000000
kfddde[1].size0: 1280 ; 0x268: 0x00000500
kfddde[1].used0: 13 ; 0x26c: 0x0000000d
kfddde[1].slot: 0 ; 0x270: 0x00000000
kfddde[1].imbal00[0]: 11 ; 0x274: 0x0000000b
kfddde[1].imbal00[1]: 0 ; 0x278: 0x00000000
kfddde[1].imbal00[2]: 0 ; 0x27c: 0x00000000
kfddde[1].imbal00[3]: 0 ; 0x280: 0x00000000
kfddde[1].imbal01[0]: 0 ; 0x284: 0x00000000
kfddde[1].imbal01[1]: 0 ; 0x288: 0x00000000
kfddde[1].imbal01[2]: 0 ; 0x28c: 0x00000000
kfddde[1].imbal01[3]: 0 ; 0x290: 0x00000000
kfddde[1].imbal02[0]: 0 ; 0x294: 0x00000000
kfddde[1].imbal02[1]: 0 ; 0x298: 0x00000000
kfddde[1].imbal02[2]: 0 ; 0x29c: 0x00000000
kfddde[1].imbal02[3]: 0 ; 0x2a0: 0x00000000
kfddde[1].imbal03[0]: 0 ; 0x2a4: 0x00000000
kfddde[1].imbal03[1]: 0 ; 0x2a8: 0x00000000
kfddde[1].imbal03[2]: 0 ; 0x2ac: 0x00000000
kfddde[1].imbal03[3]: 0 ; 0x2b0: 0x00000000
kfddde[1].start1: 0 ; 0x2b4: 0x00000000
kfddde[1].size1: 0 ; 0x2b8: 0x00000000
kfddde[1].used1: 0 ; 0x2bc: 0x00000000
kfddde[1].spare1: 0 ; 0x2c0: 0x00000000
kfddde[1].imbal10[0]: 0 ; 0x2c4: 0x00000000
kfddde[1].imbal10[1]: 0 ; 0x2c8: 0x00000000
kfddde[1].imbal10[2]: 0 ; 0x2cc: 0x00000000
kfddde[1].imbal10[3]: 0 ; 0x2d0: 0x00000000
kfddde[1].imbal11[0]: 0 ; 0x2d4: 0x00000000
kfddde[1].imbal11[1]: 0 ; 0x2d8: 0x00000000
kfddde[1].imbal11[2]: 0 ; 0x2dc: 0x00000000
kfddde[1].imbal11[3]: 0 ; 0x2e0: 0x00000000
kfddde[1].imbal12[0]: 0 ; 0x2e4: 0x00000000
kfddde[1].imbal12[1]: 0 ; 0x2e8: 0x00000000
kfddde[1].imbal12[2]: 0 ; 0x2ec: 0x00000000
kfddde[1].imbal12[3]: 0 ; 0x2f0: 0x00000000
kfddde[1].imbal13[0]: 0 ; 0x2f4: 0x00000000
kfddde[1].imbal13[1]: 0 ; 0x2f8: 0x00000000
kfddde[1].imbal13[2]: 0 ; 0x2fc: 0x00000000
kfddde[1].imbal13[3]: 0 ; 0x300: 0x00000000
kfddde[1].start2: 0 ; 0x304: 0x00000000
kfddde[1].size2: 0 ; 0x308: 0x00000000
kfddde[1].used2: 0 ; 0x30c: 0x00000000
kfddde[1].spare2: 0 ; 0x310: 0x00000000
kfddde[1].imbal20[0]: 0 ; 0x314: 0x00000000
kfddde[1].imbal20[1]: 0 ; 0x318: 0x00000000
kfddde[1].imbal20[2]: 0 ; 0x31c: 0x00000000
kfddde[1].imbal20[3]: 0 ; 0x320: 0x00000000
kfddde[1].imbal21[0]: 0 ; 0x324: 0x00000000
kfddde[1].imbal21[1]: 0 ; 0x328: 0x00000000
kfddde[1].imbal21[2]: 0 ; 0x32c: 0x00000000
kfddde[1].imbal21[3]: 0 ; 0x330: 0x00000000
kfddde[1].imbal22[0]: 0 ; 0x334: 0x00000000
kfddde[1].imbal22[1]: 0 ; 0x338: 0x00000000
kfddde[1].imbal22[2]: 0 ; 0x33c: 0x00000000
kfddde[1].imbal22[3]: 0 ; 0x340: 0x00000000
kfddde[1].imbal23[0]: 0 ; 0x344: 0x00000000
kfddde[1].imbal23[1]: 0 ; 0x348: 0x00000000
kfddde[1].imbal23[2]: 0 ; 0x34c: 0x00000000
kfddde[1].imbal23[3]: 0 ; 0x350: 0x00000000
kfddde[1].start3: 0 ; 0x354: 0x00000000
kfddde[1].size3: 0 ; 0x358: 0x00000000
kfddde[1].used3: 0 ; 0x35c: 0x00000000
kfddde[1].spare3: 0 ; 0x360: 0x00000000
kfddde[1].imbal30[0]: 0 ; 0x364: 0x00000000
kfddde[1].imbal30[1]: 0 ; 0x368: 0x00000000
kfddde[1].imbal30[2]: 0 ; 0x36c: 0x00000000
kfddde[1].imbal30[3]: 0 ; 0x370: 0x00000000
kfddde[1].imbal31[0]: 0 ; 0x374: 0x00000000
kfddde[1].imbal31[1]: 0 ; 0x378: 0x00000000
kfddde[1].imbal31[2]: 0 ; 0x37c: 0x00000000
kfddde[1].imbal31[3]: 0 ; 0x380: 0x00000000
kfddde[1].imbal32[0]: 0 ; 0x384: 0x00000000
kfddde[1].imbal32[1]: 0 ; 0x388: 0x00000000
kfddde[1].imbal32[2]: 0 ; 0x38c: 0x00000000
kfddde[1].imbal32[3]: 0 ; 0x390: 0x00000000
kfddde[1].imbal33[0]: 0 ; 0x394: 0x00000000
kfddde[1].imbal33[1]: 0 ; 0x398: 0x00000000
kfddde[1].imbal33[2]: 0 ; 0x39c: 0x00000000
kfddde[1].imbal33[3]: 0 ; 0x3a0: 0x00000000
由以上可知，kfddde结构体，每块磁盘对应一个，里面存储的都是具体的磁盘信息。包括磁盘号，磁盘名，磁盘创建时间，挂载时间，磁盘大小，failgroup信息等。
结论
1、如果asm磁盘头损坏，首选用kfed repair自动修复，但是对数据库版本又要求，版本必须为10.2.0.5、11.1.0.7、11.2之后。注意只能修复4K大小的磁盘头，如果元数据损坏严重，repair也无能为力。
命令为：kfed repair /dev/asm_data01 aus=4194304。
自动读取磁盘头备份位置，进行修复。
2、磁盘头自动备份位置：
AU size是1MB的DISKGROUP，每个AU包括block数量=1024KB/4KB=256个，因此备份信息位于AU#1的第254号block
AU size是2MB的DISKGROUP，每个AU包括block数量=2048KB/4KB=512个，因此备份信息位于AU#1的第510号block
AU size是4MB的DISKGROUP，每个AU包括block数量=4096KB/4KB=1024个，因此备份信息位于AU#1的第1022号block
AU size是8MB的DISKGROUP，每个AU包括block数量=8192KB/4KB=2048个，因此备份信息位于AU#1的第2046号block
AU size是16MB的DISKGROUP，每个AU包括block数量=16384KB/4KB=4096个，因此备份信息位于AU#1的第4094号block
如果不加au=1的参数的话，则是以下block
AU size是1MB的DISKGROUP，每个AU包括block数量=1024KB/4KB=256个，因此备份信息位于的第510号block
AU size是2MB的DISKGROUP，每个AU包括block数量=2048KB/4KB=512个，因此备份信息位于的第1022号block
AU size是4MB的DISKGROUP，每个AU包括block数量=4096KB/4KB=1024个，因此备份信息位于的第2046号block
AU size是8MB的DISKGROUP，每个AU包括block数量=8192KB/4KB=2048个，因此备份信息位于的第4094号block
AU size是16MB的DISKGROUP，每个AU包括block数量=16384KB/4KB=4096个，因此备份信息位于的8190号block
相当于kfed read /dev/asm_data01 aun=1 blkn=1022 aus=4194304
kfed read /dev/asm_data01 blkn=2046 aus=4194304读取的是同一个块
[grid@11gasm ~]$ kfed read /dev/asm_data01 aun=1 blkn=1022 aus=4194304|grep type
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
[grid@11gasm ~]$ kfed read /dev/asm_data01 blkn=2046 aus=4194304|grep type
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
3、如果创建磁盘组成功的时候，使用dd命令备份了磁盘头，后面如果损坏，也可以使用dd进行恢复
4、如果上面两种方案都不行，可以使用手工纯构。
5、可以使用kfed read 和kfed find查看是否磁盘头损坏。
6、2号元数据文件disk directory里面记录了：磁盘号 • 磁盘的状态 • 磁盘的名称 • 所在的Failgroup名称 • 创建的时间戳 • 失败的时间戳 • 自失败时间戳截止目前的时间。都是关于磁盘的信息，和header关系密切，重构的时候可以参考disk directory。
ASM磁盘头损坏修复相关推荐
- asm磁盘头自动备份19c-au11
从asm磁盘头自动备份看11g到12c的新特性--Physical_metadata_replication 概述 读取AU11 理论支撑 12c 新特性 复制的位置--AU11 磁盘组属性phys_ ...
- 从asm磁盘头自动备份看11g到12c的新特性--Physical_metadata_replication
从asm磁盘头自动备份看11g到12c的新特性--Physical_metadata_replication 概述 读取AU11 理论支撑 12c 新特性 复制的位置--AU11 磁盘组属性phys_ ...
- 某项目Oracle RAC基础库发生ASM磁盘文件头损坏宕机事件分析排查
问题描述: 2021年2月26日收到某现场项目经理电话反馈现场Oracle RAC数据库发生宕机事件,但数据库已恢复正常,需要我方进行故障分析排查原因. 日志分析: 到了现场后通过现场人员对接登录到此 ...
- oracle备份磁盘头,ASM 磁盘头信息备份
ASM磁盘头信息保存在每个磁盘的前4K里面,这个信息的备份对于ASM的恢复非常重要,有下面的几种方法 1.直接做dd来备份磁盘的前4K,磁盘头信息丢失时,dd回来 备份:dd if=/dev/raw/ ...
- oracle asm磁盘头 备份,ASM磁盘头的第三个备份-Physically Addressed Metadata Redundancy
这几天很蕉绿,想着复习下技术.个人很喜欢ASM,就从ASM开始复习.循环kfed发现一个很奇怪的事情,就是,我扫到AU 11的时候发现,居然这个aun的blkn0是KFBTYP_DISKHEAD.要知 ...
- 硬盘显示磁盘结构损坏修复方案
当进入"我的电脑"后会发现出现问题的硬盘中的分区会无法显示相关信息:如容量大小.可用空间等.跪求硬盘显示磁盘结构损坏"的错误信息,不能打开盘符. 工具/软件:光明数据恢复 ...
- linux 磁盘头损坏 pv不见了,文件系统损坏的修复过程
最近碰到两次在作扩卷等操做时整个卷数据损坏丢失的状况,有必要记录下问题的处理过程. 若是你是晚班,遇到这种状况,忽然一个卷不见了,你先作好下面两件事. 1 记录好你以前全部的操做命令,用以判断咱们究竟 ...
- 【LINUX】Oracle数据库 linux磁盘头数据损坏修复
本次模拟 通过fdisk分区的磁盘头损坏,造成文件目录无法使用. 如果是asm磁盘,可通过asm相关命令进行修复 现有环境 [root@pgtest testdata]# df -h Filesyst ...
- RAC 11G ASM磁盘损坏恢复
一个存储档案的rac数据库起不来了,生产环境是linux rac 11.2.0.4,原因是因为用工具测试磁盘IO时损坏了ocr所在磁盘组与存储数据ASM磁盘的磁盘头.下面是恢复过程: 1.检查crs的 ...
最新文章
- 猎豹MFC--列表控件ListControl
- 一文讲透推荐系统提供web服务的2种方式
- 计算机科学概论各章总结,计算机科学概论（原书第5版）读书笔记
- 【简明书】机器学习用例书册
- C#中的get和post请求（工具类）
- 物理光学 计算倏逝波/渐逝波在界面上存在的范围
- BPMF论文辅助笔记：采样Ui 部分推导
- [watevrCTF 2019]Baby RLWE
- Android判断网络连接是否可用【从新浪云搬运】
- Vue 第一天学习 ---2018.06.28
- P3959-宝藏【模拟退火】
- 怎样解决Word文档图标无法正常显示的问题?
- java判断两线段是否相交
- VS项目属性的一些配置项的总结（important）
- springboot读取application.properties中自定义配置
- python字体和图片合成
- 服务器自定义怪,GOM引擎自定义怪物appr代码计算方法和公式
- C#NPOI获取Excel的列名
- 模拟网络延迟抖动测试
- Dark Crystal RAT的新变种分析