联系：手机/微信(+86 17813235971) QQ(107644445)
标题：使用asm disk header 自动备份信息恢复异常asm disk header
作者：惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
通过参考kamus的Where is the backup of ASM disk header block,发现从10.2.0.5开始的asm确实存在自动备份asm disk header功能.有了这个功能对于那些不备份asm disk header的同学,提供了一层保证,也增加了asm的安全性.
对于10.2.0.5.0以及以后版本，不管au size是多少,asm disk header自动备份存储的位置是第2个au的倒数第2个block.
计算方法:AU中包含的block num[AU_SIZE/block_size]*2-2[因为从第一个块从0计数],通过该方法计算结论为:
1M AU在510
2M AU在1022
4M AU在2046
8M AU在4094
16M AU在8190
32M AU在16382
64M AU在32766
1.对比备份asm disk header
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - Prod
PL/SQL Release 10.2.0.5.0 - Production
CORE 10.2.0.5.0 Production
TNS for Linux: Version 10.2.0.5.0 - Production
NLSRTL Version 10.2.0.5.0 - Production
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') "xifenfei.com" from dual;
xifenfei.com
-------------------
2012-06-17 09:41:19
SQL> select group_number,DISK_NUMBER,PATH,HEADER_STATUS
2 from v$asm_disk where group_number<>0;
GROUP_NUMBER DISK_NUMBER PATH HEADER_STATU
------------ ----------- --------------- ------------
1 1 /dev/raw/raw2 MEMBER
1 0 /dev/raw/raw1 MEMBER
SQL> select group_number,name,BLOCK_SIZE,ALLOCATION_UNIT_SIZE from v$asm_diskgroup;
GROUP_NUMBER NAME BLOCK_SIZE ALLOCATION_UNIT_SIZE
------------ ------------------------------ ---------- --------------------
1 DATA 4096 1048576
rac1-> kfed read /dev/raw/raw1 blknum=510|>/tmp/xifenfei.510
rac1-> kfed read /dev/raw/raw1 blknum=0|>/tmp/xifenfei.0
rac1-> ll /tmp/xifenfei*
-rw-r--r-- 1 oracle oinstall 6606 Jun 14 04:11 /tmp/xifenfei.0
-rw-r--r-- 1 oracle oinstall 6606 Jun 14 04:12 /tmp/xifenfei.510
rac1-> diff /tmp/xifenfei.510 /tmp/xifenfei.0
--通过对比发现两者无不同记录返回,证明他们记录内容完全相同
2.尝试破坏asm disk header
rac1-> dd if=/dev/zero of=/dev/raw/raw1 bs=4096 count=1
1+0 records in
1+0 records out
rac1-> kfed read /dev/raw/raw1 blknum=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: T=0 NUMB=0x0
kfbh.block.obj: 0 ; 0x008: TYPE=0x0 NUMB=0x0
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
SQL> select group_number,DISK_NUMBER,PATH,HEADER_STATUS
2 from v$asm_disk where group_number<>0;
GROUP_NUMBER DISK_NUMBER PATH HEADER_STATU
------------ ----------- --------------- ------------
1 1 /dev/raw/raw2 MEMBER
1 0 /dev/raw/raw1 CANDIDATE
SQL> alter diskgroup data dismount;
Diskgroup altered.
SQL> alter diskgroup data mount;
alter diskgroup data mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA"
3.使用kfed repair修改损坏asm disk header
rac1-> kfed repair '/dev/raw/raw1' rac1-> kfed read /dev/raw/raw1 blknum=0 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: 883602253 ; 0x00c: 0x34aab34d kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 ………… SQL> alter diskgroup data mount; Diskgroup altered.
4.使用kfed merge恢复asm disk header
rac1-> dd if=/dev/zero of=/dev/raw/raw1 bs=4096 count=1 1+0 records in 1+0 records out rac1-> kfed read /dev/raw/raw1 blknum=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: T=0 NUMB=0x0 kfbh.block.obj: 0 ; 0x008: TYPE=0x0 NUMB=0x0 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 SQL> alter diskgroup data dismount; Diskgroup altered. SQL> alter diskgroup data mount; alter diskgroup data mount * ERROR at line 1: ORA-15032: not all alterations performed ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA" rac1-> kfed merge /dev/raw/raw1 /tmp/xifenfei.510 SQL> alter diskgroup data mount; Diskgroup altered.
通过试验证明在10.2.0.5及其以后版本中,对于备份的asm disk header我们可以通过使用kfed repair和kfed merge来恢复.
编译kfed程序
10.2.0.1 asm 中无此项备份
SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod PL/SQL Release 10.2.0.1.0 - Production CORE 10.2.0.1.0 Production TNS for Linux: Version 10.2.0.1.0 - Production NLSRTL Version 10.2.0.1.0 - Production SQL> select group_number,DISK_NUMBER,PATH 2 from v$asm_disk where group_number<>0; GROUP_NUMBER DISK_NUMBER PATH ------------ ----------- -------------------- 1 0 /dev/raw/raw2 1 1 /dev/raw/raw3 [oracle@xifenfei raw]$ kfed read /dev/raw/raw3 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: 2147483649 ; 0x008: TYPE=0x8 NUMB=0x1 kfbh.check: 1890176443 ; 0x00c: 0x70a9cdbb 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: 1 ; 0x024: 0x0001 kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: XIFENFEI_0001 ; 0x028: length=13 kfdhdb.grpname: XIFENFEI ; 0x048: length=8 kfdhdb.fgname: XIFENFEI_0001 ; 0x068: length=13 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 32971445 ; 0x0a8: HOUR=0x15 DAYS=0x15 MNTH=0x6 YEAR=0x7dc kfdhdb.crestmp.lo: 3885156352 ; 0x0ac: USEC=0x0 MSEC=0xb2 SECS=0x39 MINS=0x39 kfdhdb.mntstmp.hi: 32971445 ; 0x0b0: HOUR=0x15 DAYS=0x15 MNTH=0x6 YEAR=0x7dc kfdhdb.mntstmp.lo: 3896621056 ; 0x0b4: USEC=0x0 MSEC=0x6e SECS=0x4 MINS=0x3a kfdhdb.secsize: 512 ; 0x0b8: 0x0200 kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000 kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80 kfdhdb.dsksize: 7059 ; 0x0c4: 0x00001b93 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 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: 32971445 ; 0x0e4: HOUR=0x15 DAYS=0x15 MNTH=0x6 YEAR=0x7dc kfdhdb.grpstmp.lo: 3884946432 ; 0x0e8: USEC=0x0 MSEC=0x3e5 SECS=0x38 MINS=0x39 kfdhdb.ub4spare[0]: 0 ; 0x0ec: 0x00000000 kfdhdb.ub4spare[1]: 0 ; 0x0f0: 0x00000000 kfdhdb.ub4spare[2]: 0 ; 0x0f4: 0x00000000 kfdhdb.ub4spare[3]: 0 ; 0x0f8: 0x00000000 kfdhdb.ub4spare[4]: 0 ; 0x0fc: 0x00000000 kfdhdb.ub4spare[5]: 0 ; 0x100: 0x00000000 kfdhdb.ub4spare[6]: 0 ; 0x104: 0x00000000 kfdhdb.ub4spare[7]: 0 ; 0x108: 0x00000000 kfdhdb.ub4spare[8]: 0 ; 0x10c: 0x00000000 kfdhdb.ub4spare[9]: 0 ; 0x110: 0x00000000 kfdhdb.ub4spare[10]: 0 ; 0x114: 0x00000000 kfdhdb.ub4spare[11]: 0 ; 0x118: 0x00000000 kfdhdb.ub4spare[12]: 0 ; 0x11c: 0x00000000 kfdhdb.ub4spare[13]: 0 ; 0x120: 0x00000000 kfdhdb.ub4spare[14]: 0 ; 0x124: 0x00000000 kfdhdb.ub4spare[15]: 0 ; 0x128: 0x00000000 kfdhdb.ub4spare[16]: 0 ; 0x12c: 0x00000000 kfdhdb.ub4spare[17]: 0 ; 0x130: 0x00000000 kfdhdb.ub4spare[18]: 0 ; 0x134: 0x00000000 kfdhdb.ub4spare[19]: 0 ; 0x138: 0x00000000 kfdhdb.ub4spare[20]: 0 ; 0x13c: 0x00000000 kfdhdb.ub4spare[21]: 0 ; 0x140: 0x00000000 kfdhdb.ub4spare[22]: 0 ; 0x144: 0x00000000 kfdhdb.ub4spare[23]: 0 ; 0x148: 0x00000000 kfdhdb.ub4spare[24]: 0 ; 0x14c: 0x00000000 kfdhdb.ub4spare[25]: 0 ; 0x150: 0x00000000 kfdhdb.ub4spare[26]: 0 ; 0x154: 0x00000000 kfdhdb.ub4spare[27]: 0 ; 0x158: 0x00000000 kfdhdb.ub4spare[28]: 0 ; 0x15c: 0x00000000 kfdhdb.ub4spare[29]: 0 ; 0x160: 0x00000000 kfdhdb.ub4spare[30]: 0 ; 0x164: 0x00000000 kfdhdb.ub4spare[31]: 0 ; 0x168: 0x00000000 kfdhdb.ub4spare[32]: 0 ; 0x16c: 0x00000000 kfdhdb.ub4spare[33]: 0 ; 0x170: 0x00000000 kfdhdb.ub4spare[34]: 0 ; 0x174: 0x00000000 kfdhdb.ub4spare[35]: 0 ; 0x178: 0x00000000 kfdhdb.ub4spare[36]: 0 ; 0x17c: 0x00000000 kfdhdb.ub4spare[37]: 0 ; 0x180: 0x00000000 kfdhdb.ub4spare[38]: 0 ; 0x184: 0x00000000 kfdhdb.ub4spare[39]: 0 ; 0x188: 0x00000000 kfdhdb.ub4spare[40]: 0 ; 0x18c: 0x00000000 kfdhdb.ub4spare[41]: 0 ; 0x190: 0x00000000 kfdhdb.ub4spare[42]: 0 ; 0x194: 0x00000000 kfdhdb.ub4spare[43]: 0 ; 0x198: 0x00000000 kfdhdb.ub4spare[44]: 0 ; 0x19c: 0x00000000 kfdhdb.ub4spare[45]: 0 ; 0x1a0: 0x00000000 kfdhdb.ub4spare[46]: 0 ; 0x1a4: 0x00000000 kfdhdb.ub4spare[47]: 0 ; 0x1a8: 0x00000000 kfdhdb.ub4spare[48]: 0 ; 0x1ac: 0x00000000 kfdhdb.ub4spare[49]: 0 ; 0x1b0: 0x00000000 kfdhdb.ub4spare[50]: 0 ; 0x1b4: 0x00000000 kfdhdb.ub4spare[51]: 0 ; 0x1b8: 0x00000000 kfdhdb.ub4spare[52]: 0 ; 0x1bc: 0x00000000 kfdhdb.ub4spare[53]: 0 ; 0x1c0: 0x00000000 kfdhdb.ub4spare[54]: 0 ; 0x1c4: 0x00000000 kfdhdb.ub4spare[55]: 0 ; 0x1c8: 0x00000000 kfdhdb.ub4spare[56]: 0 ; 0x1cc: 0x00000000 kfdhdb.ub4spare[57]: 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 [oracle@xifenfei raw]$ kfed read raw3 blknum=510 kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 13 ; 0x002: KFBTYP_PST_NONE kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 2147483902 ; 0x004: T=1 NUMB=0xfe kfbh.block.obj: 2147483649 ; 0x008: TYPE=0x8 NUMB=0x1 kfbh.check: 17662718 ; 0x00c: 0x010d82fe kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000