前面一一介绍了Physically addressed metadata，现在来聊聊ASM的Virtually addressed metadata，它与Physically addressed metadata不同，虽然也是元数据，但是是以ASM文件的形式存在，由于ASM条带化的特性，所以Virtually addressed metadata是分布在磁盘组的所有磁盘上的。本小节为大家介绍的是ASM非常重要的元数据–ASM的1号文件(File Directory)，它描述了ASM磁盘中所有ASM文件(包括File Directory自身的所有。
Virtually addressed metadata）的文件大小、文件类型、冗余、条带化(粗粒度或者细粒度)以及asm文件的extent map等信息，x$kffxp的信息大量来自于File Directory。
File Directory的第一个extent所在位置由第一个extent所在的asm磁盘的磁盘头kfdhdb.f1b1locn(file 1 block 1 location)指定，通常对于External redundancy的磁盘组，在创建时默认File Directory的第一个extent都在disk 0上，其余磁盘的磁盘头kfdhdb.f1b1locn都为0，当add或者drop磁盘发生REBALANCE时，File Directory的第一个extent可能会移动到其他磁盘上。
[grid@rac1 ~]$ kfed read /dev/asmdisk-data4 |grep -E "f1b1|disk"
kfbh.block.obj: 2147483648 ; 0x008: disk=0
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
通过f1b1locn我们可以找到File Directory的block 0(KFBTYP_LISTHEAD），也是File Directory的第一个block
[grid@rac1 ~]$ kfed read /dev/asmdisk-data4 aun=2|grep type
kfbh.type: 5 ; 0x002: KFBTYP_LISTHEAD
[grid@rac1 ~]$ kfed read /dev/asmdisk-data4 aun=2 blkn=1
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 1 ; 0x004: blk=1
kfbh.block.obj: 1 ; 0x008: file=1
kfbh.check: 4210451282 ; 0x00c: 0xfaf66352
kfbh.fcn.base: 443 ; 0x010: 0x000001bb
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: 2097152 ; 0x010: 0x00200000
kfffdb.xtntcnt: 2 ; 0x014: 0x00000002
kfffdb.xtnteof: 2 ; 0x018: 0x00000002
kfffdb.blkSize: 4096 ; 0x01c: 0x00001000
kfffdb.flags: 1 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=0 A=0
kfffdb.fileType: 15 ; 0x021: 0x0f
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000
kfffdb.xtntblk: 2 ; 0x03c: 0x0002
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: KFDZN_COLD
kfffdb.secZn: 0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 4294967295 ; 0x044: 0xffffffff
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 0 ; 0x04c: 0x00
kfffdb.strpsz: 0 ; 0x04d: 0x00
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 33115693 ; 0x050: HOUR=0xd DAYS=0x11 MNTH=0x3 YEAR=0x7e5
kfffdb.crets.lo: 2730023936 ; 0x054: USEC=0x0 MSEC=0x237 SECS=0x2b MINS=0x28
kfffdb.modts.hi: 33115693 ; 0x058: HOUR=0xd DAYS=0x11 MNTH=0x3 YEAR=0x7e5
kfffdb.modts.lo: 2730023936 ; 0x05c: USEC=0x0 MSEC=0x237 SECS=0x2b MINS=0x28
kfffdb.dasz[0]: 0 ; 0x060: 0x00
kfffdb.dasz[1]: 0 ; 0x061: 0x00
kfffdb.dasz[2]: 0 ; 0x062: 0x00
kfffdb.dasz[3]: 0 ; 0x063: 0x00
kfffdb.permissn: 0 ; 0x064: 0x00
kfffdb.ub1spar1: 0 ; 0x065: 0x00
kfffdb.ub2spar2: 0 ; 0x066: 0x0000
kfffdb.user.entnum: 0 ; 0x068: 0x0000
kfffdb.user.entinc: 0 ; 0x06a: 0x0000
kfffdb.group.entnum: 0 ; 0x06c: 0x0000
kfffdb.group.entinc: 0 ; 0x06e: 0x0000
kfffdb.spare[0]: 0 ; 0x070: 0x00000000
kfffdb.spare[1]: 0 ; 0x074: 0x00000000
kfffdb.spare[2]: 0 ; 0x078: 0x00000000
kfffdb.spare[3]: 0 ; 0x07c: 0x00000000
kfffdb.spare[4]: 0 ; 0x080: 0x00000000
kfffdb.spare[5]: 0 ; 0x084: 0x00000000
kfffdb.spare[6]: 0 ; 0x088: 0x00000000
kfffdb.spare[7]: 0 ; 0x08c: 0x00000000
kfffdb.spare[8]: 0 ; 0x090: 0x00000000
kfffdb.spare[9]: 0 ; 0x094: 0x00000000
kfffdb.spare[10]: 0 ; 0x098: 0x00000000
kfffdb.spare[11]: 0 ; 0x09c: 0x00000000
kfffdb.usm: ; 0x0a0: length=0
kfffde[0].xptr.au: 2 ; 0x4a0: 0x00000002
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 40 ; 0x4a7: 0x28
kfffde[1].xptr.au: 21 ; 0x4a8: 0x00000015
kfffde[1].xptr.disk: 2 ; 0x4ac: 0x0002
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 61 ; 0x4af: 0x3d
- block_kfbh.obj：asm文件号
- block_kfbh.blk：位于该asm文件的块号，对于File Directory(1号文件)来说block_kfbh.blk也代表ASM文件号，表示这个元数据块是该asm文件号的File Directory
- kfffdb.node.incarn：文件的incarnation号
- kfffdb.hibytes：文件大小(high bytes)
- kfffdb.lobytes：文件大小(low bytes)
- kfffdb.xtntcnt：文件的物理extent数量
- kfffdb.flags: 文件标识
O - File is original, not snapshot
S - File is striped
S - Strict allocation policy
D - File is damaged
C - File creation is committed
I - File has empty indirect block
R - File has known at-risk value
A - The at-risk value itsefl- kfffdb.fileType：文件类型
| index | filetype |
| 1 | control file |
| 2 | data file |
| 3 | on-line log |
| 4 | archived log |
| 6 | temporary file |
| 8 | any other type |
| 9 | datafile backup piece |
| 10 | datafile incremental backup piece |
| 11 | archivelog backup piece |
| 12 | datafile copy |
| 13 | Persistent Initialization Parameter |
| 14 | Disaster Recovery Configuration |
| 15 | ASM metadata file |
| 16 | Change Tracking File |
| 17 | Flashback Log File |
| 18 | data pump dump file |
| 19 | Cross platform Converted datafile |
| 20 | Autobackup |
| 21 | any Operating System file |
| 22 | Block Dump File – should not have OSD block header |
| 23 | Cluster Synchronization Services voting file |
| 24 | Oracle Cluster Registry file |
| 25 | ASM Staleness Registry |
| 26 | ASM Volume Device file |
| 27 | ASM Volume Dirty Region Log file |
| 28 | Password file |
| 29 | ADR AMS relation file |
| 30 | Oracle Cluster Registry backup file |
| 31 | ASM spfile type |
| 32 | Flash file type |
| 33 | ASM spfile backup type |
| 34 | External Table I/O |
| 35 | datafile xtt backup piece |
| 36 | Spillover OS Audit file |
| 37 | datafile xtt inc backup piece |
| 38 | AKM KeyStore I/O |
| 39 | AKM AutoLogin KeyStore I/O |
| 40 | ORS block pool |
| 41 | SQL LOADER file type |
| 42 | availability machine container |
- kfffdb.blkSize：文件的块大小，如默认数据文件块大小8k，控制文件16k等等
- kfffdb.strpwdth：条带带宽
- kfffdb.strpsz：条带大小
- kfffdb.crets：文件创建时间(hi为高位，lo为低位)
- kfffdb.modts：文件修改时间(hi为高位，lo为地位)
- kfffdb.xtntblk:Direct extent条目数加上indirect extent条目数
- kfffdb.break: Direct extent和indirect extent分界线，前60个条目为Direct extent，61开始都为indirect extent
- kfffde[0-59]：前60个File Directory条目直接指向文件的物理extent所在位置，称为Direct extent pointer，kfffde[n].xptr表示指向该文件第n个物理extent的extent pointer
kfffde[0].xptr.au: 22 ; 0x4a0: 0x00000016 文件0号物理extent所在au号
kfffde[0].xptr.disk: 2 ; 0x4a4: 0x0002 文件0号物理extent所在磁盘号
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk: 62 ; 0x4a7: 0x3e
...
kfffde[59].xptr.au: 41 ; 0x678: 0x00000029 文件59号物理extent所在au号
kfffde[59].xptr.disk: 0 ; 0x67c: 0x0000 文件59号物理extent所在磁盘号
kfffde[59].xptr.flags: 0 ; 0x67e: L=0 E=0 D=0 S=0
kfffde[59].xptr.chk: 3 ; 0x67f: 0x03
- kfffde[60+]：60以后的File Directory条目指向一个名为Indirect的元数据，再由Indirect block里的Directory条目(kffixe)指向文件的物理extent所在位置，称为Indirect extent pointer，一个Indirect block可以容纳480个指向物理extent所在位置的条目，kffixe[n].xptr表示指向该文件第(60+kfbh.block.blk*480+n）个物理extent的extent pointer
[grid@rac1 ~]$ kfed read /dev/asmdisk-data6 aun=21 |grep -E "kfffde\[60"
kfffde[60].xptr.au: 39 ; 0x680: 0x00000027 文件第一个Indirect extent所在au
kfffde[60].xptr.disk: 1 ; 0x684: 0x0001 文件第一个Indirect extent所在磁盘
kfffde[60].xptr.flags: 0 ; 0x686: L=0 E=0 D=0 S=0
kfffde[60].xptr.chk: 12 ; 0x687: 0x0c
[grid@rac1 ~]$ kfed read /dev/asmdisk-data5 aun=39 |grep "kffixe"|grep xptr.au|wc -l
480
[grid@rac1 ~]$ kfed read /dev/asmdisk-data5 aun=39
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 12 ; 0x002: KFBTYP_INDIRECT
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 2147483648 ; 0x004: blk=0 (indirect)
kfbh.block.obj: 256 ; 0x008: file=256
kfbh.check: 2166194492 ; 0x00c: 0x811d813c
kfbh.fcn.base: 993 ; 0x010: 0x000003e1
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kffixb.dxsn: 60 ; 0x000: 0x0000003c
kffixb.xtntblk: 480 ; 0x004: 0x01e0
kffixb.dXrs: 17 ; 0x006: SCHE=0x1 NUMB=0x1
kffixb.ub1spare: 0 ; 0x007: 0x00
kffixb.ub4spare: 0 ; 0x008: 0x00000000
kffixe[0].xptr.au: 42 ; 0x00c: 0x0000002a --文件第60号物理extent所在au
kffixe[0].xptr.disk: 2 ; 0x010: 0x0002 --文件第60号物理extent所在磁盘
kffixe[0].xptr.flags: 0 ; 0x012: L=0 E=0 D=0 S=0
kffixe[0].xptr.chk: 2 ; 0x013: 0x02
...
kffixe[479].xptr.au: 201 ; 0xf04: 0x000000c9 --文件第539号物理extent所在au
kffixe[479].xptr.disk: 0 ; 0xf08: 0x0000 --文件第539号物理extent所在磁盘
kffixe[479].xptr.flags: 0 ; 0xf0a: L=0 E=0 D=0 S=0
kffixe[479].xptr.chk: 227 ; 0xf0b: 0xe3
当ASM磁盘组无法mount时，如果需要通过amdu抽取文件的话，就非常依赖于file directory和at，如果这些元数据有损坏将无法通过amdu进行抽取。但是可以通过odu进行抽取。
发表回复