标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,698)
- DB2 (22)
- MySQL (74)
- Oracle (1,559)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (571)
- Oracle安装升级 (93)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (81)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- Bug 21915719 Database hang or may fail to OPEN in 12c IBM AIX or HPUX Itanium – ORA-742, DEADLOCK or ORA-600 [kcrfrgv_nextlwn_scn] ORA-600 [krr_process_read_error_2]
- ORA-600 ktuPopDictI_1恢复
- impdp导入数据丢失sys授权问题分析
- impdp 创建index提示ORA-00942: table or view does not exist
- 数据泵导出 (expdp) 和导入 (impdp)工具性能降低分析参考
- 19c非归档数据库断电导致ORA-00742故障恢复
- Oracle 19c – 手动升级到 Non-CDB Oracle Database 19c 的完整核对清单
- sqlite数据库简单操作
- Oracle 暂定和恢复功能
- .pzpq扩展名勒索恢复
- Oracle read only用户—23ai新特性:只读用户
- 迁移awr快照数据到自定义表空间
- .hmallox加密mariadb/mysql数据库恢复
- 2025年首个故障恢复—ORA-600 kcbzib_kcrsds_1
- 第一例Oracle 21c恢复咨询
- ORA-15411: Failure groups in disk group DATA have different number of disks.
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
分类目录归档:Oracle ASM
asm磁盘头全部损坏数据0丢失恢复
接到朋友反馈说他们公司的10.2.0.4(无磁盘头备份)asm 磁盘头都损坏了,确定是被人恶意dd掉了磁盘头的1k,他通过查询发过来结果如下
分析alert日志,确定磁盘组和磁盘信息
asm mount data磁盘组报错
Sun Apr 16 21:39:31 2017 NOTE: cache dismounting group 2/0x3F94036B (DATA) NOTE: dbwr not being msg'd to dismount ERROR: diskgroup DATA was not mounted Sun Apr 16 21:39:31 2017 ERROR: no PST quorum in group 3: required 2, found 0
data磁盘组和磁盘信息
Mon Mar 20 16:21:59 2017 NOTE: Hbeat: instance not first (grp 3) NOTE: cache opening disk 2 of grp 2: DATA_0002 path:/dev/raw/raw21 Mon Mar 20 16:21:59 2017 NOTE: F1X0 found on disk 2 fcn 0.47624333 NOTE: cache opening disk 3 of grp 2: DATA_0003 path:/dev/raw/raw22 NOTE: cache opening disk 4 of grp 2: DATA_0004 path:/dev/raw/raw23 NOTE: cache opening disk 5 of grp 2: DATA_0005 path:/dev/raw/raw24 NOTE: F1X0 found on disk 5 fcn 0.47624333 NOTE: cache opening disk 6 of grp 2: DATA_0006 path:/dev/raw/raw26 NOTE: cache opening disk 7 of grp 2: DATA_0007 path:/dev/raw/raw25 NOTE: F1X0 found on disk 7 fcn 0.47624333 NOTE: cache mounting (not first) group 2/0x01B869DC (DATA) Mon Mar 20 16:21:59 2017 kjbdomatt send to node 1 Mon Mar 20 16:21:59 2017 NOTE: attached to recovery domain 2 Mon Mar 20 16:21:59 2017 NOTE: opening chunk 2 at fcn 0.201560874 ABA NOTE: seq=614 blk=4144 Mon Mar 20 16:21:59 2017 NOTE: cache mounting group 2/0x01B869DC (DATA) succeeded SUCCESS: diskgroup DATA was mounted
最后一次正常mount是使用了raw21-raw26的裸设备为data磁盘组,但是这里从DATA_002开始,表明很可能最初了两个asm disk被删除,继续分析alert日志
Mon Oct 15 01:53:16 2012 CREATE DISKGROUP DATA Normal REDUNDANCY DISK '/dev/raw/raw6' SIZE 1144409M , '/dev/raw/raw7' SIZE 1144409M Sat Dec 27 22:41:39 2014 alter diskgroup data add disk '/dev/raw/raw21' Sat Dec 27 22:41:54 2014 alter diskgroup data add disk '/dev/raw/raw22' Sat Dec 27 22:42:14 2014 alter diskgroup data add disk '/dev/raw/raw23' Sat Dec 27 22:42:31 2014 alter diskgroup data add disk '/dev/raw/raw24' Sat Dec 27 22:42:51 2014 alter diskgroup data add disk '/dev/raw/raw26' Sat Dec 27 22:43:10 2014 alter diskgroup data add disk '/dev/raw/raw25' Mon Dec 29 17:55:07 2014 alter diskgroup data drop disk 'DATA_0000' Tue Dec 30 03:14:42 2014 alter diskgroup data drop disk 'DATA_0001'
kfed确认磁盘头损坏情况
通过kfed分析dd出来的磁盘头发现每个磁盘头都一样,第一个block损坏
[oracle@rac1 xifenfei]$ kfed read raw22 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 7F21AF427400 00000000 00000000 00000000 00000000 [................] Repeat 255 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0] [oracle@rac1 xifenfei]$ kfed read raw22 blkn=2|more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 2 ; 0x004: blk=2 kfbh.block.obj: 2147483651 ; 0x008: disk=3 kfbh.check: 2184525105 ; 0x00c: 0x82353531 kfbh.fcn.base: 47625389 ; 0x010: 0x02d6b4ad kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdatb10.aunum: 0 ; 0x000: 0x00000000 kfdatb10.shrink: 448 ; 0x004: 0x01c0 kfdatb10.ub2pad: 0 ; 0x006: 0x0000 kfdatb10.auinfo[0].link.next: 8 ; 0x008: 0x0008 kfdatb10.auinfo[0].link.prev: 8 ; 0x00a: 0x0008 kfdatb10.auinfo[0].free: 0 ; 0x00c: 0x0000 kfdatb10.auinfo[0].total: 448 ; 0x00e: 0x01c0 kfdatb10.auinfo[1].link.next: 16 ; 0x010: 0x0010 kfdatb10.auinfo[1].link.prev: 16 ; 0x012: 0x0010 kfdatb10.auinfo[1].free: 0 ; 0x014: 0x0000 kfdatb10.auinfo[1].total: 0 ; 0x016: 0x0000 kfdatb10.auinfo[2].link.next: 24 ; 0x018: 0x0018 kfdatb10.auinfo[2].link.prev: 24 ; 0x01a: 0x0018 kfdatb10.auinfo[2].free: 0 ; 0x01c: 0x0000 kfdatb10.auinfo[2].total: 0 ; 0x01e: 0x0000 kfdatb10.auinfo[3].link.next: 32 ; 0x020: 0x0020 kfdatb10.auinfo[3].link.prev: 32 ; 0x022: 0x0020
恢复思路
确定磁盘是只被干掉了第一个block,但是由于asm 是10.2.0.4的,没有asm disk header的备份,因此也只能自己去人工kfed修复.但是考虑到该case中所有的asm disk header 全部丢失,无任何参考,完全修复比较麻烦,另外这个库也比较小,考虑修复asm disk header 关键部位,然后通过工具直接拷贝出来数据文件,在文件系统中open库的思路.主要需要恢复磁盘头基本信息(diskname,disksize,disknum,ausize,blocksize,file directory等)
通过kfed找出来file directory
kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 2 ; 0x004: blk=2 kfbh.block.obj: 1 ; 0x008: file=1 kfbh.check: 2363360058 ; 0x00c: 0x8cde033a kfbh.fcn.base: 48245591 ; 0x010: 0x02e02b57 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfffdb.node.incarn: 1 ; 0x000: A=1 NUMM=0x0 kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kfffdb.hibytes: 0 ; 0x00c: 0x00000000 kfffdb.lobytes: 1048576 ; 0x010: 0x00100000 kfffdb.xtntcnt: 3 ; 0x014: 0x00000003 kfffdb.xtnteof: 3 ; 0x018: 0x00000003 kfffdb.blkSize: 4096 ; 0x01c: 0x00001000 kfffdb.flags: 65 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=1 A=0 kfffdb.fileType: 15 ; 0x021: 0x0f kfffdb.dXrs: 19 ; 0x022: SCHE=0x1 NUMB=0x3
通过kfed找出来disk directory
kfffde[0].xptr.au: 4 ; 0x4a0: 0x00000004 kfffde[0].xptr.disk: 7 ; 0x4a4: 0x0007 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: 17405 ; 0x4a8: 0x000043fd kfffde[1].xptr.disk: 6 ; 0x4ac: 0x0006 kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0 kfffde[1].xptr.chk: 146 ; 0x4af: 0x92 kfffde[2].xptr.au: 330031 ; 0x4b0: 0x0005092f kfffde[2].xptr.disk: 4 ; 0x4b4: 0x0004 kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0 kfffde[2].xptr.chk: 13 ; 0x4b7: 0x0d kfddde[2].entry.incarn: 1 ; 0x3a4: A=1 NUMM=0x0 kfddde[2].entry.hash: 2 ; 0x3a8: 0x00000002 kfddde[2].entry.refer.number:4294967295 ; 0x3ac: 0xffffffff kfddde[2].entry.refer.incarn: 0 ; 0x3b0: A=0 NUMM=0x0 kfddde[2].dsknum: 2 ; 0x3b4: 0x0002 kfddde[2].state: 2 ; 0x3b6: KFDSTA_NORMAL kfddde[2].ddchgfl: 0 ; 0x3b7: 0x00 kfddde[2].dskname: DATA_0002 ; 0x3b8: length=9 kfddde[2].fgname: DATA_0002 ; 0x3d8: length=9 kfddde[2].crestmp.hi: 33010550 ; 0x3f8: HOUR=0x16 DAYS=0x1b MNTH=0xc YEAR=0x7de kfddde[2].crestmp.lo: 2793310208 ; 0x3fc: USEC=0x0 MSEC=0x3a2 SECS=0x27 MINS=0x29 kfddde[2].failstmp.hi: 0 ; 0x400: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[2].failstmp.lo: 0 ; 0x404: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[2].timer: 0 ; 0x408: 0x00000000 kfddde[2].size: 1258291 ; 0x40c: 0x00133333 kfddde[2].srRloc.super.hiStart: 0 ; 0x410: 0x00000000 kfddde[2].srRloc.super.loStart: 0 ; 0x414: 0x00000000 kfddde[2].srRloc.super.length: 0 ; 0x418: 0x00000000 kfddde[2].srRloc.incarn: 0 ; 0x41c: 0x00000000 kfddde[2].dskrprtm: 0 ; 0x420: 0x00000000 kfddde[2].start0: 0 ; 0x424: 0x00000000 kfddde[2].size0: 1258291 ; 0x428: 0x00133333 kfddde[2].used0: 1258229 ; 0x42c: 0x001332f5 kfddde[2].slot: 0 ; 0x430: 0x00000000 kfddde[3].entry.incarn: 1 ; 0x564: A=1 NUMM=0x0 kfddde[3].entry.hash: 3 ; 0x568: 0x00000003 kfddde[3].entry.refer.number:4294967295 ; 0x56c: 0xffffffff kfddde[3].entry.refer.incarn: 0 ; 0x570: A=0 NUMM=0x0 kfddde[3].dsknum: 3 ; 0x574: 0x0003 kfddde[3].state: 2 ; 0x576: KFDSTA_NORMAL kfddde[3].ddchgfl: 0 ; 0x577: 0x00 kfddde[3].dskname: DATA_0003 ; 0x578: length=9 kfddde[3].fgname: DATA_0003 ; 0x598: length=9 kfddde[3].crestmp.hi: 33010550 ; 0x5b8: HOUR=0x16 DAYS=0x1b MNTH=0xc YEAR=0x7de kfddde[3].crestmp.lo: 2811397120 ; 0x5bc: USEC=0x0 MSEC=0xa1 SECS=0x39 MINS=0x29 kfddde[3].failstmp.hi: 0 ; 0x5c0: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[3].failstmp.lo: 0 ; 0x5c4: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[3].timer: 0 ; 0x5c8: 0x00000000 kfddde[3].size: 1258291 ; 0x5cc: 0x00133333 kfddde[3].srRloc.super.hiStart: 0 ; 0x5d0: 0x00000000 kfddde[3].srRloc.super.loStart: 0 ; 0x5d4: 0x00000000 kfddde[3].srRloc.super.length: 0 ; 0x5d8: 0x00000000 kfddde[3].srRloc.incarn: 0 ; 0x5dc: 0x00000000 kfddde[3].dskrprtm: 0 ; 0x5e0: 0x00000000 kfddde[3].start0: 0 ; 0x5e4: 0x00000000 kfddde[3].size0: 1258291 ; 0x5e8: 0x00133333 kfddde[3].used0: 1258128 ; 0x5ec: 0x00133290 kfddde[3].slot: 0 ; 0x5f0: 0x00000000 kfddde[4].entry.incarn: 1 ; 0x724: A=1 NUMM=0x0 kfddde[4].entry.hash: 4 ; 0x728: 0x00000004 kfddde[4].entry.refer.number:4294967295 ; 0x72c: 0xffffffff kfddde[4].entry.refer.incarn: 0 ; 0x730: A=0 NUMM=0x0 kfddde[4].dsknum: 4 ; 0x734: 0x0004 kfddde[4].state: 2 ; 0x736: KFDSTA_NORMAL kfddde[4].ddchgfl: 0 ; 0x737: 0x00 kfddde[4].dskname: DATA_0004 ; 0x738: length=9 kfddde[4].fgname: DATA_0004 ; 0x758: length=9 kfddde[4].crestmp.hi: 33010550 ; 0x778: HOUR=0x16 DAYS=0x1b MNTH=0xc YEAR=0x7de kfddde[4].crestmp.lo: 2834565120 ; 0x77c: USEC=0x0 MSEC=0x102 SECS=0xf MINS=0x2a kfddde[4].failstmp.hi: 0 ; 0x780: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[4].failstmp.lo: 0 ; 0x784: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[4].timer: 0 ; 0x788: 0x00000000 kfddde[4].size: 1258291 ; 0x78c: 0x00133333 kfddde[4].srRloc.super.hiStart: 0 ; 0x790: 0x00000000 kfddde[4].srRloc.super.loStart: 0 ; 0x794: 0x00000000 kfddde[4].srRloc.super.length: 0 ; 0x798: 0x00000000 kfddde[4].srRloc.incarn: 0 ; 0x79c: 0x00000000 kfddde[4].dskrprtm: 0 ; 0x7a0: 0x00000000 kfddde[4].start0: 0 ; 0x7a4: 0x00000000 kfddde[4].size0: 1258291 ; 0x7a8: 0x00133333 kfddde[4].used0: 1258291 ; 0x7ac: 0x00133333 kfddde[4].slot: 0 ; 0x7b0: 0x00000000 kfddde[5].entry.incarn: 1 ; 0x8e4: A=1 NUMM=0x0 kfddde[5].entry.hash: 5 ; 0x8e8: 0x00000005 kfddde[5].entry.refer.number:4294967295 ; 0x8ec: 0xffffffff kfddde[5].entry.refer.incarn: 0 ; 0x8f0: A=0 NUMM=0x0 kfddde[5].dsknum: 5 ; 0x8f4: 0x0005 kfddde[5].state: 2 ; 0x8f6: KFDSTA_NORMAL kfddde[5].ddchgfl: 0 ; 0x8f7: 0x00 kfddde[5].dskname: DATA_0005 ; 0x8f8: length=9 kfddde[5].fgname: DATA_0005 ; 0x918: length=9 kfddde[5].crestmp.hi: 33010550 ; 0x938: HOUR=0x16 DAYS=0x1b MNTH=0xc YEAR=0x7de kfddde[5].crestmp.lo: 2853560320 ; 0x93c: USEC=0x0 MSEC=0x178 SECS=0x21 MINS=0x2a kfddde[5].failstmp.hi: 0 ; 0x940: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[5].failstmp.lo: 0 ; 0x944: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[5].timer: 0 ; 0x948: 0x00000000 kfddde[5].size: 1258291 ; 0x94c: 0x00133333 kfddde[5].srRloc.super.hiStart: 0 ; 0x950: 0x00000000 kfddde[5].srRloc.super.loStart: 0 ; 0x954: 0x00000000 kfddde[5].srRloc.super.length: 0 ; 0x958: 0x00000000 kfddde[5].srRloc.incarn: 0 ; 0x95c: 0x00000000 kfddde[5].dskrprtm: 0 ; 0x960: 0x00000000 kfddde[5].start0: 0 ; 0x964: 0x00000000 kfddde[5].size0: 1258291 ; 0x968: 0x00133333 kfddde[5].used0: 1258255 ; 0x96c: 0x0013330f kfddde[5].slot: 0 ; 0x970: 0x00000000 kfddde[6].entry.incarn: 1 ; 0xaa4: A=1 NUMM=0x0 kfddde[6].entry.hash: 6 ; 0xaa8: 0x00000006 kfddde[6].entry.refer.number:4294967295 ; 0xaac: 0xffffffff kfddde[6].entry.refer.incarn: 0 ; 0xab0: A=0 NUMM=0x0 kfddde[6].dsknum: 6 ; 0xab4: 0x0006 kfddde[6].state: 2 ; 0xab6: KFDSTA_NORMAL kfddde[6].ddchgfl: 0 ; 0xab7: 0x00 kfddde[6].dskname: DATA_0006 ; 0xab8: length=9 kfddde[6].fgname: DATA_0006 ; 0xad8: length=9 kfddde[6].crestmp.hi: 33010550 ; 0xaf8: HOUR=0x16 DAYS=0x1b MNTH=0xc YEAR=0x7de kfddde[6].crestmp.lo: 2875645952 ; 0xafc: USEC=0x0 MSEC=0x1b8 SECS=0x36 MINS=0x2a kfddde[6].failstmp.hi: 0 ; 0xb00: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[6].failstmp.lo: 0 ; 0xb04: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[6].timer: 0 ; 0xb08: 0x00000000 kfddde[6].size: 1258291 ; 0xb0c: 0x00133333 kfddde[6].srRloc.super.hiStart: 0 ; 0xb10: 0x00000000 kfddde[6].srRloc.super.loStart: 0 ; 0xb14: 0x00000000 kfddde[6].srRloc.super.length: 0 ; 0xb18: 0x00000000 kfddde[6].srRloc.incarn: 0 ; 0xb1c: 0x00000000 kfddde[6].dskrprtm: 0 ; 0xb20: 0x00000000 kfddde[6].start0: 0 ; 0xb24: 0x00000000 kfddde[6].size0: 1258291 ; 0xb28: 0x00133333 kfddde[6].used0: 1258247 ; 0xb2c: 0x00133307 kfddde[6].slot: 0 ; 0xb30: 0x00000000 kfddde[7].entry.incarn: 1 ; 0xc64: A=1 NUMM=0x0 kfddde[7].entry.hash: 7 ; 0xc68: 0x00000007 kfddde[7].entry.refer.number:4294967295 ; 0xc6c: 0xffffffff kfddde[7].entry.refer.incarn: 0 ; 0xc70: A=0 NUMM=0x0 kfddde[7].dsknum: 7 ; 0xc74: 0x0007 kfddde[7].state: 2 ; 0xc76: KFDSTA_NORMAL kfddde[7].ddchgfl: 0 ; 0xc77: 0x00 kfddde[7].dskname: DATA_0007 ; 0xc78: length=9 kfddde[7].fgname: DATA_0007 ; 0xc98: length=9 kfddde[7].crestmp.hi: 33010550 ; 0xcb8: HOUR=0x16 DAYS=0x1b MNTH=0xc YEAR=0x7de kfddde[7].crestmp.lo: 2898849792 ; 0xcbc: USEC=0x0 MSEC=0x23c SECS=0xc MINS=0x2b kfddde[7].failstmp.hi: 0 ; 0xcc0: HOUR=0x0 DAYS=0x0 MNTH=0x0 YEAR=0x0 kfddde[7].failstmp.lo: 0 ; 0xcc4: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0 kfddde[7].timer: 0 ; 0xcc8: 0x00000000 kfddde[7].size: 1258291 ; 0xccc: 0x00133333 kfddde[7].srRloc.super.hiStart: 0 ; 0xcd0: 0x00000000 kfddde[7].srRloc.super.loStart: 0 ; 0xcd4: 0x00000000 kfddde[7].srRloc.super.length: 0 ; 0xcd8: 0x00000000 kfddde[7].srRloc.incarn: 0 ; 0xcdc: 0x00000000 kfddde[7].dskrprtm: 0 ; 0xce0: 0x00000000 kfddde[7].start0: 0 ; 0xce4: 0x00000000 kfddde[7].size0: 1258291 ; 0xce8: 0x00133333 kfddde[7].used0: 1258209 ; 0xcec: 0x001332e1 kfddde[7].slot: 0 ; 0xcf0: 0x00000000
结合上述信息构造类似磁盘头文件
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: 3123334821 ; 0x00c: 0xba2a4ea5 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: ORCLDISKVOL2 ; 0x000: length=12 kfdhdb.driver.reserved[0]: 827084630 ; 0x008: 0x314c4f56 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: 2 ; 0x024: 0x0002 kfdhdb.grptyp: 1 ; 0x026: KFDGTP_NORMAL kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DATA_0002 ; 0x028: length=9 kfdhdb.grpname: DATA ; 0x048: length=4 kfdhdb.fgname: DATA_0002 ; 0x068: length=9 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 33010550 ; 0x3f8: HOUR=0x16 DAYS=0x1b MNTH=0xc YEAR=0x7de kfdhdb.crestmp.lo: 2793310208 ; 0x3fc: USEC=0x0 MSEC=0x3a2 SECS=0x27 MINS=0x29 kfdhdb.mntstmp.hi: 33049840 ; 0x0b0: HOUR=0x10 DAYS=0x7 MNTH=0x3 YEAR=0x7e1 kfdhdb.mntstmp.lo: 1588567040 ; 0x0b4: USEC=0x0 MSEC=0x3e7 SECS=0x2a MINS=0x17 kfdhdb.secsize: 512 ; 0x0b8: 0x0200 kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000 kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80 kfdhdb.dsksize: 1258291 ; 0x40c: 0x00133333 kfdhdb.pmcnt: 19 ; 0x0c8: 0x00000013 kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001 kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002 kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
然后通过kfed merge分别对所有磁盘头进行重构,然后通过dul去识别拷贝文件
+DATA/XFF/spfileXFF.ora.265.869858859 +DATA/XFF/CONTROLFILE/Current.256.796701475 +DATA/XFF/ONLINELOG/group_1.257.796701475 +DATA/XFF/ONLINELOG/group_2.258.796701485 +DATA/XFF/ONLINELOG/group_3.266.796704261 +DATA/XFF/ONLINELOG/group_4.267.796704277 +DATA/XFF/ONLINELOG/group_5.1235.824131117 +DATA/XFF/ONLINELOG/group_6.1115.824200515 +DATA/XFF/ONLINELOG/group_7.1113.824200587 +DATA/XFF/ONLINELOG/group_8.1112.824200627 +DATA/XFF/ONLINELOG/group_9.1066.824201189 +DATA/XFF/ONLINELOG/group_10.1063.824201207 +DATA/XFF/ONLINELOG/group_11.1062.824201287 +DATA/XFF/ONLINELOG/group_12.1061.824201301 File 259 datafile size 2147491840, block size 8192 File 260 datafile size 32186048512, block size 8192 File 261 datafile size 6897541120, block size 8192 File 263 datafile size 27409784832, block size 8192 File 264 datafile size 34359730176, block size 8192 File 280 datafile size 31457288192, block size 8192 File 281 datafile size 31457288192, block size 8192 File 330 datafile size 5242888192, block size 8192 File 334 datafile size 20971528192, block size 8192 File 382 datafile size 20971528192, block size 8192 File 383 datafile size 20971528192, block size 8192 File 384 datafile size 31457288192, block size 8192 File 385 datafile size 31457288192, block size 8192 File 386 datafile size 31457288192, block size 8192 File 387 datafile size 4294975488, block size 8192 File 388 datafile size 4294975488, block size 8192 File 389 datafile size 4294975488, block size 8192 File 390 datafile size 4294975488, block size 8192 File 391 datafile size 4294975488, block size 8192 File 392 datafile size 4294975488, block size 8192 File 394 datafile size 31457288192, block size 8192 File 491 datafile size 20971528192, block size 8192 File 494 datafile size 20971528192, block size 8192 File 578 datafile size 31457288192, block size 8192 File 597 datafile size 20971528192, block size 8192 File 613 datafile size 4294975488, block size 8192 File 638 datafile size 31457288192, block size 8192 File 668 datafile size 16988184576, block size 8192 File 688 datafile size 20971528192, block size 8192 File 740 datafile size 31457288192, block size 8192 File 787 datafile size 31457288192, block size 8192 File 798 datafile size 31457288192, block size 8192 File 806 datafile size 31457288192, block size 8192 File 810 datafile size 31457288192, block size 8192 File 845 datafile size 31457288192, block size 8192 File 886 datafile size 31457288192, block size 8192 File 887 datafile size 31457288192, block size 8192 File 889 datafile size 31457288192, block size 8192 File 892 datafile size 31457288192, block size 8192 File 903 datafile size 31457288192, block size 8192 File 932 datafile size 31457288192, block size 8192 File 933 datafile size 3145736192, block size 8192 File 951 datafile size 20971528192, block size 8192 File 953 datafile size 31457288192, block size 8192 File 955 datafile size 31457288192, block size 8192 File 963 datafile size 31457288192, block size 8192 File 1000 datafile size 31457288192, block size 8192 File 1001 datafile size 12035563520, block size 8192 File 1031 datafile size 31457288192, block size 8192 File 1033 datafile size 31457288192, block size 8192 File 1035 datafile size 31457288192, block size 8192 File 1037 datafile size 31457288192, block size 8192 File 1045 datafile size 31457288192, block size 8192 File 1073 datafile size 4294975488, block size 8192 File 1074 datafile size 4294975488, block size 8192 File 1075 datafile size 4294975488, block size 8192 File 1076 datafile size 8589942784, block size 8192 File 1077 datafile size 31457288192, block size 8192 File 1078 datafile size 8589942784, block size 8192 File 1079 datafile size 8589942784, block size 8192 File 1080 datafile size 4294975488, block size 8192 File 1081 datafile size 8589942784, block size 8192 File 1082 datafile size 8589942784, block size 8192 File 1083 datafile size 8589942784, block size 8192 File 1084 datafile size 8589942784, block size 8192 File 1085 datafile size 32365355008, block size 8192 File 1086 datafile size 9071239168, block size 8192 File 1116 datafile size 8589942784, block size 8192 File 1133 datafile size 8589942784, block size 8192 File 1219 datafile size 31457288192, block size 8192 File 1245 datafile size 31457288192, block size 8192 File 1249 datafile size 31457288192, block size 8192 File 1251 datafile size 31457288192, block size 8192 File 1322 datafile size 4294975488, block size 8192 File 1442 datafile size 31457288192, block size 8192 File 1468 datafile size 1048584192, block size 8192 File 1508 datafile size 31457288192, block size 8192 File 1554 datafile size 4294975488, block size 8192 File 1570 datafile size 31457288192, block size 8192 File 2004 datafile size 31457288192, block size 8192 File 2005 datafile size 31457288192, block size 8192 File 2344 datafile size 31457288192, block size 8192 File 2345 datafile size 31457288192, block size 8192 File 2348 datafile size 31457288192, block size 8192 File 2617 datafile size 10737426432, block size 8192 File 2618 datafile size 21474844672, block size 8192 File 2766 datafile size 33554440192, block size 8192 File 2782 datafile size 31457288192, block size 8192 File 2784 datafile size 31457288192, block size 8192 File 2893 datafile size 31457288192, block size 8192 File 2924 datafile size 31457288192, block size 8192 File 2925 datafile size 31457288192, block size 8192 File 2926 datafile size 31457288192, block size 8192 File 2983 datafile size 31457288192, block size 8192 File 2984 datafile size 31457288192, block size 8192 File 3634 datafile size 31457288192, block size 8192 File 3909 datafile size 31457288192, block size 8192 File 3917 datafile size 31457288192, block size 8192 File 3920 datafile size 31457288192, block size 8192 File 3922 datafile size 31457288192, block size 8192
剩下的事情就比较简单了,通过把spfile,controlfile,datafile文件拷贝出来,本地启动数据库,恢复成功
如果您遇到此类情况,无法解决请联系我们,提供专业ORACLE数据库恢复技术支持
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type]
在oracle asm的使用过程中由于操作系统层面的错误操作导致asm disk 被破坏,这里列举了几种破坏之后的kfed报错现象(KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type])
asm mount 磁盘组报错(ORA-15040 ORA-15042)
SQL> alter diskgroup DATA mount; alter diskgroup DATA mount * ERROR at line 1: ORA-15032: not all alterations performed ORA-15040: diskgroup is incomplete ORA-15042: ASM disk "2" is missing from group number "2"
asm alert日志报错(ORA-15335 ORA-15066 ORA-15196等)
ORA-15335: ASM metadata corruption detected in disk group 'DATA' ORA-15130: diskgroup "DATA" is being dismounted ORA-15066: offlining disk "DATA_0002" in group "DATA" may result in a data loss ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh] [2147483651] [48] [0 != 1]
kfed查看磁盘头报错
文件文件头(不光是disk header的4k,可能是连续的几个au,甚至更多)可能彻底损坏,一般kfed 读取都会看到KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type]之类错误
[oracle@fcomtaep2 disks]$ kfed read ASMRECO03 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 7FC18D899400 00000000 00000000 00000000 00000000 [................] Repeat 27 times 7FC18D8995C0 FEEE0001 0001FFFF FFFF0000 00000FFF [................] 7FC18D8995D0 00000000 00000000 00000000 00000000 [................] Repeat 1 times 7FC18D8995F0 00000000 00000000 00000000 AA550000 [..............U.] 7FC18D899600 20494645 54524150 00010000 0000005C [EFI PART....\...] <==== **** Here ****** 7FC18D899610 BD82BBB3 00000000 00000001 00000000 [................] 7FC18D899620 0FFFFFFF 00000000 00000022 00000000 [........".......] 7FC18D899630 0FFFFFDE 00000000 FD8857E5 42D7B49B [.........W.....B] 7FC18D899640 0901FA87 6B3DB5AA 00000002 00000000 [......=k........] 7FC18D899650 00000080 00000080 FE48EB77 00000000 [........w.H.....] 7FC18D899660 00000000 00000000 00000000 00000000 [................] Repeat 25 times 7FC18D899800 EBD0A0A2 4433B9E5 B668C087 C79926B7 [......3D..h..&..] 7FC18D899810 5381F6DF 4626F988 0E4F468D D78D3B28 [...S..&F.FO.(;..] 7FC18D899820 000007A1 00000000 0FFFF85F 00000000 [........_.......] 7FC18D899830 00000000 00000000 00720070 006D0069 [........p.r.i.m.] 7FC18D899840 00720061 00000079 00000000 00000000 [a.r.y...........] 7FC18D899850 00000000 00000000 00000000 00000000 [................] Repeat 186 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
“EFI PART”是分区的元数据,一般是被分区导致asm disk损坏.
[ebernal@dbaasm new2]$ kfed read emcpowerl | head -25 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 2ABD671E9400 00000000 00000000 00000000 00000000 [................] Repeat 31 times 2ABD671E9600 4542414C 454E4F4C 00000001 00000000 [LABELONE........] 2ABD671E9610 E4E1DDB1 00000020 324D564C 31303020 [.... ...LVM2 001] <==== **** Here ****** 2ABD671E9620 50365A77 71327874 34303156 4B4E6136 [wZ6Ptx2qV1046aNK] 2ABD671E9630 35395159 5147634C 487A5A38 63575A37 [YQ95LcGQ8ZzH7ZWc] 2ABD671E9640 00000000 00000019 00030000 00000000 [................] 2ABD671E9650 00000000 00000000 00000000 00000000 [................] 2ABD671E9660 00000000 00000000 00001000 00000000 [................] 2ABD671E9670 0002F000 00000000 00000000 00000000 [................] 2ABD671E9680 00000000 00000000 00000000 00000000 [................] Repeat 215 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
“LVM2 001” 是逻辑卷的名字,该asm disk很可能被做为lvm管理而被破坏
[ebernal@dbaasm tars]$ kfed read rhdisk16 kfbh.endian: 65 ; 0x000: 0x41 kfbh.hard: 73 ; 0x001: 0x49 kfbh.type: 88 ; 0x002: *** Unknown Enum *** kfbh.datfmt: 32 ; 0x003: 0x20 kfbh.block.blk: 1111709260 ; 0x004: blk=1111709260 kfbh.block.obj: 1634861056 ; 0x008: file=131072 kfbh.check: 119 ; 0x00c: 0x00000077 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 2B6FE2AC1400 20584941 4243564C 61720000 00000077 [AIX LVCB..raw...] <==== **** Here ****** 2B6FE2AC1410 00000000 00000000 00000000 00000000 [................] 2B6FE2AC1420 00000000 00000000 30300000 38306430 [..........000d08] 2B6FE2AC1430 30306131 34643030 30303030 31303030 [1a0000d400000001] 2B6FE2AC1440 61006533 766C6D73 7461645F 00003161 [3e.asmlv_data1..] 2B6FE2AC1450 00000000 00000000 00000000 00000000 [................] Repeat 2 times 2B6FE2AC1480 54000000 4D206575 20207961 31312037 [...Tue May 7 11] 2B6FE2AC1490 3A33343A 32203633 0A333130 00000000 [:43:36 2013.....] 2B6FE2AC14A0 65755400 79614D20 20372020 343A3131 [.Tue May 7 11:4] 2B6FE2AC14B0 34323A38 31303220 00000A33 44000000 [8:24 2013......D] 2B6FE2AC14C0 41313830 30303444 6D6D7900 02007900 [081AD400.ymm.y..] 2B6FE2AC14D0 0100E40C 656E6F4E 00000000 00000000 [....None........] 2B6FE2AC14E0 00000000 00000000 00000000 00000000 [................] Repeat 14 times 2B6FE2AC15D0 00000000 00000000 65310000 61653934 [..........1e49ea] 2B6FE2AC15E0 342E3862 00000000 00000000 00000000 [b8.4............] 2B6FE2AC15F0 00000000 00000000 00000000 00000000 [................] Repeat 224 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][88]
这里的“AIX LVCB..raw” 是AIX OS volume 的元数据库,也就是说,asm disk 被作为了aix os层面破坏
[oracle@dbep2 disks]$ kfed read asm-disk3 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 06000000 00000000 00000000 00000000 00000000 [................] Repeat 25 times 0602100 51e2b7f6 00ed4e00 00000000 00000001 [...Q.N..........] 0602120 00000000 0000000b 00000100 0000003c [............<...] 0602140 00000242 0000007b 5d8468e7 6147782a [B...{....h.]*xGa] 0602160 d17851a2 327552e2 00000000 00000000 [.Qx..Ru2........] 0602200 00000000 00000000 3130752f 91a4f000 [......../u01....] <==== **** Here ****** 0602220 ff8808e4 d5104cff 000000ac 00000100 [.....L..........] 0602240 00000000 00000000 00000000 09d18000 [................] Repeat 254 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][88]
这里的/u01很可能表明该asm disk被文件系统覆盖
对于asm disk的各种破坏情况,如果是normal/high冗余,那么asm dg没有问题,可以考虑通过删除异常盘,然后重新加入;如果是外部冗余遭遇到asm disk 被破坏,一般asm disk 会dismount,而且无法正常mount,如果有备份的磁盘头,可以尝试还原磁盘头,mount 磁盘组,然后只读方式迁移数据;如果没有备份磁盘头或者还原之后也无法mount,可能需要通过一些额外的方式处理比如通过工具在asm dismount状态下恢复数据文件,甚至通过对asm block/oracle block碎片重组的方式恢复数据.参考相关文章:
oracle asm系列文章汇总
pvid=yes导致asm无法mount
asm disk header 彻底损坏恢复
分区无法识别导致asm diskgroup无法mount
oracle asm disk格式化恢复—格式化为ext4文件系统
oracle asm disk格式化恢复—格式化为ntfs文件系统
asm disk误设置pvid导致asm diskgroup无法mount恢复
分享oracleasm createdisk重新创建asm disk后数据0丢失恢复案例
ORA-15042: ASM disk “N” is missing from group number “M” 故障恢复
如果您遇到此类情况,无法解决请联系我们,提供专业ORACLE数据库恢复技术支持
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
发表在 Oracle ASM, Oracle备份恢复
标签为 endian_kfbh, Invalid OSM block type, kfbtTraverseBlock, KFED-00322, ORA-15042, ORA-15196
评论关闭
通过kfed说明asm disk header定义
kfed读取数据磁盘头主要参数解释说明
% kfed read /dev/raw/raw1 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: 2932902794 ; 0x00c: 0xaed08b8a 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: 0 ; 0x024: 0x0000 kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: ASM01_0000 ; 0x028: length=10 kfdhdb.grpname: ASM01 ; 0x048: length=5 kfdhdb.fgname: ASM01_0000 ; 0x068: length=10 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 32837774 ; 0x0a8: HOUR=0xe DAYS=0x4 MNTH=0x4 YEAR=0x7d4 kfdhdb.crestmp.lo: 1555722240 ; 0x0ac: USEC=0x0 MSEC=0x29c SECS=0xb MINS=0x17 kfdhdb.mntstmp.hi: 32837774 ; 0x0b0: HOUR=0xe DAYS=0x4 MNTH=0x4 YEAR=0x7d4 kfdhdb.mntstmp.lo: 1563864064 ; 0x0b4: USEC=0x0 MSEC=0x1ab SECS=0x13 MINS=0x17 kfdhdb.secsize: 512 ; 0x0b8: 0x0200 kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000 kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80 kfdhdb.dsksize: 9075 ; 0x0c4: 0x00002373 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.ub4spare[0]: 0 ; 0x0e0: 0x00000000 ... kfdhdb.ub4spare[60]: 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 Breakdown: kfbh.endian kf3.h /* endianness of writer */ Little endian = 1 Big endian = 0 kfbh.hard kf3.h /* H.A.R.D. magic # and block size */ kfbh.type kf3.h /* metadata block type */ kfbh.datfmt kf3.h /* metadata block data format */ kfbh.block kf3.h /* block location of this block */ blk -- Disk header should have T=0 and NUMB=0x0 obj -- Disk header should have TYPE=0x8 NUMB=<disknumber> blk and obj values are derived from a series of macros in kf3.h. See "KFBL Macros" in kf3.h for more information. kfbh.check kf3.h /* check value to verify consistency */ kfbh.fcn kf3.h /* change number of last change */ kfdhdb.driver kf3.h /* OSMLIB driver reserved block */ If no driver is defined "ORCLDISK" is used. kfdhdb.compat kf3.h /* Comaptible software version */ example: 0x0a100000 You get: a=10 1=1 so 10.1.0.0.0 kfdhdb.dsknum kf3.h /* OSM disk number * This is the disk number. The first disk being "0". There can be up to ub2 disks in a diskgroup. This allows for 65336 disks 0 through 65335. kfdhdb.grptyp kf3.h /* Disk group type */ kfdhdb.hdrsts kf3.h /* Disk header status */ This is what is used to determine if a disk is available or not to the diskgroup. 0x03 is the correct value for a valid status. kfdhdb.dskname /* OSM disk name */ kfdhdb.grpname /* OSM disk group name */ kfdhdb.fgname /* Failure group name */ kfdhdb.capname /* Capacity grp, unused*/ kf3.h kfdhdb.crestmp /* Creation timestamp */ kfdhdb.mntstmp /* Mount timestamp */ kf3.h To derive the hi and low time`from an unformated dump use the "KFTS Macros" in kf3.h. kfdhdb.secsize kf3.h /* Disk sector size (bytes) */ This is the physical sector size of the disk in bytes. All I/O's to the disk are described in physical sectors. This must be a power of 2. An ideal value would be 4096, but most disks are formatted with 512 byte sectors. (from asmlib.h) kfdhdb.blksize kf3.h /* Metadata block (bytes) */ kfdhdb.ausize kf3.h /* Allocation Unit (bytes) */ kfdhdb.mfact kf3.h /* Stride between phys addr AUs */ kfdhdb.dsksize kf3.h /* Disk size in AUs */ Mulitply by AUs to get actual size of disk when added. kfdhdb.pmcnt kf3.h /* Permanent phys addressed AUs */ Number of physically addressed allocation units. kfdhdb.fstlocn kf3.h /* First FreeSpace table blk num */ Used to find freespace. kfdhdb.altlocn kf3.h /* First Alocation table blk num */ Used to find alocated space. kfdhdb.f1b1locn kf3.h /* File Directory blk 1 AU num */ Beginging for file directory.