love wife & love life —Roger 的Oracle技术博客

Phone:18180207355 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务

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

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客

本文链接地址: 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有些类似。

后面还会继续研究分享,欢迎大家关注!这仅仅是个开始~~~

    分享到:
  • sunnyihui

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

  • Lunar

    还是一头雾水,预留的50M空间,体现在哪里呢?

  • steven

    thanks.

  • 孙海龙

    大师,我在AIX上测试时发现测试结果跟你的不一样,磁盘头块差不多,看到第二篇文档就进行不下去了,不知道AIX是不是有些特别的,
    AIX方面有什么资料可以参考呢!
    谢谢谢,这个问题困惑我很久!

  • 前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 […………….

  • Pingback: oracle asm 剖析系列(1) –disk header | Burning()

18180207355
加Q咨询