oracle asm 剖析系列(4) –file directory
本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
在前面几篇文章中我分别详细剖析了disk header、free space table、pst以及disk directory等元数据结构,这一篇文章
将重点剖析另外一个重要的asm元数据结构,那就是file directory,这是跟我们database datafile关联最为紧密的一个
asm元数据结构,首先我们还是来使用kfed工具进行读取file directory的信息。
1 2 3 |
---读取disk header [oracle@10gasm ~]$ kfed read /dev/sdd |grep f1 kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002 |
通过读取disk header,可以发现file directory信息位于第2个AU中。
下面继续使用该工具读取相关信息,如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 |
[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、主要包括文件分配信息。下面针对部分关键信息进行说明:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
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的具体信息,如下:
1 2 3 4 5 6 7 8 9 |
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来进行展示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
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试图,如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
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中,我们来看看是不是这样:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 |
[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分配位置呢?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 |
---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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
[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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 |
[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 kfbh.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.
3 Responses to “oracle asm 剖析系列(4) –file directory”
[…] 2. 关于file directory,可以参考:http://www.killdb.com/2013/01/13/oracle-asm-%e5%89%96%e6%9e%90%e7%b3%bb%e5%88%974-file-directory.htm… […]
[…] 2. 关于file directory,可以参考:http://www.killdb.com/2013/01/13/oracle-asm-%e5%89%96%e6%9e%90%e7%b3%bb%e5%88%974-file-directory.htm… […]
关于如何定位file directory使用默认au大小也就是1M的时候确实实在2号au的block 1上,但是
对于自定义AU大小file header中的f1..也还是2,但是这个块类型却不是KFBTYP_FILEDIR了,就不在这个位置了,比如4M的是在AU 8 BLOCK 1上,不知道是否还有其他结构指针,我测试是在AIX 6.1 ORACLE 10205上测试的。
Leave a Reply
You must be logged in to post a comment.