sitemap

RSS地图

收藏本站

设为首页

Oracle研究中心

当前位置:Oracle研究中心 > 产品DBA > Oracle ASM >

【学习笔记】Oracle asm 剖析系列(2)–pst/fst/allocator tabe

时间:2016-12-19 10:28   来源:Oracle研究中心   作者:网络   点击:

天萃荷净 10gR2 asm | love wife & love life —Roger 的Oracle技术博客

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客
本文链接地址: oracle asm 剖析系列(2)–pst/fst/allocator tabe

在前面一篇文章中,我们详细描述了disk header的结构以及其含义,其中从disk header中,我们发现了如下信息:

[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=0| more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
......
kfdhdb.dsksize:                    1024 ; 0x0c4: 0x00000400
kfdhdb.pmcnt:                         2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001
kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn:                      2 ; 0x0d4: 0x00000002
......

这里的kfdhdb.fstlocn表示Free Space Table (FST),所以在asm剖析系列第2篇文章中,我将重点描述FST的结构。

不管是在10g还是在11g版本中,FST的信息都的存在固定的位置,如下:

[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=0 blkn=0 | grep fstlocn
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001

从上面信息我们可以知道,FST信息存在第一个AU中,由于asm中,block编号都是从第0个开始,所以可以使用kfed直接查看元数据信息,不过这里第0个block的数据并不是FST的信息,而是Partnership and Status Table (PST)信息。顾名思义,PST,就是存放diskgroup中disk的关系以及disk状态灯信息,下面通过kfed来查看详细详细:

[oracle@10gasm ~]$ kfed read /dev/sdd aun=1 blkn=0
kfbh.endian:                          1 ; 0x000: 0x01            --1表示little,0表示big。
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           17 ; 0x002: KFBTYP_PST_META --表示PST元数据
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                     256 ; 0x004: T=0 NUMB=0x100
kfbh.block.obj:              2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check:                   841194965 ; 0x00c: 0x32239dd5
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpHdrB.time.hi:              32977623 ; 0x000: HOUR=0x17 DAYS=0x16 MNTH=0xc YEAR=0x7dc
kfdpHdrB.time.lo:            2999004160 ; 0x004: USEC=0x0 MSEC=0x4b SECS=0x2c MINS=0x2c
kfdpHdrB.last:                        3 ; 0x008: 0x00000003
kfdpHdrB.next:                        3 ; 0x00c: 0x00000003
kfdpHdrB.copyCnt:                     1 ; 0x010: 0x01
kfdpHdrB.ub1spare:                    0 ; 0x011: 0x00
kfdpHdrB.ub2spare:                    0 ; 0x012: 0x0000
kfdpHdrB.incarn:                      0 ; 0x014: 0x00000000
kfdpHdrB.copy[0]:                     0 ; 0x018: 0x0000
kfdpHdrB.copy[1]:                     0 ; 0x01a: 0x0000
kfdpHdrB.copy[2]:                     0 ; 0x01c: 0x0000
kfdpHdrB.copy[3]:                     0 ; 0x01e: 0x0000
kfdpHdrB.copy[4]:                     0 ; 0x020: 0x0000
kfdpHdrB.dtaSz:                       4 ; 0x022: 0x0004
ub1[0]:                               2 ; 0x024: 0x02
ub1[1]:                               0 ; 0x025: 0x00
ub1[2]:                               0 ; 0x026: 0x00
ub1[3]:                               0 ; 0x027: 0x00
ub1[4]:                               0 ; 0x028: 0x00
..........
ub1[4026]:                            0 ; 0xfde: 0x00
ub1[4027]:                            0 ; 0xfdf: 0x00

既然这里提到了PST,那么我们就首先来描述Partnership and Status Table (PST)的结构和含义。在前不久还遇到asm添加disk时导致磁盘组无法mount,我通过模拟测试发现通过可以修改pst等信息将diskgroup成功mount,大家可以参考下:

asm 添加disk时,ctrl+C导致diskgroup无法mount

asm的pst信息通常都存在disk中的第一个AU中的前面几个block中,如下是这里的情况:

[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=0 | grep type
kfbh.type:                           17 ; 0x002: KFBTYP_PST_META

[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=1 | grep type
kfbh.type:                           17 ; 0x002: KFBTYP_PST_META

[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=2 | grep type
kfbh.type:                           18 ; 0x002: KFBTYP_PST_DTA

[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=3 | grep type
kfbh.type:                           18 ; 0x002: KFBTYP_PST_DTA

[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=4 | grep type
kfbh.type:                           13 ; 0x002: KFBTYP_PST_NONE

[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=1 blkn=5 | grep type
kfbh.type:
从上面信息可以看出,在前面2个block是存的pst元数据,而blk 2,3则是存放的pst数据。首先我们来分析pst的元数据.

[oracle@10gasm ~]$ kfed read /dev/sdd aun=1 blkn=0 |more

kfbh.endian:                          1 ; 0x000: 0x01   ---0 表示big endian,1 表示little endian.
kfbh.hard:                          130 ; 0x001: 0x82   ---这里是HARD magic number
kfbh.type:                           17 ; 0x002: KFBTYP_PST_META  ---这表示元数据block类型
kfbh.datfmt:                          1 ; 0x003: 0x01     ---表示元数据block格式
kfbh.block.blk:                     256 ; 0x004: T=0 NUMB=0x100  ---表示block位置
kfbh.block.obj:              2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check:                   841194965 ; 0x00c: 0x32239dd5   --主要是做校验用的,check一致性
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpHdrB.time.hi:              32977623 ; 0x000: HOUR=0x17 DAYS=0x16 MNTH=0xc YEAR=0x7dc --最后一次pst元数据的更新时间,这是高位
kfdpHdrB.time.lo:            2999004160 ; 0x004: USEC=0x0 MSEC=0x4b SECS=0x2c MINS=0x2c  --最后一次pst元数据的更新时间,这是地位
kfdpHdrB.last:                        3 ; 0x008: 0x00000003   ---最新的disk版本号
kfdpHdrB.next:                        3 ; 0x00c: 0x00000003   ---下一个disk版本号
kfdpHdrB.copyCnt:                     1 ; 0x010: 0x01   ---表示PST元数据的备份信息,如果是1表示磁盘组是external冗余。如果是3那么则是normal。
kfdpHdrB.ub1spare:                    0 ; 0x011: 0x00
kfdpHdrB.ub2spare:                    0 ; 0x012: 0x0000
kfdpHdrB.incarn:                      0 ; 0x014: 0x00000000
kfdpHdrB.copy[0]:                     0 ; 0x018: 0x0000
kfdpHdrB.copy[1]:                     0 ; 0x01a: 0x0000
kfdpHdrB.copy[2]:                     0 ; 0x01c: 0x0000
kfdpHdrB.copy[3]:                     0 ; 0x01e: 0x0000
kfdpHdrB.copy[4]:                     0 ; 0x020: 0x0000
kfdpHdrB.dtaSz:                       4 ; 0x022: 0x0004  ---表示pst元数据中,diskgroup所包含的disk个数
ub1[0]:                               2 ; 0x024: 0x02
........

[oracle@10gasm ~]$ kfed read /dev/sdd aun=1 blkn=1 |more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           17 ; 0x002: KFBTYP_PST_META
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                     257 ; 0x004: T=0 NUMB=0x101
kfbh.block.obj:              2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check:                   847094230 ; 0x00c: 0x327da1d6
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpHdrB.time.hi:              32977623 ; 0x000: HOUR=0x17 DAYS=0x16 MNTH=0xc YEAR=0x7dc
kfdpHdrB.time.lo:            2996768768 ; 0x004: USEC=0x0 MSEC=0x3c4 SECS=0x29 MINS=0x2c
kfdpHdrB.last:                        2 ; 0x008: 0x00000002
kfdpHdrB.next:                        3 ; 0x00c: 0x00000003
kfdpHdrB.copyCnt:                     1 ; 0x010: 0x01
kfdpHdrB.ub1spare:                    0 ; 0x011: 0x00
kfdpHdrB.ub2spare:                    0 ; 0x012: 0x0000
kfdpHdrB.incarn:                      0 ; 0x014: 0x00000000
kfdpHdrB.copy[0]:                     0 ; 0x018: 0x0000
kfdpHdrB.copy[1]:                     0 ; 0x01a: 0x0000
kfdpHdrB.copy[2]:                     0 ; 0x01c: 0x0000
kfdpHdrB.copy[3]:                     0 ; 0x01e: 0x0000
kfdpHdrB.copy[4]:                     0 ; 0x020: 0x0000
kfdpHdrB.dtaSz:                       4 ; 0x022: 0x0004
ub1[0]:                               1 ; 0x024: 0x01
ub1[1]:                               0 ; 0x025: 0x00
..........

正如我那篇文章所提到的那样,如果某个disk无法从diskgroup中去掉,进行重新添加时(10g至少是这样,11g可以force操作).那么我们就可以通过去修改pst等元数据来完成,当然这个不建议随便操作,比较危险,除非你有十分的把握。即使操作也需要先dd备份相关的au数据。提到pst,其实就必须要说一下asm的gmon进程,因为相关元数据的操作都是该进程来完成的,我这里来strace跟踪下gmon的动作,同时我开另外一个sqlplus窗口进行drop disk操作,如下:

---session 1
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  /

Path              File Name            Fail GROUP           File SIZE (MB) Used SIZE (MB) Pct. Used
----------------- -------------------- -------------------- -------------- -------------- ---------
/dev/sdb          DATA1_0002           DATA1_0002                    1,024              2       .20
/dev/sdc          DATA1_0001           DATA1_0001                    1,024            503     49.12
/dev/sdd          DATA1_0000           DATA1_0000                    1,024            504     49.22
/dev/sde          DATA1_0003           DATA1_0003                    1,024              2       .20
                                                            -------------- --------------
                                                                     4,096          1,011

                                                            -------------- --------------
                                                                     4,096          1,011

SQL> ALTER diskgroup data1 DROP disk DATA1_0003;

Diskgroup altered.

SQL>
—-session 2

trace信息如下:
[oracle@10gasm tmp]$ cat 3.log |grep write
30006      0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200i]\334\\\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000069 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\2740\233\202\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000154 write(2, "*** 2013-01-07 06:43:38.072", 27) = 27
30006      0.000091 write(2, "\n", 1)   = 1
30006      0.000059 write(2, "InvalLck (group 1) upgraded to X"..., 33) = 33
30006      0.000105 write(2, "\n", 1)   = 1
30006      0.000056 pwrite64(19, "\1\202\21\1\1\1\0\0\0\0\0\200\322\235#2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1052672) = 4096
30006      0.000058 pwrite64(19, "\1\202\22\1\2\1\0\0\0\0\0\200\3\203\22\201\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1056768) = 4096
30006      0.000081 pwrite64(19, "\1\202\21\1\0\1\0\0\0\0\0\200\346\357\203.\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1048576) = 4096
30006      0.000037 write(2, "InvalLck (group 1) downgraded to"..., 35) = 35
30006      0.000046 write(2, "\n", 1)   = 1
30006      0.000038 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\17@f*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200s\216\2T\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000025 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\311TQK\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\252gB\304\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000028 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\221\310\n`\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000046 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\301[~G\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000047 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\212j\202\365\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200i\304\307\31\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000029 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200$V\212{\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000036 write(2, "*** 2013-01-07 06:44:11.939", 27) = 27
30006      0.000055 write(2, "\n", 1)   = 1
30006      0.000041 write(2, "InvalLck (group 1) upgraded to X"..., 33) = 33
30006      0.000049 write(2, "\n", 1)   = 1
30006      0.000024 pwrite64(19, "\1\202\21\1\1\1\0\0\0\0\0\200\347\357\203.\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1052672) = 4096
30006      0.000040 pwrite64(19, "\1\202\22\1\3\1\0\0\0\0\0\200\2\203\22\201\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1060864) = 4096
30006      0.000037 pwrite64(19, "\1\202\21\1\0\1\0\0\0\0\0\200\344s\\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1048576) = 4096
30006      0.000040 write(2, "InvalLck (group 1) downgraded to"..., 35) = 35
30006      0.000049 write(2, "\n", 1)   = 1
30006      0.000028 write(2, "InvalLck (group 1) upgraded to X"..., 33) = 33
30006      0.000034 write(2, "\n", 1)   = 1
30006      0.000039 pwrite64(19, "\1\202\21\1\1\1\0\0\0\0\0\200\347s\\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1052672) = 4096
30006      0.000025 pwrite64(19, "\1\202\22\1\2\1\0\0\0\0\0\200\3\203\22\203\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1056768) = 4096
30006      0.000024 pwrite64(19, "\1\202\21\1\0\1\0\0\0\0\0\200\346\23#0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1048576) = 4096
30006      0.000039 write(2, "InvalLck (group 1) downgraded to"..., 35) = 35
30006      0.000053 write(2, "\n", 1)   = 1
30006      0.000036 write(2, "PST verChk 3: ack, id=2593589894"..., 56) = 56
30006      0.000049 write(2, "\n", 1)   = 1
30006      0.000024 write(2, "InvalLck (group 1) upgraded to X"..., 33) = 33
30006      0.000032 write(2, "\n", 1)   = 1
30006      0.000028 pwrite64(19, "\1\202\21\1\1\1\0\0\0\0\0\200\347\23$0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1052672) = 4096
30006      0.000023 pwrite64(19, "\1\202\22\1\3\1\0\0\0\0\0\200\2\203\22\206\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1060864) = 4096
30006      0.000024 pwrite64(19, "\1\202\21\1\0\1\0\0\0\0\0\200\344+$0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 1048576) = 4096
30006      0.000024 write(2, "InvalLck (group 1) downgraded to"..., 35) = 35
30006      0.000031 write(2, "\n", 1)   = 1
30006      0.000028 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\2007Ip\246\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000033 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200Au\236\35\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000029 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200h\3174V\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000031 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\215]\246\214\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000023 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\324*\30E\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200Fy]\313\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000025 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\321{\275\357\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\261WC\274\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.000038 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\36@\335k\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
[oracle@10gasm tmp]$

上面的file 2是gmon进程产生的trace文件,而file 19正是/dev/sdd,如下:
[oracle@10gasm fd]$ ls -ltr
total 0
lrwx------ 1 oracle oinstall 64 Jan  7 06:47 9 -> /home/oracle/oracle/product/10.2.0/dbs/hc_+ASM.dat
l-wx------ 1 oracle oinstall 64 Jan  7 06:47 8 -> /home/oracle/admin/+ASM/bdump/alert_+ASM.log
lrwx------ 1 oracle oinstall 64 Jan  7 06:47 7 -> /home/oracle/oracle/product/10.2.0/dbs/lkinst+ASM (deleted)
l-wx------ 1 oracle oinstall 64 Jan  7 06:47 6 -> /home/oracle/admin/+ASM/bdump/alert_+ASM.log
l-wx------ 1 oracle oinstall 64 Jan  7 06:47 5 -> /home/oracle/admin/+ASM/udump/+asm_ora_29975.trc
lr-x------ 1 oracle oinstall 64 Jan  7 06:47 4 -> /dev/null
lr-x------ 1 oracle oinstall 64 Jan  7 06:47 3 -> /dev/null
lrwx------ 1 oracle oinstall 64 Jan  7 06:47 20 -> /dev/sdc
l-wx------ 1 oracle oinstall 64 Jan  7 06:47 2 -> /home/oracle/admin/+ASM/bdump/+asm_gmon_30006.trc
lrwx------ 1 oracle oinstall 64 Jan  7 06:47 19 -> /dev/sdd
lrwx------ 1 oracle oinstall 64 Jan  7 06:47 18 -> socket:[253917]
lrwx------ 1 oracle oinstall 64 Jan  7 06:47 17 -> socket:[253916]
lr-x------ 1 oracle oinstall 64 Jan  7 06:47 16 -> /home/oracle/oracle/product/10.2.0/cdata/localhost/local.ocr
lr-x------ 1 oracle oinstall 64 Jan  7 06:47 15 -> /home/oracle/oracle/product/10.2.0/srvm/mesg/procus.msb
lrwx------ 1 oracle oinstall 64 Jan  7 06:47 14 -> /home/oracle/oracle/product/10.2.0/dbs/hc_+ASM.dat
lr-x------ 1 oracle oinstall 64 Jan  7 06:47 13 -> /home/oracle/oracle/product/10.2.0/rdbms/mesg/oraus.msb
lr-x------ 1 oracle oinstall 64 Jan  7 06:47 12 -> /dev/zero
lr-x------ 1 oracle oinstall 64 Jan  7 06:47 11 -> /dev/zero
lrwx------ 1 oracle oinstall 64 Jan  7 06:47 10 -> /home/oracle/oracle/product/10.2.0/rdbms/audit/ora_29975.aud
lr-x------ 1 oracle oinstall 64 Jan  7 06:47 1 -> /dev/null
lr-x------ 1 oracle oinstall 64 Jan  7 06:47 0 -> /dev/null
从上面的trace信息,我们可以看出,gmon进程在每次更新元数据时,每次写操作都是更新4096 byte,也就是一个block。最后的数字是offset。
简单换算一下,如下:

SQL> SELECT 1048576/4096 FROM dual;

1048576/4096
------------
         256  
SQL> SELECT 1052672/4096 FROM dual;

1052672/4096
------------
         257
SQL> SELECT 1056768/4096 FROM dual;

1056768/4096
------------
         258
SQL> SELECT 1060864/4096 FROM dual;

1060864/4096
------------
         259
SQL> SELECT 2093056/4096 FROM dual;

2093056/4096
------------
         511
从上面的数据我们可以得到什么呢? 由于第1(实际上是第0个au)个au只存255个block,那么从256开始到259就是在第2个au中(实际上是第1个au),如下:

[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=256|grep type
kfbh.type:                           17 ; 0x002: KFBTYP_PST_META
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=257|grep type
kfbh.type:                           17 ; 0x002: KFBTYP_PST_META
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=258|grep type
kfbh.type:                           18 ; 0x002: KFBTYP_PST_DTA
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=259|grep type
kfbh.type:                           18 ; 0x002: KFBTYP_PST_DTA

说明gmon进程操作了上述4个pst 数据块,其中2个元数据block,2个pst数据block。那么最后gmon进程操作的block 511又是什么呢?
通过分析trace,发现gmon进程每秒钟都会更新该block,如下:


30006      0.000038 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\17@f*\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.001413 times(NULL)         = 445917247
30006      0.000071 gettimeofday({1357569818, 778684}, NULL) = 0
..........
30006      0.000031 gettimeofday({1357569822, 909002}, NULL) = 0
30006      0.000070 times(NULL)         = 445917547
30006      0.000032 poll([{fd=17, events=POLLIN|POLLRDNORM}, {fd=17, events=0}, {fd=18, events=POLLIN|POLLRDNORM}, {fd=18, events=0}], 4, 0) = 0 (Timeout)
30006      0.000038 times(NULL)         = 445917547
30006      0.000020 times(NULL)         = 445917547
30006      0.000028 gettimeofday({1357569822, 909190}, NULL) = 0
30006      0.000024 gettimeofday({1357569822, 909214}, NULL) = 0
30006      0.000038 gettimeofday({1357569822, 909253}, NULL) = 0
30006      0.000046 times(NULL)         = 445917547
30006      0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200s\216\2T\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.005612 times(NULL)         = 445917548
30006      0.000057 gettimeofday({1357569822, 914994}, NULL) = 0
..........
30006      0.000027 semtimedop(3506176, 0xbf9ccb68, 1, {3, 0}) = -1 EAGAIN (Resource temporarily unavailable)
30006      4.024697 gettimeofday({1357569826, 939952}, NULL) = 0
30006      0.000054 gettimeofday({1357569826, 939985}, NULL) = 0
..........
30006      0.000084 gettimeofday({1357569826, 940574}, NULL) = 0
30006      0.000053 times(NULL)         = 445917848
30006      0.000025 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\311TQK\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.141790 times(NULL)         = 445917858
30006      0.000054 gettimeofday({1357569827, 82494}, NULL) = 0
.........
30006      0.000028 gettimeofday({1357569827, 82694}, NULL) = 0
30006      0.000030 semtimedop(3506176, 0xbf9ccb68, 1, {3, 0}) = -1 EAGAIN (Resource temporarily unavailable)
30006      4.067061 gettimeofday({1357569831, 149787}, NULL) = 0
30006      0.000032 gettimeofday({1357569831, 149852}, NULL) = 0
........
30006      0.000038 gettimeofday({1357569831, 150224}, NULL) = 0
30006      0.000031 gettimeofday({1357569831, 150254}, NULL) = 0
30006      0.000026 times(NULL)         = 445918159
30006      0.000025 poll([{fd=17, events=POLLIN|POLLRDNORM}, {fd=17, events=0}, {fd=18, events=POLLIN|POLLRDNORM}, {fd=18, events=0}], 4, 0) = 0 (Timeout)
30006      0.000038 times(NULL)         = 445918159
........
30006      0.000040 gettimeofday({1357569831, 150460}, NULL) = 0
30006      0.000052 times(NULL)         = 445918159
30006      0.000024 pwrite64(19, "\1\202\23\1\377\1\0\0\0\0\0\200\252gB\304\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096, 2093056) = 4096
30006      0.038081 times(NULL)         = 445918161
30006      0.000107 gettimeofday({1357569831, 188731}, NULL) = 0
我们来看下这个block 511是什么?

[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           19 ; 0x002: KFBTYP_HBEAT
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                     511 ; 0x004: T=0 NUMB=0x1ff
kfbh.block.obj:              2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check:                  1801389837 ; 0x00c: 0x6b5f070d
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpHbeatB.instance:                  0 ; 0x000: 0x00000000
kfdpHbeatB.ts.hi:              32982247 ; 0x004: HOUR=0x7 DAYS=0x7 MNTH=0x1 YEAR=0x7dd
kfdpHbeatB.ts.lo:            1823758336 ; 0x008: USEC=0x0 MSEC=0x116 SECS=0xb MINS=0x1b
kfdpHbeatB.rnd[0]:           4243380219 ; 0x00c: 0xfcecd7fb
kfdpHbeatB.rnd[1]:           4223846872 ; 0x010: 0xfbc2c9d8
kfdpHbeatB.rnd[2]:            544685178 ; 0x014: 0x20773c7a
kfdpHbeatB.rnd[3]:           2690038349 ; 0x018: 0xa056ba4d

KFBTYP_HBEAT,很显然这是asm的disk心跳验证,oracle正是通过这个来判断某个disk是否属于某个磁盘组,以防止其他磁盘组将该disk挂载。这里我猜测oracle是通过hash算法来计算hash值的,也就是上面的kfbh.check,通过观察,正常情况下,该值基本上是几秒就会被更新,如下:

[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|grep check
kfbh.check:                  1696975138 ; 0x00c: 0x6525c922
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|grep check
kfbh.check:                   238939432 ; 0x00c: 0x0e3ded28
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|grep check
kfbh.check:                   931877671 ; 0x00c: 0x378b5327
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=511|grep check
kfbh.check:                   625709379 ; 0x00c: 0x254b9143

最后我们再回到前面的问题,Free Space Table (FST)是什么?其结构又是如何的?

[ora11g@11gR2test ~]$ kfed read /dev/sdd aun=0 blkn=0 | grep fstlocn
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001
[ora11g@11gR2test ~]$

前面我们用kfed读取,看到fst的第1个block应该是1,而位置就是第1个AU,如下:
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=1|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            2 ; 0x002: KFBTYP_FREESPC
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       1 ; 0x004: T=0 NUMB=0x1
kfbh.block.obj:              2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check:                  2147519081 ; 0x00c: 0x80008a69
kfbh.fcn.base:                     2071 ; 0x010: 0x00000817
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdfsb.aunum:                         0 ; 0x000: 0x00000000
kfdfsb.max:                         254 ; 0x004: 0x00fe
kfdfsb.cnt:                           3 ; 0x006: 0x0003
kfdfse[0].total:                    448 ; 0x008: 0x01c0
kfdfse[0].free:                       1 ; 0x00a: 0x01
kfdfse[0].frag:                       1 ; 0x00b: 0x01
kfdfse[1].total:                    448 ; 0x00c: 0x01c0
kfdfse[1].free:                       1 ; 0x00e: 0x01
kfdfse[1].frag:                       1 ; 0x00f: 0x01
kfdfse[2].total:                    128 ; 0x010: 0x0080
kfdfse[2].free:                       1 ; 0x012: 0x01
kfdfse[2].frag:                       1 ; 0x013: 0x01
kfdfse[3].total:                      0 ; 0x014: 0x0000
kfdfse[3].free:                       0 ; 0x016: 0x00
........
上面的kfdfse.total,加起来就是disk /dev/sdd的大小1024m。同一个磁盘组里面的disk都存在fst信息,而且信息基本上完全一致。如下:

[oracle@10gasm ~]$ kfed read /dev/sdc aun=0 blkn=1|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            2 ; 0x002: KFBTYP_FREESPC
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       1 ; 0x004: T=0 NUMB=0x1
kfbh.block.obj:              2147483649 ; 0x008: TYPE=0x8 NUMB=0x1
kfbh.check:                  2147519071 ; 0x00c: 0x80008a5f
kfbh.fcn.base:                     2080 ; 0x010: 0x00000820
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdfsb.aunum:                         0 ; 0x000: 0x00000000
kfdfsb.max:                         254 ; 0x004: 0x00fe
kfdfsb.cnt:                           3 ; 0x006: 0x0003
kfdfse[0].total:                    448 ; 0x008: 0x01c0
kfdfse[0].free:                       1 ; 0x00a: 0x01
kfdfse[0].frag:                       1 ; 0x00b: 0x01
kfdfse[1].total:                    448 ; 0x00c: 0x01c0
kfdfse[1].free:                       1 ; 0x00e: 0x01
kfdfse[1].frag:                       1 ; 0x00f: 0x01
kfdfse[2].total:                    128 ; 0x010: 0x0080
kfdfse[2].free:                       1 ; 0x012: 0x01
kfdfse[2].frag:                       1 ; 0x013: 0x01
kfdfse[3].total:                      0 ; 0x014: 0x0000
kfdfse[3].free:                       0 ; 0x016: 0x00
kfdfse[3].frag:                       0 ; 0x017: 0x00
kfdfse[4].total:                      0 ; 0x018: 0x0000
........

[oracle@10gasm ~]$ kfed read /dev/sdb aun=0 blkn=1|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            2 ; 0x002: KFBTYP_FREESPC
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       1 ; 0x004: T=0 NUMB=0x1
kfbh.block.obj:              2147483650 ; 0x008: TYPE=0x8 NUMB=0x2
kfbh.check:                  2147517052 ; 0x00c: 0x8000827c
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdfsb.aunum:                         0 ; 0x000: 0x00000000 ---对应的au编号
kfdfsb.max:                         254 ; 0x004: 0x00fe
kfdfsb.cnt:                           3 ; 0x006: 0x0003     ---当前disk包含的fst kfdfse条目数。
kfdfse[0].total:                    448 ; 0x008: 0x01c0
kfdfse[0].free:                       1 ; 0x00a: 0x01
kfdfse[0].frag:                       1 ; 0x00b: 0x01
kfdfse[1].total:                    448 ; 0x00c: 0x01c0
kfdfse[1].free:                       1 ; 0x00e: 0x01
kfdfse[1].frag:                       1 ; 0x00f: 0x01
kfdfse[2].total:                    128 ; 0x010: 0x0080
kfdfse[2].free:                       1 ; 0x012: 0x01
kfdfse[2].frag:                       1 ; 0x013: 0x01
kfdfse[3].total:                      0 ; 0x014: 0x0000
kfdfse[3].free:                       0 ; 0x016: 0x00

除了标注信息外,其他信息,没有什么实际意义,不过多描述。
[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=2|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:                       2 ; 0x004: T=0 NUMB=0x2
kfbh.block.obj:              2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check:                   980649727 ; 0x00c: 0x3a7386ff
kfbh.fcn.base:                     2465 ; 0x010: 0x000009a1
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdatb.aunum:                         0 ; 0x000: 0x00000000
kfdatb.shrink:                      448 ; 0x004: 0x01c0
kfdatb.ub2pad:                    46872 ; 0x006: 0xb718
kfdatb.auinfo[0].link.next:        3608 ; 0x008: 0x0e18
kfdatb.auinfo[0].link.prev:         256 ; 0x00a: 0x0100
kfdatb.auinfo[0].free:              149 ; 0x00c: 0x0095
kfdatb.auinfo[0].total:             448 ; 0x00e: 0x01c0
kfdatb.auinfo[1].link.next:          16 ; 0x010: 0x0010
kfdatb.auinfo[1].link.prev:          16 ; 0x012: 0x0010
kfdatb.auinfo[1].free:                0 ; 0x014: 0x0000
kfdatb.auinfo[1].total:               0 ; 0x016: 0x0000
kfdatb.auinfo[2].link.next:          24 ; 0x018: 0x0018
kfdatb.auinfo[2].link.prev:          24 ; 0x01a: 0x0018
kfdatb.auinfo[2].free:                0 ; 0x01c: 0x0000
kfdatb.auinfo[2].total:               0 ; 0x01e: 0x0000
kfdatb.auinfo[3].link.next:          32 ; 0x020: 0x0020
kfdatb.auinfo[3].link.prev:          32 ; 0x022: 0x0020
kfdatb.auinfo[3].free:                0 ; 0x024: 0x0000
kfdatb.auinfo[3].total:               0 ; 0x026: 0x0000
kfdate[0].allo.lo:                    0 ; 0x028: XNUM=0x0
kfdate[0].allo.hi:              8388608 ; 0x02c: V=1 I=0 FNUM=0x0
kfdate[1].allo.lo:                    0 ; 0x030: XNUM=0x0
kfdate[1].allo.hi:              8388608 ; 0x034: V=1 I=0 FNUM=0x0
kfdate[2].allo.lo:                    0 ; 0x038: XNUM=0x0
kfdate[2].allo.hi:              8388609 ; 0x03c: V=1 I=0 FNUM=0x1
kfdate[3].allo.lo:                    1 ; 0x040: XNUM=0x1
kfdate[3].allo.hi:              8388611 ; 0x044: V=1 I=0 FNUM=0x3
kfdate[4].allo.lo:                    3 ; 0x048: XNUM=0x3
kfdate[4].allo.hi:              8388611 ; 0x04c: V=1 I=0 FNUM=0x3
kfdate[5].allo.lo:                    7 ; 0x050: XNUM=0x7
kfdate[5].allo.hi:              8388611 ; 0x054: V=1 I=0 FNUM=0x3
kfdate[6].free.lo.next:             256 ; 0x058: 0x0100
kfdate[6].free.lo.prev:             120 ; 0x05a: 0x0078
kfdate[6].free.hi:                    0 ; 0x05c: V=0 ASZM=0x0
kfdate[7].allo.lo:                   11 ; 0x060: XNUM=0xb
kfdate[7].allo.hi:              8388611 ; 0x064: V=1 I=0 FNUM=0x3
kfdate[8].allo.lo:                   13 ; 0x068: XNUM=0xd
kfdate[8].allo.hi:              8388611 ; 0x06c: V=1 I=0 FNUM=0x3
kfdate[9].allo.lo:                   15 ; 0x070: XNUM=0xf
kfdate[9].allo.hi:              8388611 ; 0x074: V=1 I=0 FNUM=0x3
kfdate[10].free.lo.next:             88 ; 0x078: 0x0058
kfdate[10].free.lo.prev:            136 ; 0x07a: 0x0088
kfdate[10].free.hi:                   0 ; 0x07c: V=0 ASZM=0x0
kfdate[11].allo.lo:                  19 ; 0x080: XNUM=0x13
kfdate[11].allo.hi:             8388611 ; 0x084: V=1 I=0 FNUM=0x3
kfdate[12].free.lo.next:            120 ; 0x088: 0x0078
kfdate[12].free.lo.prev:            152 ; 0x08a: 0x0098
kfdate[12].free.hi:                   0 ; 0x08c: V=0 ASZM=Oracleoracleplus.net0x0
kfdate[13].allo.lo:                  21 ; 0x090: XNUM=0x15
kfdate[13].allo.hi:             8388611 ; 0x094: V=1 I=0 FNUM=0x3
kfdate[14].free.lo.next:            136 ; 0x098: 0x0088
kfdate[14].free.lo.prev:            184 ; 0x09a: 0x00b8
kfdate[14].free.hi:                   0 ; 0x09c: V=0 ASZM=0x0
kfdate[15].allo.lo:                  25 ; 0x0a0: XNUM=0x19
kfdate[15].allo.hi:             8388611 ; 0x0a4: V=1 I=0 FNUM=0x3
kfdate[16].allo.lo:                  29 ; 0x0a8: XNUM=0x1d
kfdate[16].allo.hi:             8388611 ; 0x0ac: V=1 I=0 FNUM=0x3
kfdate[17].allo.lo:                  30 ; 0x0b0: XNUM=0x1e
kfdate[17].allo.hi:             8388611 ; 0x0b4: V=1 I=0 FNUM=0x3
kfdate[18].free.lo.next:            152 ; 0x0b8: 0x0098
kfdate[18].free.lo.prev:            192 ; 0x0ba: 0x00c0
kfdate[18].free.hi:                   0 ; 0x0bc: V=0 ASZM=0x0
kfdate[19].free.lo.next:            184 ; 0x0c0: 0x00b8
kfdate[19].free.lo.prev:            208 ; 0x0c2: 0x00d0
kfdate[19].free.hi:                   0 ; 0x0c4: V=0 ASZM=0x0
kfdate[20].allo.lo:                  33 ; 0x0c8: XNUM=0x21
kfdate[20].allo.hi:             8388611 ; 0x0cc: V=1 I=0 FNUM=0x3
kfdate[21].free.lo.next:            192 ; 0x0d0: 0x00c0
kfdate[21].free.lo.prev:            240 ; 0x0d2: 0x00f0
kfdate[21].free.hi:                   0 ; 0x0d4: V=0 ASZM=0x0
kfdate[22].allo.lo:                  36 ; 0x0d8: XNUM=0x24
..........

[oracle@10gasm ~]$ kfed read /dev/sdd aun=0 blkn=3|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:                       3 ; 0x004: T=0 NUMB=0x3
kfbh.block.obj:              2147483648 ; 0x008: TYPE=0x8 NUMB=0x0
kfbh.check:                   941327592 ; 0x00c: 0x381b84e8
kfbh.fcn.base:                     2516 ; 0x010: 0x000009d4
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdatb.aunum:                       448 ; 0x000: 0x000001c0
kfdatb.shrink:                      448 ; 0x004: 0x01c0
kfdatb.ub2pad:                    46872 ; 0x006: 0xb718
kfdatb.auinfo[0].link.next:         424 ; 0x008: 0x01a8
kfdatb.auinfo[0].link.prev:        3616 ; 0x00a: 0x0e20
kfdatb.auinfo[0].free:              411 ; 0x00c: 0x019b
kfdatb.auinfo[0].total:             448 ; 0x00e: 0x01c0
kfdatb.auinfo[1].link.next:          16 ; 0x010: 0x0010
kfdatb.auinfo[1].link.prev:          16 ; 0x012: 0x0010
kfdatb.auinfo[1].free:                0 ; 0x014: 0x0000
kfdatb.auinfo[1].total:               0 ; 0x016: 0x0000
kfdatb.auinfo[2].link.next:          24 ; 0x018: 0x0018
kfdatb.auinfo[2].link.prev:          24 ; 0x01a: 0x0018
kfdatb.auinfo[2].free:                0 ; 0x01c: 0x0000
kfdatb.auinfo[2].total:               0 ; 0x01e: 0x0000
kfdatb.auinfo[3].link.next:          32 ; 0x020: 0x0020
kfdatb.auinfo[3].link.prev:          32 ; 0x022: 0x0020
kfdatb.auinfo[3].free:                0 ; 0x024: 0x0000
kfdatb.auinfo[3].total:               0 ; 0x026: 0x0000
kfdate[0].allo.lo:                   33 ; 0x028: XNUM=0x21
kfdate[0].allo.hi:              8388870 ; 0x02c: V=1 I=0 FNUM=0x106
kfdate[1].free.lo.next:             480 ; 0x030: 0x01e0
kfdate[1].free.lo.prev:              72 ; 0x032: 0x0048
kfdate[1].free.hi:                    0 ; 0x034: V=0 ASZM=0x0
kfdate[2].allo.lo:                   37 ; 0x038: XNUM=0x25
kfdate[2].allo.hi:              8388870 ; 0x03c: V=1 I=0 FNUM=0x106
kfdate[3].allo.lo:                   39 ; 0x040: XNUM=0x27
kfdate[3].allo.hi:              8388870 ; 0x044: V=1 I=0 FNUM=0x106
kfdate[4].free.lo.next:              48 ; 0x048: 0x0030
kfdate[4].free.lo.prev:              96 ; 0x04a: 0x0060
kfdate[4].free.hi:                    0 ; 0x04c: V=0 ASZM=0x0
kfdate[5].allo.lo:                   43 ; 0x050: XNUM=0x2b
kfdate[5].allo.hi:              8388870 ; 0x054: V=1 I=0 FNUM=0x106
kfdate[6].allo.lo:                   45 ; 0x058: XNUM=0x2d
kfdate[6].allo.hi:              8388870 ; 0x05c: V=1 I=0 FNUM=0x106
kfdate[7].free.lo.next:              72 ; 0x060: 0x0048
kfdate[7].free.lo.prev:             120 ; 0x062: 0x0078
kfdate[7].free.hi:                    0 ; 0x064: V=0 ASZM=0x0
kfdate[8].allo.lo:                   49 ; 0x068: XNUM=0x31
kfdate[8].allo.hi:              8388870 ; 0x06c: V=1 I=0 FNUM=0x106
kfdate[9].allo.lo:                   51 ; 0x070: XNUM=0x33
kfdate[9].allo.hi:              8388870 ; 0x074: V=1 I=0 FNUM=0x106
kfdate[10].free.lo.next:             96 ; 0x078: 0x0060
kfdate[10].free.lo.prev:            136 ; 0x07a: 0x0088
kfdate[10].free.hi:                   0 ; 0x07c: V=0 ASZM=0x0
kfdate[11].allo.lo:                  55 ; 0x080: XNUM=0x37
kfdate[11].allo.hi:             8388870 ; 0x084: V=1 I=0 FNUM=0x106
kfdate[12].free.lo.next:            120 ; 0x088: 0x0078
kfdate[12].free.lo.prev:            160 ; 0x08a: 0x00a0
........
au 0上,从block 1开始到255,都是 ASM allocator table信息,你可以想象为这些au的分配关系都被串成一个链表,每个链表上的一个点都是一个指针,对应做一个AU编号。

最后奉上一个图,清晰的描述了asm元数据的关系,一目了然。

--------------------------------------ORACLE-DBA----------------------------------------

最权威、专业的Oracle案例资源汇总之【学习笔记】Oracle asm 剖析系列(2)–pst/fst/allocator tabe

本文由大师惜分飞原创分享,网址:http://www.oracleplus.net/arch/1415.html

Oracle研究中心

关键词:

Oracle ASM

oracle kfed