ASM 翻譯系列第三十九彈:物理後設資料AT表

沃趣科技發表於2017-03-13

原作者: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表。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28218939/viewspace-2135207/,如需轉載,請註明出處,否則將追究法律責任。

相關文章