AIX下Oracle 10g asm diskgrop盘头信息修复经验分享
年前处理的一个案例：p570分区，AIX 5309，ORACLE 10g RAC，无HACMP 使用ASM；通过2个IBM B24 SAN SWITCH连接共享存储IBM DS8100，使用SDDPCM＋MPIO。关机后，把原有的2个B24 SAN交换机的线路切换到新的B80 SAN中。但是当时由于多个原因，关机前没有检查和记录磁盘情况，重启动后发现存储盘...显示全部年前处理的一个案例：
p570分区，AIX 5309，ORACLE 10g RAC，无HACMP 使用ASM；通过2个IBM B24 SAN SWITCH连接共享存储IBM DS8100，使用SDDPCM＋MPIO。
关机后，把原有的2个B24 SAN交换机的线路切换到新的B80 SAN中。
但是当时由于多个原因，关机前没有检查和记录磁盘情况，重启动后发现存储盘都没有PVID和VG等信息：
#lspv
hdisk0 00c07785ef303251 rootvg active
hdisk1 00c4e7240bc05149 rootvg active
hdisk2 00c4e724ad76d823 None (有pvid，但是只存在ODM中，实际磁盘上并没有该信息)
hdisk3 none None
hdisk4 none None
hdisk5 none None
hdisk6 none None
hdisk7 none None
hdisk8 none None
hdisk9 none None
hdisk10 none None
hdisk11 none None
hdisk12 none None
hdisk13 none None
hdisk14 none None
hdisk15 none None
hdisk16 none None
hdisk17 none None
hdisk18 none None
hdisk19 none None
hdisk20 none None
hdisk21 none None
hdisk22 none None
hdisk23 00c4e724a9d7c44f None
hdisk24 none None
hdisk25 none None
hdisk26 00c4e854a9797807 None
hdisk27 none None
hdisk28 none None
#lsvg -o
rootvg
#lsvg
rootvg
检查磁盘发现VGDA/VGSA等LVM头信息均没有
#lquerypv -h /dev/hdisk2
00000000 00820101 00000000 80000000 9D4E014E |.............N.N|
00000010 000002D7 00000000 00000000 00000000 |................|
00000020 4F52434C 4449534B 00000000 00000000 |ORCLDISK........|
00000030 00000000 00000000 00000000 00000000 |................|
00000040 0A100000 00000103 4650534B 4447315F |........FPSKDG1_|
00000050 30303030 00000000 00000000 00000000 |0000............|
00000060 00000000 00000000 4650534B 44473100 |........FPSKDG1.|
00000070 00000000 00000000 00000000 00000000 |................|
00000080 00000000 00000000 4650534B 4447315F |........FPSKDG1_| <----硬盘头并没有PVID信息
00000090 30303030 00000000 00000000 00000000 |0000............|
000000A0 00000000 00000000 00000000 00000000 |................|
000000B0 00000000 00000000 00000000 00000000 |................|
000000C0 00000000 00000000 01F66F30 DB9C0800 |..........o0....|
000000D0 01F6C733 75A77C00 02001000 00100000 |...3u.|.........|
000000E0 0001BC80 00032000 00000003 00000001 |...... .........|
000000F0 00000002 00000002 0000FFFF FFFFFFFF |................|
#pcmpath query device|pg
Total Dual Active and Active/Asymmetrc Devices : 27
DEV#: 2 DEVICE NAME: hdisk2 TYPE: 2107900 ALGORITHM: Load Balance
SERIAL: 75xxxxx0000
==========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi0/path1 OPEN NORMAL 65133 0
1 fscsi0/path2 OPEN NORMAL 64262 0
2 fscsi1/path0 OPEN NORMAL 30961 0
3 fscsi1/path3 OPEN NORMAL 30957 0
DEV#: 3 DEVICE NAME: hdisk3 TYPE: 2107900 ALGORITHM: Load Balance
SERIAL: 75xxxxx0001
==========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi0/path1 OPEN NORMAL 74770 0
1 fscsi0/path2 OPEN NORMAL 74164 0
2 fscsi1/path0 OPEN NORMAL 35591 0
3 fscsi1/path3 OPEN NORMAL 35260 0
#
当时不知道是采用ORACLE ASM来直接管理PV的环境，尝试了作chdev -l hdiskX -a pv=yes这样的操作，破坏了diskgroup盘原有正确的头部数据（见下面第四张图）。
经过对一些头信息没有被破坏的盘进行分析发现，相同diskgroup中的盘的头部信息有一些规律可循，见图：
根据规律可以重建被破坏的diskgroup盘的头信息。
规律1（对应第一张图片中标红色框的4个地方）：hdisk7是FPSKDG1这个diskgroup里的第5块盘，hdisk8是第6块盘......这个应该是在建立diskgroup和增加盘的时候按先后顺序定义的（注意：从第0块盘算起的哦）。
规律2（对应第一张图片中标蓝色框的2个地方）：37和E4这2个字节的数据也是有一定关联的，diskgroup中的盘越多越好推理，经过对比和多次尝试，一般都是可以恢复的。
***但是有一点必须注意的是，diskgroup里面第0块盘的头信息和其它成员盘的差别要多很多(上面第三张图），在我目前看来是很难恢复的。
#kfed read /dev/hdisk7
kfbh.endian: 0 ; 0x000: 0x00
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: 2147483653 ; 0x008: TYPE=0x8 NUMB=0x5
kfbh.check: 2922881508 ; 0x00c: 0xae37a1e4
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: 5 ; 0x024: 0x0005
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: FPSKDG1_0005 ; 0x028: length=12
kfdhdb.grpname: FPSKDG1 ; 0x048: length=7
kfdhdb.fgname: FPSKDG1_0005 ; 0x068: length=12
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32927536 ; 0x0a8: HOUR=0x10 DAYS=0x19 MNTH=0xb YEAR=0x7d9
kfdhdb.crestmp.lo: 3723322368 ; 0x0ac: USEC=0x0 MSEC=0x359 SECS=0x1e MINS=0x37
kfdhdb.mntstmp.hi: 32933679 ; 0x0b0: HOUR=0xf DAYS=0x19 MNTH=0x1 YEAR=0x7da
kfdhdb.mntstmp.lo: 573501440 ; 0x0b4: USEC=0x0 MSEC=0x3bc SECS=0x22 MINS=0x8
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 204800 ; 0x0c4: 0x00032000
kfdhdb.pmcnt: 3 ; 0x0c8: 0x00000003
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: 32927536 ; 0x0e4: HOUR=0x10 DAYS=0x19 MNTH=0xb YEAR=0x7d9
kfdhdb.grpstmp.lo: 3684387840 ; 0x0e8: USEC=0x0 MSEC=0x2d3 SECS=0x39 MINS=0x36
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
根据上面的kfed获得的diskgroup盘的头信息，长度为0x01FF，256字节，正好是一个扇区
所以只需要根据规律，用winhex重新构造这个扇区的数据，dd写回去即可
dd if=/dev/hdisk7 of=/tmp/hdisk7.dd.512 bs=512 count=1
dd if=/tmp/hdisk7.dd.512.new of=/dev/hdisk7 bs=512 count=1
另外，附上各命令或软件输出的第一列即offset使用的进制：
od -x /dev/hdisk2 | pg 8进制
lquerypv -h /dev/hdisk2 0 200 16进制
winhex 默认10进制，可在选项里改为16进制，或鼠标单击offset列依次切换
kfed read /dev/hdisk2 里面的offset为16进制，但是后面的地址需要加上20收起
p570分区，AIX 5309，ORACLE 10g RAC，无HACMP 使用ASM；通过2个IBM B24 SAN SWITCH连接共享存储IBM DS8100，使用SDDPCM＋MPIO。
关机后，把原有的2个B24 SAN交换机的线路切换到新的B80 SAN中。
但是当时由于多个原因，关机前没有检查和记录磁盘情况，重启动后发现存储盘都没有PVID和VG等信息：
#lspv
hdisk0 00c07785ef303251 rootvg active
hdisk1 00c4e7240bc05149 rootvg active
hdisk2 00c4e724ad76d823 None (有pvid，但是只存在ODM中，实际磁盘上并没有该信息)
hdisk3 none None
hdisk4 none None
hdisk5 none None
hdisk6 none None
hdisk7 none None
hdisk8 none None
hdisk9 none None
hdisk10 none None
hdisk11 none None
hdisk12 none None
hdisk13 none None
hdisk14 none None
hdisk15 none None
hdisk16 none None
hdisk17 none None
hdisk18 none None
hdisk19 none None
hdisk20 none None
hdisk21 none None
hdisk22 none None
hdisk23 00c4e724a9d7c44f None
hdisk24 none None
hdisk25 none None
hdisk26 00c4e854a9797807 None
hdisk27 none None
hdisk28 none None
#lsvg -o
rootvg
#lsvg
rootvg
检查磁盘发现VGDA/VGSA等LVM头信息均没有
#lquerypv -h /dev/hdisk2
00000000 00820101 00000000 80000000 9D4E014E |.............N.N|
00000010 000002D7 00000000 00000000 00000000 |................|
00000020 4F52434C 4449534B 00000000 00000000 |ORCLDISK........|
00000030 00000000 00000000 00000000 00000000 |................|
00000040 0A100000 00000103 4650534B 4447315F |........FPSKDG1_|
00000050 30303030 00000000 00000000 00000000 |0000............|
00000060 00000000 00000000 4650534B 44473100 |........FPSKDG1.|
00000070 00000000 00000000 00000000 00000000 |................|
00000080 00000000 00000000 4650534B 4447315F |........FPSKDG1_| <----硬盘头并没有PVID信息
00000090 30303030 00000000 00000000 00000000 |0000............|
000000A0 00000000 00000000 00000000 00000000 |................|
000000B0 00000000 00000000 00000000 00000000 |................|
000000C0 00000000 00000000 01F66F30 DB9C0800 |..........o0....|
000000D0 01F6C733 75A77C00 02001000 00100000 |...3u.|.........|
000000E0 0001BC80 00032000 00000003 00000001 |...... .........|
000000F0 00000002 00000002 0000FFFF FFFFFFFF |................|
#pcmpath query device|pg
Total Dual Active and Active/Asymmetrc Devices : 27
DEV#: 2 DEVICE NAME: hdisk2 TYPE: 2107900 ALGORITHM: Load Balance
SERIAL: 75xxxxx0000
==========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi0/path1 OPEN NORMAL 65133 0
1 fscsi0/path2 OPEN NORMAL 64262 0
2 fscsi1/path0 OPEN NORMAL 30961 0
3 fscsi1/path3 OPEN NORMAL 30957 0
DEV#: 3 DEVICE NAME: hdisk3 TYPE: 2107900 ALGORITHM: Load Balance
SERIAL: 75xxxxx0001
==========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi0/path1 OPEN NORMAL 74770 0
1 fscsi0/path2 OPEN NORMAL 74164 0
2 fscsi1/path0 OPEN NORMAL 35591 0
3 fscsi1/path3 OPEN NORMAL 35260 0
#
当时不知道是采用ORACLE ASM来直接管理PV的环境，尝试了作chdev -l hdiskX -a pv=yes这样的操作，破坏了diskgroup盘原有正确的头部数据（见下面第四张图）。
经过对一些头信息没有被破坏的盘进行分析发现，相同diskgroup中的盘的头部信息有一些规律可循，见图：
根据规律可以重建被破坏的diskgroup盘的头信息。
规律1（对应第一张图片中标红色框的4个地方）：hdisk7是FPSKDG1这个diskgroup里的第5块盘，hdisk8是第6块盘......这个应该是在建立diskgroup和增加盘的时候按先后顺序定义的（注意：从第0块盘算起的哦）。
规律2（对应第一张图片中标蓝色框的2个地方）：37和E4这2个字节的数据也是有一定关联的，diskgroup中的盘越多越好推理，经过对比和多次尝试，一般都是可以恢复的。
***但是有一点必须注意的是，diskgroup里面第0块盘的头信息和其它成员盘的差别要多很多(上面第三张图），在我目前看来是很难恢复的。
#kfed read /dev/hdisk7
kfbh.endian: 0 ; 0x000: 0x00
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: 2147483653 ; 0x008: TYPE=0x8 NUMB=0x5
kfbh.check: 2922881508 ; 0x00c: 0xae37a1e4
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: 5 ; 0x024: 0x0005
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: FPSKDG1_0005 ; 0x028: length=12
kfdhdb.grpname: FPSKDG1 ; 0x048: length=7
kfdhdb.fgname: FPSKDG1_0005 ; 0x068: length=12
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32927536 ; 0x0a8: HOUR=0x10 DAYS=0x19 MNTH=0xb YEAR=0x7d9
kfdhdb.crestmp.lo: 3723322368 ; 0x0ac: USEC=0x0 MSEC=0x359 SECS=0x1e MINS=0x37
kfdhdb.mntstmp.hi: 32933679 ; 0x0b0: HOUR=0xf DAYS=0x19 MNTH=0x1 YEAR=0x7da
kfdhdb.mntstmp.lo: 573501440 ; 0x0b4: USEC=0x0 MSEC=0x3bc SECS=0x22 MINS=0x8
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 204800 ; 0x0c4: 0x00032000
kfdhdb.pmcnt: 3 ; 0x0c8: 0x00000003
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: 32927536 ; 0x0e4: HOUR=0x10 DAYS=0x19 MNTH=0xb YEAR=0x7d9
kfdhdb.grpstmp.lo: 3684387840 ; 0x0e8: USEC=0x0 MSEC=0x2d3 SECS=0x39 MINS=0x36
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
根据上面的kfed获得的diskgroup盘的头信息，长度为0x01FF，256字节，正好是一个扇区
所以只需要根据规律，用winhex重新构造这个扇区的数据，dd写回去即可
dd if=/dev/hdisk7 of=/tmp/hdisk7.dd.512 bs=512 count=1
dd if=/tmp/hdisk7.dd.512.new of=/dev/hdisk7 bs=512 count=1
另外，附上各命令或软件输出的第一列即offset使用的进制：
od -x /dev/hdisk2 | pg 8进制
lquerypv -h /dev/hdisk2 0 200 16进制
winhex 默认10进制，可在选项里改为16进制，或鼠标单击offset列依次切换
kfed read /dev/hdisk2 里面的offset为16进制，但是后面的地址需要加上20收起