ASM 翻译系列第三十九弹:物理元数据AT表

原作者:Bane Radulovic

译者: 魏兴华

审核: 魏兴华

DBGeeK联合出品

原文链接:http://asmsupportguy.blogspot.sg/2013/08/allocation-table.html

Allocation Table

每一块由ASM管理的磁盘都会至少包含一个Allocation Table ,简称AT表,它是用来描述磁盘的AU分布情况的,AT表里的每一个条目都代表了磁盘上的一个AU,一旦某个AU被分配出去,AT表中此条目的内容会被更新,例如此AU属于的extent号和属于哪一个文件。

Finding The Allocation Table

AT表是由N个AT块组成的(不同的AU大小,N的值会不同),它位于ASM磁盘头所在的AU。下面例子里kfed工具的输出显示,AT表开始于磁盘头所在AU(0号AU)的第二个块。

$ kfed read /dev/sdc1 | grep kfdhdb.altlocn
kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002

我们通过kfed工具来进一步看一下AT表第一个块的细节信息:

$ kfed read /dev/sdc1 blkn=2 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
...
kfdatb.aunum:                         0 ; 0x000: 0x00000000
kfdatb.shrink:                      448 ; 0x004: 0x01c0
...

kfdatb.aunum=0意味着AU0是这个AT块所描述的第一个AU,kfdatb.shrink=448 意味着这个AT 块可以包含448个AU的信息。因此不难猜测,在下一个AT块,kfdatb.aunum的值应该为448(AU编号是从0号开始),它包含的是AU 448到AU (448+448)的信息,我们通过kfed来证明一下:

$ kfed read /dev/sdc1 blkn=3 | grep kfdatb.aunum
kfdatb.aunum:                       448 ; 0x000: 0x000001c0

同样,第三个AT块(AU的第四个块)应该显示kfdatb.aunum=896:

$ kfed read /dev/sdc1 blkn=4 | grep kfdatb.aunum
kfdatb.aunum:                       896 ; 0x000: 0x00000380

以此类推。

Allocation table entries

使用kfed工具可以读取AT表的内容,对于已经从磁盘中分配出去的AU,会在AT表相关条目上记录相应的extent号,文件号和au的状态,对于已经分配出去的AU,flag V=1,否则,flag V=0,例如AU还没有分配给具体的文件或者已经释放掉的AU,V的值会是0。

我们通过kfed工具来看下AT表上块的内容:

$ kfed read /dev/sdc1 blkn=3 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            3 ; 0x002: KFBTYP_ALLOCTBL
...
kfdatb.aunum:                       448 ; 0x000: 0x000001c0
...
kfdate[142].discriminator:            1 ; 0x498: 0x00000001
kfdate[142].allo.lo:                  0 ; 0x498: XNUM=0x0
kfdate[142].allo.hi:            8388867 ; 0x49c: V=1 I=0 H=0 FNUM=0x103
kfdate[143].discriminator:            1 ; 0x4a0: 0x00000001
kfdate[143].allo.lo:                  1 ; 0x4a0: XNUM=0x1
kfdate[143].allo.hi:            8388867 ; 0x4a4: V=1 I=0 H=0 FNUM=0x103
kfdate[144].discriminator:            1 ; 0x4a8: 0x00000001
kfdate[144].allo.lo:                  2 ; 0x4a8: XNUM=0x2
kfdate[144].allo.hi:            8388867 ; 0x4ac: V=1 I=0 H=0 FNUM=0x103
kfdate[145].discriminator:            1 ; 0x4b0: 0x00000001
kfdate[145].allo.lo:                  3 ; 0x4b0: XNUM=0x3
kfdate[145].allo.hi:            8388867 ; 0x4b4: V=1 I=0 H=0 FNUM=0x103
kfdate[146].discriminator:            1 ; 0x4b8: 0x00000001
kfdate[146].allo.lo:                  4 ; 0x4b8: XNUM=0x4
kfdate[146].allo.hi:            8388867 ; 0x4bc: V=1 I=0 H=0 FNUM=0x103
kfdate[147].discriminator:            1 ; 0x4c0: 0x00000001
kfdate[147].allo.lo:                  5 ; 0x4c0: XNUM=0x5
kfdate[147].allo.hi:            8388867 ; 0x4c4: V=1 I=0 H=0 FNUM=0x103
kfdate[148].discriminator:            0 ; 0x4c8: 0x00000000
kfdate[148].free.lo.next:            16 ; 0x4c8: 0x0010
kfdate[148].free.lo.prev:            16 ; 0x4ca: 0x0010
kfdate[148].free.hi:                  2 ; 0x4cc: V=0 ASZM=0x2
kfdate[149].discriminator:            0 ; 0x4d0: 0x00000000
kfdate[149].free.lo.next:             0 ; 0x4d0: 0x0000
kfdate[149].free.lo.prev:             0 ; 0x4d2: 0x0000
kfdate[149].free.hi:                  0 ; 0x4d4: V=0 ASZM=0x0
...

