在前面几篇文章中我分别详细剖析了disk header、free space table、pst以及disk directory等元数据结构，这一篇文章
将重点剖析另外一个重要的asm元数据结构，那就是file directory，这是跟我们database datafile关联最为紧密的一个
asm元数据结构，首先我们还是来使用kfed工具进行读取file directory的信息。
通过读取disk header，可以发现file directory信息位于第2个AU中。
下面继续使用该工具读取相关信息，如下：
从上面数据可以看出，file directory元数据结构分为3个部分：
1) kfbh ，头部信息，这部分信息跟前面其他几篇文章讲述的内容类似，这里不重复累述。
2) kfffdb、主要包括文件分配信息。下面针对部分关键信息进行说明：
3) kfffde,这里主要是数据文件所分配au的具体信息，如下：
到这里，基本上file directory的结构信息，我们描述的比较清楚了，大家可以发现，这其实非常简单。那么，到最后自然
也就出现了一个问题，比如我这里的某个datafile，存于asm中，我怎么知道它所占据的au位置呢?具体在asm diskgroup中的
什么地方呢？在这里，我用一个datafile来进行展示：
关于该试图的一些说明，网上也有很多文章，我这里不过多描述，我这里主要是想让大家明白，假如我们的asm 磁盘组都无法mount，
那么你怎么去定位呢？因为这是你无法使用该x$试图进行查询。其实很简单，前面我已经详细描述了file directory的结构，我们
我们轻易的定位到数据库中任何一个datafile的具体位置。
我这里仍然以上面的datafile 5为例，首先通过该datafile的名称，我们知道该datafile对应的asm 的文件号是266. 如果你无法从
数据库实例v$datafile或dba_data_files等试图得知，那么你可以查询v$asm_alias试图,如下：
当然，如果当你的asm磁盘组都无法mount时，你可以直接从asm alias元数据中获得相关的asm文件号，这也是下一篇文章将要描述的内容。
回到主题上来，当我们知道该datafile 5对应的asm文件号是266后，那么下一步怎么办呢？
我们在前面已经知道file directory信息存在在第2个au中，而我们也知道第2个au是从256开始，那么我们的266文件的信息就应该
在266-256 这个block中，换句话讲，file 266的au分配信息应该就在au 2，block 10中，我们来看看是不是这样：
到这里，你甚至通过dd命令将这21个au copy出来，组合在一起。在前面我也写过类似的文章。
最后大家看到这里，或许会有个疑问，那就是我这里的datafile 5明明是20m，为什么看到的au分配却是21个呢？
怎么多了1m ？
这其实是因为datafile header的原因，由于数据文件头也需要占据1个block，我这里是8k，而asm最小的分配单位是au,
也就是必须再多分配1个au出来，所以你看到的就是21个au，即21m.
补充：那么在11g中，不同au的情况下，如何找到某个数据文件的具体au分配位置呢？
首先定位到disk file directory：
第一个au link里面的信息是存放元数据，那么该datafile的au分配信息应该就在第2个link au里面，而我这里
au大小是8m，而asm block是4096，那么也就是说每个au可以存放2048个block，所以我直接读取第256个block：
可以看到，我们的datafile 是30m，这里asm分配了4个au，每个au 8m，即是32m.
将重点剖析另外一个重要的asm元数据结构，那就是file directory，这是跟我们database datafile关联最为紧密的一个
asm元数据结构，首先我们还是来使用kfed工具进行读取file directory的信息。
---读取disk header
[oracle@10gasm ~]$ kfed read /dev/sdd |grep f1
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
通过读取disk header，可以发现file directory信息位于第2个AU中。
下面继续使用该工具读取相关信息，如下：
[oracle@10gasm ~]$ kfed read /dev/sdd aun=2 blkn=1|more
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: T=0 NUMB=0x1
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.check: 3992348944 ; 0x00c: 0xedf66910
kfbh.fcn.base: 2990 ; 0x010: 0x00000bae
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: 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: 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: 0x00
kfffdb.secZn: 0 ; 0x041: 0x00
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: 32977478 ; 0x050: HOUR=0x6 DAYS=0x12 MNTH=0xc YEAR=0x7dc
kfffdb.crets.lo: 2407343104 ; 0x054: USEC=0x0 MSEC=0x349 SECS=0x37 MINS=0x23
kfffdb.modts.hi: 32977478 ; 0x058: HOUR=0x6 DAYS=0x12 MNTH=0xc YEAR=0x7dc
kfffdb.modts.lo: 2407343104 ; 0x05c: USEC=0x0 MSEC=0x349 SECS=0x37 MINS=0x23
kfffdb.spare[0]: 0 ; 0x060: 0x00000000
........
kfffdb.spare[14]: 0 ; 0x098: 0x00000000
kfffdb.spare[15]: 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 C=0 S=0
kfffde[0].xptr.chk: 40 ; 0x4a7: 0x28
kfffde[1].xptr.au: 2 ; 0x4a8: 0x00000002
kfffde[1].xptr.disk: 2 ; 0x4ac: 0x0002
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 C=0 S=0
kfffde[1].xptr.chk: 42 ; 0x4af: 0x2a
kfffde[2].xptr.au: 4294967295 ; 0x4b0: 0xffffffff
..........
从上面数据可以看出，file directory元数据结构分为3个部分：
1) kfbh ，头部信息，这部分信息跟前面其他几篇文章讲述的内容类似，这里不重复累述。
2) kfffdb、主要包括文件分配信息。下面针对部分关键信息进行说明：
kfffdb.node.incarn: 1 ; 0x000: A=1 NUMM=0x0 ---File incarnation information
kfffdb.hibytes: 0 ; 0x00c: 0x00000000 ---文件大小(高位),单位byte
kfffdb.lobytes: 2097152 ; 0x010: 0x00200000 ---文件大小(地位),单位byte
kfffdb.xtntcnt: 2 ; 0x014: 0x00000002 ---该文件分配的extent个数,这里是2，表示该文件大小是2m。
kfffdb.xtnteof: 2 ; 0x018: 0x00000002
kfffdb.blkSize: 4096 ; 0x01c: 0x00001000 ---标准asm 块大小
kfffdb.flags: 65 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=1 A=0 --flag标示
---flag定义如下：
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: 15 ; 0x021: 0x0f ---15描述问asm元数据，其中12表示数据文件，3表示redo文件
kfffdb.dXrs: 17 ; 0x022: SCHE=0x1 NUMB=0x1 ---direct extent redundancy scheme
kfffdb.iXrs: 17 ; 0x023: SCHE=0x1 NUMB=0x1 ---indirect extent redundancy scheme
kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff ---of direct extents of each size(目前该值表示没有冗余)
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 ---Total number of dir + indir extents in this block
kfffdb.break: 60 ; 0x03e: 0x003c ---Direct/indirect boundary index
kfffdb.priZn: 0 ; 0x040: 0x00 ---Primary extent allocation zone
kfffdb.secZn: 0 ; 0x041: 0x00 ---Secondary extent allocation zone (因为我这里没有冗余，所以均为0)
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: 32977478 ; 0x050: HOUR=0x6 DAYS=0x12 MNTH=0xc YEAR=0x7dc
kfffdb.crets.lo: 2407343104 ; 0x054: USEC=0x0 MSEC=0x349 SECS=0x37 MINS=0x23 --文件创建时间(高低位组合换算集合起来即可)
kfffdb.modts.hi: 32977478 ; 0x058: HOUR=0x6 DAYS=0x12 MNTH=0xc YEAR=0x7dc
kfffdb.modts.lo: 2407343104 ; 0x05c: USEC=0x0 MSEC=0x349 SECS=0x37 MINS=0x23 --文件修改时间(高低位组合换算集合起来即可)
kfffdb.spare[0]: 0 ; 0x060: 0x00000000
........
kfffdb.spare[15]: 0 ; 0x09c: 0x00000000
3) kfffde,这里主要是数据文件所分配au的具体信息，如下：
kfffde[0].xptr.au: 2 ; 0x4a0: 0x00000002 --第一个au指针
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000 --该au所在的disk编号
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 C=0 S=0
kfffde[0].xptr.chk: 40 ; 0x4a7: 0x28
kfffde[1].xptr.au: 2 ; 0x4a8: 0x00000002 --第2个au指针
kfffde[1].xptr.disk: 2 ; 0x4ac: 0x0002 --该au所在的disk编号
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 C=0 S=0
kfffde[1].xptr.chk: 42 ; 0x4af: 0x2a
kfffde[2].xptr.au: 4294967295 ; 0x4b0: 0xffffffff --表示后面没有指针
到这里，基本上file directory的结构信息，我们描述的比较清楚了，大家可以发现，这其实非常简单。那么，到最后自然
也就出现了一个问题，比如我这里的某个datafile，存于asm中，我怎么知道它所占据的au位置呢?具体在asm diskgroup中的
什么地方呢？在这里，我用一个datafile来进行展示：
SQL> select file#,name,bytes/1024/1024 from v$datafile order by 1;
FILE# NAME BYTES/1024/1024
---------- ------------------------------------------------- ---------------
1 +DATA1/test/datafile/system.256.802678453 480
2 +DATA1/test/datafile/undotbs1.258.802678457 25
3 +DATA1/test/datafile/sysaux.257.802678455 250
4 +DATA1/test/datafile/users.259.802678457 5
5 +DATA1/test/datafile/roger.266.804210969 20
例如，上面我这里的file 5，一共是20m大小，那么我如何知道它这20m空间都位于asm disk中的什么位置呢？有人会说可以通过
x$kffxp直接进行查询，是的，我们是可以通过该试图直接进行查询，如下：
SQL> select disk_kffxp, AU_kffxp, xnum_kffxp
2 from x$kffxp
3 where group_kffxp=1
4 and number_kffxp=266 order by 2;
DISK_KFFXP AU_KFFXP XNUM_KFFXP
---------- ---------- ----------
3 252 1
3 253 6
3 254 10
3 255 14
3 256 18
2 336 2
2 337 5
2 338 8
2 339 11
2 341 17
2 342 20
1 429 19
0 431 15
1 432 16
0 434 12
1 435 13
0 437 9
1 441 7
0 443 3
1 444 4
0 446 0
21 rows selected.
SQL>
关于该试图的一些说明，网上也有很多文章，我这里不过多描述，我这里主要是想让大家明白，假如我们的asm 磁盘组都无法mount，
那么你怎么去定位呢？因为这是你无法使用该x$试图进行查询。其实很简单，前面我已经详细描述了file directory的结构，我们
我们轻易的定位到数据库中任何一个datafile的具体位置。
我这里仍然以上面的datafile 5为例，首先通过该datafile的名称，我们知道该datafile对应的asm 的文件号是266. 如果你无法从
数据库实例v$datafile或dba_data_files等试图得知，那么你可以查询v$asm_alias试图,如下：
SQL> l
1* select FILE_NUMBER,name from v$asm_alias order by 1
SQL> /
FILE_NUMBER NAME
----------- ------------------------------------------------
256 SYSTEM.256.802678453
257 SYSAUX.257.802678455
258 UNDOTBS1.258.802678457
259 USERS.259.802678457
260 Current.260.802678553
261 group_1.261.802678553
262 group_2.262.802678555
263 group_3.263.802678557
264 TEMP.264.802678569
265 spfile.265.802678613
265 spfiletest.ora
266 ROGER.266.804210969
4294967295 DATAFILE
4294967295 TEMPFILE
4294967295 TEST
4294967295 PARAMETERFILE
4294967295 CONTROLFILE
4294967295 ONLINELOG
18 rows selected.
当然，如果当你的asm磁盘组都无法mount时，你可以直接从asm alias元数据中获得相关的asm文件号，这也是下一篇文章将要描述的内容。
回到主题上来，当我们知道该datafile 5对应的asm文件号是266后，那么下一步怎么办呢？
我们在前面已经知道file directory信息存在在第2个au中，而我们也知道第2个au是从256开始，那么我们的266文件的信息就应该
在266-256 这个block中，换句话讲，file 266的au分配信息应该就在au 2，block 10中，我们来看看是不是这样：
[oracle@10gasm ~]$ kfed read /dev/sdb aun=2 blkn=10|more --说明，前面kfffde[1].xptr.disk 是2，说明是在第2个disk，我这里2个disk是/dev/sdb。
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 266 ; 0x004: T=0 NUMB=0x10a ---大家可以看到，果然是266号文件。
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1
kfbh.check: 669502081 ; 0x00c: 0x27e7ca81
kfbh.fcn.base: 3006 ; 0x010: 0x00000bbe
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 804210969 ; 0x000: A=1 NUMM=0x17f7a48c
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 20979712 ; 0x010: 0x01402000
kfffdb.xtntcnt: 21 ; 0x014: 0x00000015
kfffdb.xtnteof: 21 ; 0x018: 0x00000015
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 81 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=1 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
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: 21 ; 0x03c: 0x0015
kfffdb.break: 60 ; 0x03e: 0x003c
kfffdb.priZn: 0 ; 0x040: 0x00
kfffdb.secZn: 0 ; 0x041: 0x00
kfffdb.ub2spare: 0 ; 0x042: 0x0000
kfffdb.alias[0]: 110 ; 0x044: 0x0000006e
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 20 ; 0x04d: 0x14 --条带宽度20，也就是该文件实际大小是20m。
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32982295 ; 0x050: HOUR=0x17 DAYS=0x8 MNTH=0x1 YEAR=0x7dd
kfffdb.crets.lo: 3768458240 ; 0x054: USEC=0x0 MSEC=0x387 SECS=0x9 MINS=0x38
kfffdb.modts.hi: 32982295 ; 0x058: HOUR=0x17 DAYS=0x8 MNTH=0x1 YEAR=0x7dd
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
kfffdb.spare[0]: 0 ; 0x060: 0x00000000
........
kfffdb.spare[15]: 0 ; 0x09c: 0x00000000
kfffdb.usm: ; 0x0a0: length=0
kfffde[0].xptr.au: 446 ; 0x4a0: 0x000001be --该文件的第1个au
kfffde[0].xptr.disk: 0 ; 0x4a4: 0x0000 --表示该au在第0个disk中
kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 C=0 S=0
kfffde[0].xptr.chk: 149 ; 0x4a7: 0x95
kfffde[1].xptr.au: 252 ; 0x4a8: 0x000000fc
kfffde[1].xptr.disk: 3 ; 0x4ac: 0x0003
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 C=0 S=0
kfffde[1].xptr.chk: 213 ; 0x4af: 0xd5
kfffde[2].xptr.au: 336 ; 0x4b0: 0x00000150
kfffde[2].xptr.disk: 2 ; 0x4b4: 0x0002
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 C=0 S=0
kfffde[2].xptr.chk: 121 ; 0x4b7: 0x79
kfffde[3].xptr.au: 443 ; 0x4b8: 0x000001bb
kfffde[3].xptr.disk: 0 ; 0x4bc: 0x0000
kfffde[3].xptr.flags: 0 ; 0x4be: L=0 E=0 D=0 C=0 S=0
kfffde[3].xptr.chk: 144 ; 0x4bf: 0x90
kfffde[4].xptr.au: 444 ; 0x4c0: 0x000001bc
kfffde[4].xptr.disk: 1 ; 0x4c4: 0x0001
kfffde[4].xptr.flags: 0 ; 0x4c6: L=0 E=0 D=0 C=0 S=0
kfffde[4].xptr.chk: 150 ; 0x4c7: 0x96
kfffde[5].xptr.au: 337 ; 0x4c8: 0x00000151
kfffde[5].xptr.disk: 2 ; 0x4cc: 0x0002
kfffde[5].xptr.flags: 0 ; 0x4ce: L=0 E=0 D=0 C=0 S=0
kfffde[5].xptr.chk: 120 ; 0x4cf: 0x78
kfffde[6].xptr.au: 253 ; 0x4d0: 0x000000fd
kfffde[6].xptr.disk: 3 ; 0x4d4: 0x0003
kfffde[6].xptr.flags: 0 ; 0x4d6: L=0 E=0 D=0 C=0 S=0
kfffde[6].xptr.chk: 212 ; 0x4d7: 0xd4
kfffde[7].xptr.au: 441 ; 0x4d8: 0x000001b9
kfffde[7].xptr.disk: 1 ; 0x4dc: 0x0001
kfffde[7].xptr.flags: 0 ; 0x4de: L=0 E=0 D=0 C=0 S=0
kfffde[7].xptr.chk: 147 ; 0x4df: 0x93
kfffde[8].xptr.au: 338 ; 0x4e0: 0x00000152
kfffde[8].xptr.disk: 2 ; 0x4e4: 0x0002
kfffde[8].xptr.flags: 0 ; 0x4e6: L=0 E=0 D=0 C=0 S=0
kfffde[8].xptr.chk: 123 ; 0x4e7: 0x7b
kfffde[9].xptr.au: 437 ; 0x4e8: 0x000001b5
kfffde[9].xptr.disk: 0 ; 0x4ec: 0x0000
kfffde[9].xptr.flags: 0 ; 0x4ee: L=0 E=0 D=0 C=0 S=0
kfffde[9].xptr.chk: 158 ; 0x4ef: 0x9e
kfffde[10].xptr.au: 254 ; 0x4f0: 0x000000fe
kfffde[10].xptr.disk: 3 ; 0x4f4: 0x0003
kfffde[10].xptr.flags: 0 ; 0x4f6: L=0 E=0 D=0 C=0 S=0
kfffde[10].xptr.chk: 215 ; 0x4f7: 0xd7
kfffde[11].xptr.au: 339 ; 0x4f8: 0x00000153
kfffde[11].xptr.disk: 2 ; 0x4fc: 0x0002
kfffde[11].xptr.flags: 0 ; 0x4fe: L=0 E=0 D=0 C=0 S=0
kfffde[11].xptr.chk: 122 ; 0x4ff: 0x7a
kfffde[12].xptr.au: 434 ; 0x500: 0x000001b2
kfffde[12].xptr.disk: 0 ; 0x504: 0x0000
kfffde[12].xptr.flags: 0 ; 0x506: L=0 E=0 D=0 C=0 S=0
kfffde[12].xptr.chk: 153 ; 0x507: 0x99
kfffde[13].xptr.au: 435 ; 0x508: 0x000001b3
kfffde[13].xptr.disk: 1 ; 0x50c: 0x0001
kfffde[13].xptr.flags: 0 ; 0x50e: L=0 E=0 D=0 C=0 S=0
kfffde[13].xptr.chk: 153 ; 0x50f: 0x99
kfffde[14].xptr.au: 255 ; 0x510: 0x000000ff
kfffde[14].xptr.disk: 3 ; 0x514: 0x0003
kfffde[14].xptr.flags: 0 ; 0x516: L=0 E=0 D=0 C=0 S=0
kfffde[14].xptr.chk: 214 ; 0x517: 0xd6
kfffde[15].xptr.au: 431 ; 0x518: 0x000001af
kfffde[15].xptr.disk: 0 ; 0x51c: 0x0000
kfffde[15].xptr.flags: 0 ; 0x51e: L=0 E=0 D=0 C=0 S=0
kfffde[15].xptr.chk: 132 ; 0x51f: 0x84
kfffde[16].xptr.au: 432 ; 0x520: 0x000001b0
kfffde[16].xptr.disk: 1 ; 0x524: 0x0001
kfffde[16].xptr.flags: 0 ; 0x526: L=0 E=0 D=0 C=0 S=0
kfffde[16].xptr.chk: 154 ; 0x527: 0x9a
kfffde[17].xptr.au: 341 ; 0x528: 0x00000155
kfffde[17].xptr.disk: 2 ; 0x52c: 0x0002
kfffde[17].xptr.flags: 0 ; 0x52e: L=0 E=0 D=0 C=0 S=0
kfffde[17].xptr.chk: 124 ; 0x52f: 0x7c
kfffde[18].xptr.au: 256 ; 0x530: 0x00000100
kfffde[18].xptr.disk: 3 ; 0x534: 0x0003
kfffde[18].xptr.flags: 0 ; 0x536: L=0 E=0 D=0 C=0 S=0
kfffde[18].xptr.chk: 40 ; 0x537: 0x28
kfffde[19].xptr.au: 429 ; 0x538: 0x000001ad
kfffde[19].xptr.disk: 1 ; 0x53c: 0x0001
kfffde[19].xptr.flags: 0 ; 0x53e: L=0 E=0 D=0 C=0 S=0
kfffde[19].xptr.chk: 135 ; 0x53f: 0x87
kfffde[20].xptr.au: 342 ; 0x540: 0x00000156
kfffde[20].xptr.disk: 2 ; 0x544: 0x0002
kfffde[20].xptr.flags: 0 ; 0x546: L=0 E=0 D=0 C=0 S=0
kfffde[20].xptr.chk: 127 ; 0x547: 0x7f
kfffde[21].xptr.au: 4294967295 ; 0x548: 0xffffffff
kfffde[21].xptr.disk: 65535 ; 0x54c: 0xffff
kfffde[21].xptr.flags: 0 ; 0x54e: L=0 E=0 D=0 C=0 S=0
kfffde[21].xptr.chk: 42 ; 0x54f: 0x2a
到这里，你甚至通过dd命令将这21个au copy出来，组合在一起。在前面我也写过类似的文章。
最后大家看到这里，或许会有个疑问，那就是我这里的datafile 5明明是20m，为什么看到的au分配却是21个呢？
怎么多了1m ？
这其实是因为datafile header的原因，由于数据文件头也需要占据1个block，我这里是8k，而asm最小的分配单位是au,
也就是必须再多分配1个au出来，所以你看到的就是21个au，即21m.
补充：那么在11g中，不同au的情况下，如何找到某个数据文件的具体au分配位置呢？
---database instance
SQL> select * from V$version where rownum < 3;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production
PL/SQL Release 11.2.0.2.0 - Production
SQL> select file#,name ,bytes/1024/1024 from V$datafile order by 1;
FILE# NAME BYTES/1024/1024
---------- ------------------------------------------------------------ ---------------
1 +DATA1/roger/system01.dbf 720
2 +DATA1/roger/sysaux01.dbf 600
3 +DATA2/roger/datafile/test.256.792394777 30
4 +DATA1/roger/users01.dbf 1876.25
5 +DATA1/roger/roger01.dbf 500
6 +DATA1/roger/undotbs.dbf 20
6 rows selected.
---asm instance
SQL> SELECT
2 name group_name
3 , sector_size sector_size
4 , block_size block_size
5 , allocation_unit_size allocation_unit_size
6 , state state
7 , type type
8 , total_mb total_mb
9 , (total_mb - free_mb) used_mb
10 , ROUND((1- (free_mb / total_mb))*100, 2) pct_used
11 FROM
12 v$asm_diskgroup
13 ORDER BY
14 name
15 /
Disk Group Sector Block Allocation
Name Size Size Unit Size State Type Total Size (MB) Used Size (MB) Pct. Used
-------------------- ------- ------- ------------ ----------- ------ --------------- -------------- ---------
DATA1 512 4,096 1,048,576 MOUNTED EXTERN 6,144 4,095 66.65
DATA2 512 4,096 8,388,608 MOUNTED EXTERN 2,048 200 9.77
--------------- --------------
Grand Total: 8,192 4,295
SQL> SELECT
2 NVL(a.name, '[CANDIDATE]') disk_group_name
3 , b.path disk_file_path
4 , b.name disk_file_name
5 , b.failgroup disk_file_fail_group
6 , b.total_mb total_mb
7 , (b.total_mb - b.free_mb) used_mb
8 , ROUND((1- (b.free_mb / b.total_mb))*100, 2) pct_used
9 FROM
10 v$asm_diskgroup a RIGHT OUTER JOIN v$asm_disk b USING (group_number)
11 ORDER BY
12 a.name
13 /
Disk Group Name Path File Name Fail Group File Size (MB) Used Size (MB) Pct. Used
-------------------- ----------------- -------------------- -------------------- -------------- -------------- ---------
DATA1 /dev/sdc DATA1_0003 DATA1_0003 2,048 1,365 66.65
/dev/sdd DATA1_0000 DATA1_0000 4,096 2,730 66.65
******************** -------------- --------------
6,144 4,095
DATA2 /dev/sdb DATA2_0000 DATA2_0000 2,048 200 9.77
******************** -------------- --------------
2,048 200
-------------- --------------
Grand Total: 8,192 4,295
首先定位到disk file directory：
[ora11g@11gR2test ~]$ kfed read /dev/sdb |grep f1
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
[ora11g@11gR2test ~]$
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=2 blkn=1 | 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: 513 ; 0x004: T=0 NUMB=0x201
kfbh.block.obj: 2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check: 2948726368 ; 0x00c: 0xafc1fe60
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdatb10.aunum: 228928 ; 0x000: 0x00037e40
kfdatb10.shrink: 0 ; 0x004: 0x0000
kfdatb10.ub2pad: 12001 ; 0x006: 0x2ee1
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: 0 ; 0x00e: 0x0000
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
kfdatb10.auinfo[3].free: 0 ; 0x024: 0x0000
kfdatb10.auinfo[3].total: 0 ; 0x026: 0x0000
kfdate[0].discriminator: 1 ; 0x028: 0x00000001
kfdate[0].allo.lo: 0 ; 0x028: XNUM=0x0
kfdate[0].allo.hi: 9437183 ; 0x02c: V=1 I=0 H=0 FNUM=0xfffff
kfdate[1].discriminator: 1 ; 0x030: 0x00000001
kfdate[1].allo.lo: 0 ; 0x030: XNUM=0x0
........
第一个au link里面的信息是存放元数据，那么该datafile的au分配信息应该就在第2个link au里面，而我这里
au大小是8m，而asm block是4096，那么也就是说每个au可以存放2048个block，所以我直接读取第256个block：
[ora11g@11gR2test ~]$ kfed read /dev/sdb aun=16 blkn=256 | more
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj: 1 ; 0x008: TYPE=0x0 NUMB=0x1\rkfbh.check: 3166381195 ; 0x00c: 0xbcbb248b
kfbh.fcn.base: 177 ; 0x010: 0x000000b1
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfffdb.node.incarn: 792394777 ; 0x000: A=1 NUMM=0x179d7e0c
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes: 0 ; 0x00c: 0x00000000
kfffdb.lobytes: 31465472 ; 0x010: 0x01e02000
kfffdb.xtntcnt: 4 ; 0x014: 0x00000004
kfffdb.xtnteof: 4 ; 0x018: 0x00000004
kfffdb.blkSize: 8192 ; 0x01c: 0x00002000
kfffdb.flags: 17 ; 0x020: O=1 S=0 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType: 2 ; 0x021: 0x02
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: 4 ; 0x03c: 0x0004
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]: 106 ; 0x044: 0x0000006a
kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth: 1 ; 0x04c: 0x01
kfffdb.strpsz: 23 ; 0x04d: 0x17
kfffdb.usmsz: 0 ; 0x04e: 0x0000
kfffdb.crets.hi: 32973669 ; 0x050: HOUR=0x5 DAYS=0x1b MNTH=0x8 YEAR=0x7dc
kfffdb.crets.lo: 2655528960 ; 0x054: USEC=0x0 MSEC=0x20a SECS=0x24 MINS=0x27
kfffdb.modts.hi: 32982308 ; 0x058: HOUR=0x4 DAYS=0x9 MNTH=0x1 YEAR=0x7dd
kfffdb.modts.lo: 0 ; 0x05c: USEC=0x0 MSEC=0x0 SECS=0x0 MINS=0x0
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[11]: 0 ; 0x09c: 0x00000000
kfffdb.usm: ; 0x0a0: length=0
kfffde[0].xptr.au: 13 ; 0x4a0: 0x0000000d
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: 39 ; 0x4a7: 0x27
kfffde[1].xptr.au: 14 ; 0x4a8: 0x0000000e
kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000
kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk: 36 ; 0x4af: 0x24
kfffde[2].xptr.au: 15 ; 0x4b0: 0x0000000f
kfffde[2].xptr.disk: 0 ; 0x4b4: 0x0000
kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk: 37 ; 0x4b7: 0x25
kfffde[3].xptr.au: 16 ; 0x4b8: 0x00000010
kfffde[3].xptr.disk: 0 ; 0x4bc: 0x0000
kfffde[3].xptr.flags: 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk: 58 ; 0x4bf: 0x3a
kfffde[4].xptr.au: 4294967295 ; 0x4c0: 0xffffffff
kfffde[4].xptr.disk: 65535 ; 0x4c4: 0xffff
kfffde[4].xptr.flags: 0 ; 0x4c6: L=0 E=0 D=0 S=0
kfffde[4].xptr.chk: 42 ; 0x4c7: 0x2a
可以看到，我们的datafile 是30m，这里asm分配了4个au，每个au 8m，即是32m.
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
