love wife love life —Roger的Oracle/MySQL數據恢復博客

Phone:18180207355 提供專業Oracle/MySQL數據恢復、性能優化、遷移升級、緊急救援等服務

oracle asm 剖析系列(1) –disk header

本站文章除注明轉載外,均為本站原創: 轉載自love wife love life —Roger的Oracle/MySQL數據恢復博客

本文鏈接地址: oracle asm 剖析系列(1) –disk header

asm是oracle 10g引入的特性,其好處就不多說了,在10g中存在不少的問題,但是在11g中相對比較穩定了。
曾經何時,asm對大多數dba來講,猶如一個黑匣子一樣,對其內部的原理架構完全不知道,最近兩年網上
也出現了不少的文檔對asm進行了解析,但是目前我尚未發現特別詳細的文章。這里我拋磚引玉,將寫一個
asm研究的系列,當然,這都是個人實驗研究的東西,歡迎大家拍磚,供大家參考,后續會陸續分享。

在這個asm系列中,我將對asm涉及的術語,例如如下的元數據信息進行詳細剖析:

上述元數據,其中有部分是11g才有的內容,部分在10g是不存在的,在10g版本中查詢,你會得到如下結果:

上述查詢的file信息,其實就的10g版本中asm所涉及的元數據信息,對應關系如下:

然后在11gR2版本中查詢,你會得到如下結果:

你可以看到,file 1~9 都是元數據信息。前面的file 1~6 對應的關系不變,那后面的file 8,file 9是什么呢?

file# 7 —volume directory (當你使用ACFS后,你會看到,后面會詳細描述)
file# 8 —disk Used Space Directory (USD)
file# 9 —attributes directory

在我的理解中,對于asm,大家可以理解為跟database一樣,是一個單獨的數據庫,而asm元數據,則可以理解為database中的
數據字典信息。由此,你可以詳細這些元數據是多么的重要,當然對這些元數據的分布等信息了解之后,在今后遇到相關的asm
故障時,處理起來將會非常的容易。

這asm系列的第一篇,我們首先來溫習asm disk header。曾經何時, 很多人都擔心asm disk header的損壞,進而導致
磁盤組無法mount,確實,在10.2.0.5版本以前,很容易出現這個問題,特別是aix環境下,如果disk存在pvid,那么很
容易在主機重啟后pvid被清空,進而導致disk header損壞,進而導致磁盤組無法mount。從10.2.0.5版本開始,oracle
會自動備份disk header,我在一片文章中也進行了描述。

那么disk header在什么地方?它的結構如何?其實以前我也寫過相關文章,所以這一篇我就相對簡單一些。

asm disk header,顧名思義就是磁盤頭塊,那顯然就是在disk的第一個block中。這里需要注意的是,操作系統block
是4k,而不是常見的數據庫block_size 8k。 我們可以使用oracle提供的kfed工具來對disk header block進行查看。

下面我們使用kfed來讀取header block,查看其內容:

當你使用kfed時,不指定AU,默認是讀取au 0,block 0(記住,asm中block編號都是從0開始的),當然,如果你指定,得到也是一樣的結果:

下面繼續進行詳細描述:

關于其他的不再累述,由于2010年底寫過一篇詳解disk header的文章,我這里摘取過來:

由于我這里是32位平臺,字節序是反的,所以大家看起來可能有點費力,不過沒關系,下面有對于關系的詳細描述,我原來的文章
是使用dd復制出disk header block,然后使用bbed來進行觀察的,如下:

下面我們來對上面的dump信息進行解釋:

最后再補充下,從11gR2開始,asm au會隨著extent的分配而發生變化,大概是如下一個關系:

當extent < 20000時,au size等于默認大小,如果你指定大小,那么默認是1m; 當extent >= 20000時, au size等于4倍默認au size大小,如果你不指定au大小,那么將是4m;
當extent >= 40000時,au size等于16倍默認au size大小,如果你不指定au大小,那么將是16m.

從asm角度來看,最小的分配單位是au,而一個或多個au又組成extent,所以這里的extent其實跟database中的extent有些類似。

后面還會繼續研究分享,歡迎大家關注!這僅僅是個開始~~~

6 Responses to “oracle asm 剖析系列(1) –disk header”

  1. sunnyihui Says:

    太深了,看起來有些吃力!!!!

  2. Lunar Says:

    還是一頭霧水,預留的50M空間,體現在哪里呢?

  3. steven Says:
  4. 孫海龍 Says:

    大師,我在AIX上測試時發現測試結果跟你的不一樣,磁盤頭塊差不多,看到第二篇文檔就進行不下去了,不知道AIX是不是有些特別的,
    AIX方面有什么資料可以參考呢!
    謝謝謝,這個問題困惑我很久!

  5. desertxu Says:

    前au # 50個是元數據,總共是51M元數據

    -bash-4.1$ kfed read /dev/raw/raw7 aun=50 |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: blk=256

    kfbh.block.obj: 1 ; 0x008: file=1

    kfbh.check: 2198926922 ; 0x00c: 0x8310f64a

    kfbh.fcn.base: 442 ; 0x010: 0x000001ba

    kfbh.fcn.wrap: 0 ; 0x014: 0x00000000

    kfbh.spare1: 0 ; 0x018: 0x00000000

    kfbh.spare2: 0 ; 0x01c: 0x00000000

    kfffdb.node.incarn: 885382041 ; 0x000: A=1 NUMM=0x1a62edcc

    kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff

    kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0

    kfffdb.hibytes: 0 ; 0x00c: 0x00000000

    kfffdb.lobytes: 104865792 ; 0x010: 0x06402000

    kfffdb.xtntcnt: 101 ; 0x014: 0x00000065

    kfffdb.xtnteof: 101 ; 0x018: 0x00000065

    kfffdb.blkSize: 8192 ; 0x01c: 0x00002000

    -bash-4.1$ kfed read /dev/raw/raw7 aun=51|more

    kfbh.endian: 0 ; 0x000: 0x00

    kfbh.hard: 162 ; 0x001: 0xa2

    kfbh.type: 0 ; 0x002: KFBTYP_INVALID

    kfbh.datfmt: 0 ; 0x003: 0x00

    kfbh.block.blk: 4290772992 ; 0x004: blk=2143289344 (indirect)

    kfbh.block.obj: 0 ; 0x008: file=0

    kfbh.check: 0 ; 0x00c: 0x00000000

    kfbh.fcn.base: 18886 ; 0x010: 0x000049c6

    kfbh.fcn.wrap: 8192 ; 0x014: 0x00002000

    kfbh.spare1: 12800 ; 0x018: 0x00003200

    kfbh.spare2: 2054913149 ; 0x01c: 0x7a7b7c7d

    7EFEF7064400 0000A200 FFC00000 00000000 00000000 […………….]

    7EFEF7064410 000049C6 00002000 00003200 7A7B7C7D [.I… …2..}|{z]

    7EFEF7064420 00000000 00000000 00000000 00000000 […………….

  6. oracle asm 剖析系列(1) –disk header | Burning Says:

Leave a Reply

You must be logged in to post a comment.

百度彩票APP