译者注:kfdate[i].allo.lo的值代表了文件的物理的extent号,即视图X$KFFXP的PXN_KFFXP字段。

上面摘录的信息显示,ASM的259号文件 (十六进制FNUM=0x103转换后)在AT表中占用了一些条目,从kfdate[142] 开始到 kfdate[147],共包含了6个AU,AU的绝对AU号计算方式为kfdate[i] + offset (kfdatb.aunum=448),也就是说142+448=590, 143+448=591 ... 147+448=595,可以通过查询X$KFFXP视图得到证实:

SQL> select AU_KFFXP
from X$KFFXP
where GROUP_KFFXP=1  -- disk group 1
and NUMBER_KFFXP=259 -- file 259
;
  AU_KFFXP
----------
       590
       591
       592
       593
       594
       595
6 rows selected.

译者注:视图X$KFFXP记录的信息,准确的说是extent的信息而非AU,当文件的extent数量大于20000的时候,AU_KFFXP字段的值仅仅代表了这个extent的起始AU号。例如下面的语句查看了496号文件的前几个extent和大于20000以后的4个extent,前几个的AU_KFFXP(Allocation unit)值是连续的,大于20000的Allocation unit值是跳跃的,这是因为AU_KFFXP的值只代表了这个extent起始的AU号。SIZE_KFFXP的值代表了这个extent是由几个AU组成的。

select XNUM_KFFXP "Virtual extent", PXN_KFFXP "Physical extent", LXN_KFFXP "Extent copy", DISK_KFFXP "Disk", AU_KFFXP "Allocation unit",SIZE_KFFXP
from X$KFFXP
where GROUP_KFFXP=1 and NUMBER_KFFXP=496 and SIZE_KFFXP=1 and DISK_KFFXP=2
and rownum<10
union all
select XNUM_KFFXP "Virtual extent", PXN_KFFXP "Physical extent", LXN_KFFXP "Extent copy", DISK_KFFXP "Disk", AU_KFFXP "Allocation unit",SIZE_KFFXP
from X$KFFXP
where GROUP_KFFXP=1 and NUMBER_KFFXP=496 and AU_KFFXP>384224 and DISK_KFFXP=2
;
Virtual extent Physical extent Extent copy   Disk Allocation unit SIZE_KFFXP
-------------- --------------- ----------- ---------- --------------- ----------
         2           5       1      2          380130          1
         6          12       0      2          380131          1
        16          32       0      2          380132          1
        24          49       1      2          380133          1
        26          52       0      2          380134          1
        29          59       1      2          380135          1
        36          72       0      2          380136          1
        46          92       0      2          380137          1
        50         101       1      2          380138          1
     21150       42300       0      2          384228          4
     21156       42313       1      2          384232          4
     21160       42320       0      2          384236          4
     21170       42340       0      2          384240          4

通过在AT表中搜索某个虚拟extent号大于20000的extent也可以看出,它是由4个AU组成的。

for (( i=0; i<256; i++ ))
do
kfed read /dev/mmm/path-102.321.01.fioa  blkn=$i | grep 45340
done
kfdate[388].allo.lo:              45340 ; 0xc48: XNUM=0xb11c
kfdate[389].allo.lo:              45340 ; 0xc50: XNUM=0xb11c
kfdate[390].allo.lo:              45340 ; 0xc58: XNUM=0xb11c
kfdate[391].allo.lo:              45340 ; 0xc60: XNUM=0xb11c

Free space

在上面kfed的输出中,我们可以看到kfdate[148] 和 kfdate[149]是free的AU,因为标志V=0(kfdate[148].free.hi: 2 ; 0x4cc: V=0 ASZM=0x2),后面的输出被我人为的截断掉了,其实这个AT块中还有很多没有被分配出去的free的AU。

The stride

每一个AT块(4K)可以描述448个AU(kfed输出的kfdatb.shrink值表明了这一点),每一个AT表有254个块(Free Space Table块中的 kfdfsb.max的值表明了这一点,关于Free Space Table块的内容请参考本系列的Free Space Table章节)。这意味着一个AT表可以用来描述254*448= 113792个AU。这在ASM里被称为一个stride,一个stride可以描述的AU在ASM的磁盘头的kfdhdb.mfact部分看到:

$ kfed read /dev/sdc1 | grep kfdhdb.mfact

kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80

在我们例子中,AU的size是1M,AU0可以装载256个元数据块,块0是磁盘头块,块1是Free Space Table,剩余254个块就是作为AT表的块。

假如AU的size是4M(Exadata的默认值),一个stride能够容纳的AU就会是454272或者说是454272*4= 1817088M,越大的AU size,stride也可以变得更大。

How Many Allocation Tables

大的ASM磁盘stride的数量会不止一个,每一个stride都会有它自己的物理元数据,也就是会有它自己的AT表。

例如,我们找一个大的磁盘,看下第二个stride的物理元数据,它同样是位于这个stride的第一个AU中,我们来看下:

$ kfed read /dev/sdc1 | grep mfact

kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80

上面显示了第一个stride包含了113792 AU,可以推算出第二个stride位于第113792 AU中(注意AU号是从0号开始计算的),AT表位于这个AU中的第2-255个块。

$ kfed read /dev/sdc1 aun=113792 blkn=2 | grep type

kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL

...

$ kfed read /dev/sdc1 aun=113792 blkn=255 | grep type

kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL

跟我们预测的一样,我们有第二个AT在第113792AU中,继续,如果有第三个stride,那么AT同样位于stride的开始AU处。

$ kfed read /dev/sdc1 aun=227584 blkn=2 | grep type

kfbh.type: 3 ; 0x002: KFBTYP_ALLOCTBL

Conclusion

每一个ASM磁盘可能会包含不止一个AT表,AT表描述了磁盘的AU分配情况,AT表中的每一个条目代表了磁盘上的一个AU,如果磁盘比较大,可以有不止一个stride,每一个stride都会有它自己的AT表。

文件。

原文发布于微信公众号 - 沃趣科技(woqutech)

原文发表时间:2017-03-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏我是攻城师

Solr中如何使用游标进行深度分页查询

39260
来自专栏程序小工

windows7使用Sphinx+PHP+MySQL详细介绍

由于业务需要,需要做类似淘宝商城商品检索的功能,对于数据量很大的情况,MySQL 查询的效率损耗很大,需要使用专门的索引引擎进行搜索查询,实现功能,对于和 PH...

52610
来自专栏数据和云

【循序渐进Oracle】Oracle的逻辑备份与恢复

编辑手记:针对最近发生的炉石及GitLab事件,我们不得不再次强调备份的重要性。DBA的四大守则,第一条就是备份重于一切。年初做好备份,愿你的系统17无恙。 本...

46080
来自专栏知识分享

3-MSP430引脚中断

为了写一篇文章做铺垫--提醒着自己,,,,,, 这两天一直在寻找 #pragma vector = PORT1_VECTOR __interrupt void ...

29570
来自专栏xingoo, 一个梦想做发明家的程序员

DB Cache

1 DB Cache 是以bock为单位组织的缓冲区,不同大小的BLOCK对应不同的缓冲区参数 2 DB Cache的命中率越高,访问性能就越好 3 Cache...

21990
来自专栏祝威廉

ElasticSearch QueryCache漫谈

这些天在做ES调优,因为之前更多的是考虑ES的架构和可运维性,并没有过多关注query调优这块。今天一查Query Cache相关的内容,发现是少之又少。于是自...

18920
来自专栏数据库新发现

数据库服务:数据库表空间扩容

http://www.enmotech.com/services/service.html(专业数据库服务)

15840
来自专栏企鹅号快讯

全文搜索引擎Elasticsearch入门教程

全文搜索属于最常见的需求,开源的Elasticsearch(以下简称 Elastic)是目前全文搜索引擎的首选。 它可以快速地储存、搜索和分析海量数据。维基百科...

27270
来自专栏沃趣科技

ASM 翻译系列第十五弹:ASM Internal ASM File Directory

原作者:Bane Radulovic 译者: 郭旭瑞 审核: 魏兴华 DBGeeK社群联合出品 ASM File Directory 本篇主要介绍A...

36840
来自专栏Greenplum

Greenplum 列存表(AO表)的膨胀和垃圾检查与空间收缩

Greenplum支持行储存(HEAP储存)与列(append-only)储存,对于AO存储,虽然是appendonly,但实际上GP是支持DELETE和UPD...

48710

扫码关注云+社区

领取腾讯云代金券