Oracle ASM Continuing Operations Directory

Continuing Operations Directory(COD)
COD用来跟踪ASM中长时间执行的操作,例如rebalance, drop disk, create/delete/resize file,这些信息ACD的简要结构不足以描述其变化,这些操作需要通过ASM的COD目录去追踪,COD是ASM的4号文件,A每一个磁盘组都会有一个COD。如果进程在执行长时间操作未正常完成前异常终止,将会有恢复进程查看COD区域的记录尝试完成或回退这个操作,有两种类型的持续性操作:后台操作和回滚操作。

后台操作
后台操作是由ASM实例的后台进程去执行的,它作为磁盘组的维护任务的一部分,而非特殊要求,直到完成或者ASM实例挂掉,如果ASM实例挂掉,执行恢复的实例需要重新执行后台操作,磁盘组的rebalance就是一个很好的后台操作的例子。我们查询内部视图X$KFFXP找到磁盘组3的COD的AU分布,COD是ASM的文件4,因此在查询中设置了number_kffxp=4。

SQL> select group_number,name,type from v$asm_diskgroup;

GROUP_NUMBER NAME                           TYPE
------------ ------------------------------ ------------
           1 ARCHDG                         NORMAL
           2 CRSDG                          EXTERN
           3 DATADG                         NORMAL
           4 TESTDG                         NORMAL

SQL> select group_number, disk_number, state, name,failgroup,mount_status from v$asm_disk where group_number=3;

GROUP_NUMBER DISK_NUMBER STATE                          NAME                           FAILGROUP                                                    MOUNT_STATUS
------------ ----------- ------------------------------ ------------------------------ ------------------------------------------------------------ --------------
           3           0 NORMAL                         DATADG_0001                    DATADG_0001                                                  CACHED
           3           3 NORMAL                         DATADG_0000                    DATADG_0000                                                  CACHED
           3           1 NORMAL                         DATADG_0003                    DATADG_0003                                                  CACHED
           3           2 NORMAL                         DATADG_0002                    DATADG_0002                                                  CACHED

SQL> select group_number,disk_number,name,path,state from v$asm_disk where group_number=3;

GROUP_NUMBER DISK_NUMBER NAME                           PATH                           STATE
------------ ----------- ------------------------------ ------------------------------ ------------------------------
           3           0 DATADG_0001                    /dev/raw/raw11                 NORMAL
           3           3 DATADG_0000                    /dev/raw/raw10                 NORMAL
           3           1 DATADG_0003                    /dev/raw/raw4                  NORMAL
           3           2 DATADG_0002                    /dev/raw/raw3                  NORMAL


SQL> select number_kffxp file#, disk_kffxp disk#, count(disk_kffxp) extents
  2  from x$kffxp
  3  where group_kffxp=3
  4   and disk_kffxp <> 65534
  5   and number_kffxp=4
  6  group by number_kffxp, disk_kffxp
  7  order by 1;

     FILE#      DISK#    EXTENTS
---------- ---------- ----------
         4          0          6
         4          1          5
         4          2          6
         4          3          7

可以看到,上面显示file #的信息有4条,每个COD大小分别是6个AU,5个AU,6个AU,7个AU。因磁盘组DATADG有4个磁盘所以有4行记录。

查询COD在磁盘组DATADG中的AU分布情况

SQL> select x.xnum_kffxp "virtual extent",pxn_kffxp "physical extent",x.au_kffxp "au",x.disk_kffxp "disk #",d.name "disk name"
  2  from x$kffxp x, v$asm_disk_stat d
  3  where x.group_kffxp=d.group_number
  4  and x.disk_kffxp=d.disk_number
  5  and x.group_kffxp=3
  6  and x.number_kffxp=4
  7  order by 1, 2,3;

virtual extent physical extent         au     disk # disk name
-------------- --------------- ---------- ---------- ------------------------------------------------------------
             0               0         36          2 DATADG_0002
             0               1         35          3 DATADG_0000
             0               2         35          1 DATADG_0003
             1               3         36          3 DATADG_0000
             1               4         37          0 DATADG_0001
             1               5         37          2 DATADG_0002
             2               6         72          1 DATADG_0003
             2               7         71          0 DATADG_0001
             2               8         71          3 DATADG_0000
             3               9         72          0 DATADG_0001
             3              10         72          3 DATADG_0000
             3              11         73          1 DATADG_0003
             4              12         73          2 DATADG_0002
             4              13         73          0 DATADG_0001
             4              14         73          3 DATADG_0000
             5              15         74          3 DATADG_0000
             5              16         74          1 DATADG_0003
             5              17         74          2 DATADG_0002
             6              18         75          1 DATADG_0003
             6              19         75          2 DATADG_0002
             6              20         74          0 DATADG_0001
             7              21         75          0 DATADG_0001
             7              22         76          2 DATADG_0002
             7              23         75          3 DATADG_0000

24 rows selected.

因磁盘组DATADG为normal冗余,并且有4个故障磁盘组所以COD信息将会有三份副本。也就是说virtual extent对应的3个physical extent所对应的3个AU所存储的内容是一样的。

通过kfed工具来查看COD的AU分布情况
由于1号文件总是开始在0号磁盘2号AU,记住这个位置:0号盘2号AU。这是ASM中定位文件的起点,它的作用,有点相当于磁盘上的引导区,在电脑开机后负责将OS启动起来。1号文件在最少情况下,至少有两个AU。在1号文件中,每个文件占用一个元数据块,存放自身的空间分布信息。每个元数据块大小是4K,一个AU是1M,哪么,每个AU中,可以存储256个文件的空间分布信息。这其中,0号盘2号AU中,全是元文件的信息。再具体一点,0号盘2号AU,第一个元数据块被系统占用,从第二个块开始,到255为止,共255个元数据块,对应索引号1至255的文件。其实,也就是全部的元文件了。也就是说0号盘2号AU,保存了全部元文件的空间分布信息。1号文件的第二个AU,从第一个块开始,保存256号文件。第二个块对应257号文件,等等。每次从ASM中读数据时,Oracle都要先读到1号文件,从中找出要读的目标文件在磁盘上的分布位置,然后再去读取相应的文件的数据。由于COD是4号文件,所以要读取0号磁盘(/dev/raw/raw11)的2号AU的4号块

[grid@jyrac1 ~]$ kfed read /dev/raw/raw11 aun=2 blkn=4 | 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:                       4 ; 0x004: blk=4
kfbh.block.obj:                       1 ; 0x008: file=1
kfbh.check:                  3953869782 ; 0x00c: 0xebab43d6
kfbh.fcn.base:                      307 ; 0x010: 0x00000133
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfffdb.node.incarn:                   1 ; 0x000: A=1 NUMM=0x0
kfffdb.node.frlist.number:   4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn:            0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes:                       0 ; 0x00c: 0x00000000
kfffdb.lobytes:                 8331264 ; 0x010: 0x007f2000
kfffdb.xtntcnt:                      24 ; 0x014: 0x00000018
kfffdb.xtnteof:                      24 ; 0x018: 0x00000018
kfffdb.blkSize:                    4096 ; 0x01c: 0x00001000
kfffdb.flags:                         1 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=0 A=0
kfffdb.fileType:                     15 ; 0x021: 0x0f
kfffdb.dXrs:                         19 ; 0x022: SCHE=0x1 NUMB=0x3
kfffdb.iXrs:                         19 ; 0x023: SCHE=0x1 NUMB=0x3
kfffdb.dXsiz[0]:             4294967295 ; 0x024: 0xffffffff
kfffdb.dXsiz[1]:                      0 ; 0x028: 0x00000000
kfffdb.dXsiz[2]:                      0 ; 0x02c: 0x00000000
kfffdb.iXsiz[0]:             4294967295 ; 0x030: 0xffffffff
kfffdb.iXsiz[1]:                      0 ; 0x034: 0x00000000
kfffdb.iXsiz[2]:                      0 ; 0x038: 0x00000000
kfffdb.xtntblk:                      24 ; 0x03c: 0x0018
kfffdb.break:                        60 ; 0x03e: 0x003c
kfffdb.priZn:                         0 ; 0x040: KFDZN_COLD
kfffdb.secZn:                         0 ; 0x041: KFDZN_COLD
kfffdb.ub2spare:                      0 ; 0x042: 0x0000
kfffdb.alias[0]:             4294967295 ; 0x044: 0xffffffff
kfffdb.alias[1]:             4294967295 ; 0x048: 0xffffffff
kfffdb.strpwdth:                      0 ; 0x04c: 0x00
kfffdb.strpsz:                        0 ; 0x04d: 0x00
kfffdb.usmsz:                         0 ; 0x04e: 0x0000
kfffdb.crets.hi:               33042831 ; 0x050: HOUR=0xf DAYS=0xc MNTH=0xc YEAR=0x7e0
kfffdb.crets.lo:             2457465856 ; 0x054: USEC=0x0 MSEC=0x27d SECS=0x27 MINS=0x24
kfffdb.modts.hi:               33042831 ; 0x058: HOUR=0xf DAYS=0xc MNTH=0xc YEAR=0x7e0
kfffdb.modts.lo:             2457465856 ; 0x05c: USEC=0x0 MSEC=0x27d SECS=0x27 MINS=0x24
kfffdb.dasz[0]:                       0 ; 0x060: 0x00
kfffdb.dasz[1]:                       0 ; 0x061: 0x00
kfffdb.dasz[2]:                       0 ; 0x062: 0x00
kfffdb.dasz[3]:                       0 ; 0x063: 0x00
kfffdb.permissn:                      0 ; 0x064: 0x00
kfffdb.ub1spar1:                      0 ; 0x065: 0x00
kfffdb.ub2spar2:                      0 ; 0x066: 0x0000
kfffdb.user.entnum:                   0 ; 0x068: 0x0000
kfffdb.user.entinc:                   0 ; 0x06a: 0x0000
kfffdb.group.entnum:                  0 ; 0x06c: 0x0000
kfffdb.group.entinc:                  0 ; 0x06e: 0x0000
kfffdb.spare[0]:                      0 ; 0x070: 0x00000000
kfffdb.spare[1]:                      0 ; 0x074: 0x00000000
kfffdb.spare[2]:                      0 ; 0x078: 0x00000000
kfffdb.spare[3]:                      0 ; 0x07c: 0x00000000
kfffdb.spare[4]:                      0 ; 0x080: 0x00000000
kfffdb.spare[5]:                      0 ; 0x084: 0x00000000
kfffdb.spare[6]:                      0 ; 0x088: 0x00000000
kfffdb.spare[7]:                      0 ; 0x08c: 0x00000000
kfffdb.spare[8]:                      0 ; 0x090: 0x00000000
kfffdb.spare[9]:                      0 ; 0x094: 0x00000000
kfffdb.spare[10]:                     0 ; 0x098: 0x00000000
kfffdb.spare[11]:                     0 ; 0x09c: 0x00000000
kfffdb.usm:                             ; 0x0a0: length=0
kfffde[0].xptr.au:                   36 ; 0x4a0: 0x00000024
kfffde[0].xptr.disk:                  2 ; 0x4a4: 0x0002
kfffde[0].xptr.flags:                 0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk:                  12 ; 0x4a7: 0x0c
kfffde[1].xptr.au:                   35 ; 0x4a8: 0x00000023
kfffde[1].xptr.disk:                  3 ; 0x4ac: 0x0003
kfffde[1].xptr.flags:                 0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk:                  10 ; 0x4af: 0x0a
kfffde[2].xptr.au:                   35 ; 0x4b0: 0x00000023
kfffde[2].xptr.disk:                  1 ; 0x4b4: 0x0001
kfffde[2].xptr.flags:                 0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk:                   8 ; 0x4b7: 0x08
kfffde[3].xptr.au:                   36 ; 0x4b8: 0x00000024
kfffde[3].xptr.disk:                  3 ; 0x4bc: 0x0003
kfffde[3].xptr.flags:                 0 ; 0x4be: L=0 E=0 D=0 S=0
kfffde[3].xptr.chk:                  13 ; 0x4bf: 0x0d
kfffde[4].xptr.au:                   37 ; 0x4c0: 0x00000025
kfffde[4].xptr.disk:                  0 ; 0x4c4: 0x0000
kfffde[4].xptr.flags:                 0 ; 0x4c6: L=0 E=0 D=0 S=0
kfffde[4].xptr.chk:                  15 ; 0x4c7: 0x0f
kfffde[5].xptr.au:                   37 ; 0x4c8: 0x00000025
kfffde[5].xptr.disk:                  2 ; 0x4cc: 0x0002
kfffde[5].xptr.flags:                 0 ; 0x4ce: L=0 E=0 D=0 S=0
kfffde[5].xptr.chk:                  13 ; 0x4cf: 0x0d
kfffde[6].xptr.au:                   72 ; 0x4d0: 0x00000048
kfffde[6].xptr.disk:                  1 ; 0x4d4: 0x0001
kfffde[6].xptr.flags:                 0 ; 0x4d6: L=0 E=0 D=0 S=0
kfffde[6].xptr.chk:                  99 ; 0x4d7: 0x63
kfffde[7].xptr.au:                   71 ; 0x4d8: 0x00000047
kfffde[7].xptr.disk:                  0 ; 0x4dc: 0x0000
kfffde[7].xptr.flags:                 0 ; 0x4de: L=0 E=0 D=0 S=0
kfffde[7].xptr.chk:                 109 ; 0x4df: 0x6d
kfffde[8].xptr.au:                   71 ; 0x4e0: 0x00000047
kfffde[8].xptr.disk:                  3 ; 0x4e4: 0x0003
kfffde[8].xptr.flags:                 0 ; 0x4e6: L=0 E=0 D=0 S=0
kfffde[8].xptr.chk:                 110 ; 0x4e7: 0x6e
kfffde[9].xptr.au:                   72 ; 0x4e8: 0x00000048
kfffde[9].xptr.disk:                  0 ; 0x4ec: 0x0000
kfffde[9].xptr.flags:                 0 ; 0x4ee: L=0 E=0 D=0 S=0
kfffde[9].xptr.chk:                  98 ; 0x4ef: 0x62
kfffde[10].xptr.au:                  72 ; 0x4f0: 0x00000048
kfffde[10].xptr.disk:                 3 ; 0x4f4: 0x0003
kfffde[10].xptr.flags:                0 ; 0x4f6: L=0 E=0 D=0 S=0
kfffde[10].xptr.chk:                 97 ; 0x4f7: 0x61
kfffde[11].xptr.au:                  73 ; 0x4f8: 0x00000049
kfffde[11].xptr.disk:                 1 ; 0x4fc: 0x0001
kfffde[11].xptr.flags:                0 ; 0x4fe: L=0 E=0 D=0 S=0
kfffde[11].xptr.chk:                 98 ; 0x4ff: 0x62
kfffde[12].xptr.au:                  73 ; 0x500: 0x00000049
kfffde[12].xptr.disk:                 2 ; 0x504: 0x0002
kfffde[12].xptr.flags:                0 ; 0x506: L=0 E=0 D=0 S=0
kfffde[12].xptr.chk:                 97 ; 0x507: 0x61
kfffde[13].xptr.au:                  73 ; 0x508: 0x00000049
kfffde[13].xptr.disk:                 0 ; 0x50c: 0x0000
kfffde[13].xptr.flags:                0 ; 0x50e: L=0 E=0 D=0 S=0
kfffde[13].xptr.chk:                 99 ; 0x50f: 0x63
kfffde[14].xptr.au:                  73 ; 0x510: 0x00000049
kfffde[14].xptr.disk:                 3 ; 0x514: 0x0003
kfffde[14].xptr.flags:                0 ; 0x516: L=0 E=0 D=0 S=0
kfffde[14].xptr.chk:                 96 ; 0x517: 0x60
kfffde[15].xptr.au:                  74 ; 0x518: 0x0000004a
kfffde[15].xptr.disk:                 3 ; 0x51c: 0x0003
kfffde[15].xptr.flags:                0 ; 0x51e: L=0 E=0 D=0 S=0
kfffde[15].xptr.chk:                 99 ; 0x51f: 0x63
kfffde[16].xptr.au:                  74 ; 0x520: 0x0000004a
kfffde[16].xptr.disk:                 1 ; 0x524: 0x0001
kfffde[16].xptr.flags:                0 ; 0x526: L=0 E=0 D=0 S=0
kfffde[16].xptr.chk:                 97 ; 0x527: 0x61
kfffde[17].xptr.au:                  74 ; 0x528: 0x0000004a
kfffde[17].xptr.disk:                 2 ; 0x52c: 0x0002
kfffde[17].xptr.flags:                0 ; 0x52e: L=0 E=0 D=0 S=0
kfffde[17].xptr.chk:                 98 ; 0x52f: 0x62
kfffde[18].xptr.au:                  75 ; 0x530: 0x0000004b
kfffde[18].xptr.disk:                 1 ; 0x534: 0x0001
kfffde[18].xptr.flags:                0 ; 0x536: L=0 E=0 D=0 S=0
kfffde[18].xptr.chk:                 96 ; 0x537: 0x60
kfffde[19].xptr.au:                  75 ; 0x538: 0x0000004b
kfffde[19].xptr.disk:                 2 ; 0x53c: 0x0002
kfffde[19].xptr.flags:                0 ; 0x53e: L=0 E=0 D=0 S=0
kfffde[19].xptr.chk:                 99 ; 0x53f: 0x63
kfffde[20].xptr.au:                  74 ; 0x540: 0x0000004a
kfffde[20].xptr.disk:                 0 ; 0x544: 0x0000
kfffde[20].xptr.flags:                0 ; 0x546: L=0 E=0 D=0 S=0
kfffde[20].xptr.chk:                 96 ; 0x547: 0x60
kfffde[21].xptr.au:                  75 ; 0x548: 0x0000004b
kfffde[21].xptr.disk:                 0 ; 0x54c: 0x0000
kfffde[21].xptr.flags:                0 ; 0x54e: L=0 E=0 D=0 S=0
kfffde[21].xptr.chk:                 97 ; 0x54f: 0x61
kfffde[22].xptr.au:                  76 ; 0x550: 0x0000004c
kfffde[22].xptr.disk:                 2 ; 0x554: 0x0002
kfffde[22].xptr.flags:                0 ; 0x556: L=0 E=0 D=0 S=0
kfffde[22].xptr.chk:                100 ; 0x557: 0x64
kfffde[23].xptr.au:                  75 ; 0x558: 0x0000004b
kfffde[23].xptr.disk:                 3 ; 0x55c: 0x0003
kfffde[23].xptr.flags:                0 ; 0x55e: L=0 E=0 D=0 S=0
kfffde[23].xptr.chk:                 98 ; 0x55f: 0x62
kfffde[24].xptr.au:          4294967295 ; 0x560: 0xffffffff
kfffde[24].xptr.disk:             65535 ; 0x564: 0xffff
kfffde[24].xptr.flags:                0 ; 0x566: L=0 E=0 D=0 S=0
kfffde[24].xptr.chk:                 42 ; 0x567: 0x2a

从kfffde[0].xptr.au=36,kfffde[0].xptr.disk=2可知COD存储在2号磁盘的36号AU,依此类推,这与上面的查询结果是一致的。

下面通过kfed工具来验证0号virtual extent的3个phyiscal extent所对的3个AU所存储的内容

[grid@jyrac1 ~]$ kfed read /dev/raw/raw3 aun=36 blkn=0 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            9 ; 0x002: KFBTYP_COD_BGO
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       4 ; 0x008: file=4
kfbh.check:                    17403005 ; 0x00c: 0x01098c7d
kfbh.fcn.base:                     3704 ; 0x010: 0x00000e78
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfrcbg.size:                          0 ; 0x000: 0x0000
kfrcbg.op:                            0 ; 0x002: 0x0000
kfrcbg.inum:                          0 ; 0x004: 0x00000000
kfrcbg.iser:                          0 ; 0x008: 0x00000000
[grid@jyrac1 ~]$ kfed read /dev/raw/raw10 aun=35 blkn=0 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            9 ; 0x002: KFBTYP_COD_BGO
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       4 ; 0x008: file=4
kfbh.check:                    17403005 ; 0x00c: 0x01098c7d
kfbh.fcn.base:                     3704 ; 0x010: 0x00000e78
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfrcbg.size:                          0 ; 0x000: 0x0000
kfrcbg.op:                            0 ; 0x002: 0x0000
kfrcbg.inum:                          0 ; 0x004: 0x00000000
kfrcbg.iser:                          0 ; 0x008: 0x00000000
[grid@jyrac1 ~]$ kfed read /dev/raw/raw4 aun=35 blkn=0 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            9 ; 0x002: KFBTYP_COD_BGO
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:                       4 ; 0x008: file=4
kfbh.check:                    17403005 ; 0x00c: 0x01098c7d
kfbh.fcn.base:                     3704 ; 0x010: 0x00000e78
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfrcbg.size:                          0 ; 0x000: 0x0000
kfrcbg.op:                            0 ; 0x002: 0x0000 -- 表示后台进程操作,有2种属性值,0 表示当前没有后台进程操作,1表示当前后台进程正在进行reblance operation.
kfrcbg.inum:                          0 ; 0x004: 0x00000000 --表示后台进程所运作的asm instance number
kfrcbg.iser:                          0 ; 0x008: 0x00000000

从上面的输出可以看到,0号virtual extent的3个phyiscal extent所对应的3个AU(2号磁盘[/dev/raw/raw3]的36号AU,3号磁盘[/dev/raw/raw10]的35号AU,1号磁盘[/dev/raw/raw4]的35号AU)所存储的内容是一样的。上面显示了一个COD的块,kfbh.type=KFBTYP_COD_BGO显示为background类型的操作,不过此刻并没有后台操作发生,因为所有的kfrcbg区域都是0,这代表了当前没有活跃的后台操作,如果操作代码kfrcbg.op为1,那么将表示有活跃的磁盘的rebalance操作在进行。

回滚操作
Rollback操作类型类似于数据库的事务。ASM的前台进程发起请求,为了能够记录这个rollback操作,必须在ASM的COD目录中申请一个槽位,COD目录的block 1展示了所有的槽位和使用状态,如果所有的槽位当时都是忙的,那么这个操作会休息一段时间,直到发现其中一个可以使用。rollback类型操作过程中,磁盘组是一个不一致的状态,这个操作需要完成或者回退所有它对磁盘组的更改。数据库实例大多时候会去执行这个操作(例如添加数据文件)。如果数据库实例挂掉或者ASM前台进程挂掉,一个不可恢复的错误会发生,然后这个操作会被终止。创建文件是一个rollback操作非常好的例子,如果在文件空间分配过程中发生错误,那么已经分配过的空间需要被删除,如果数据库实例没有提交文件的创建操作,这个文件必须被自动删除,如果ASM实例挂掉,这个删除操作会由恢复实例来执行。

使用kfed来查看COD的1号块:
先执行数据文件的创建操作

SQL> create tablespace jycs datafile '+DATADG/jyrac/datafile/jycs01.dbf' size 1G ; 

再查看cod的1号块

[grid@jyrac1 ~]$ kfed read /dev/raw/raw3 aun=36 blkn=1 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           15 ; 0x002: KFBTYP_COD_RBO --表示操作类型,15即为 KFBTYP_COD_RBO,RBO 即为rollback operation的简写
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                       1 ; 0x004: blk=1 --表示当前元数据所在的block号
kfbh.block.obj:                       4 ; 0x008: file=4
kfbh.check:                    34575077 ; 0x00c: 0x020f92e5
kfbh.fcn.base:                     4320 ; 0x010: 0x000010e0
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
--kfrcrb rb即为rollback
kfrcrb[0].opcode:                     1 ; 0x000: 0x0001 --表示具体的操作类型,该opcode有很多种属性值
kfrcrb[1].opcode:                     0 ; 0x002: 0x0000
kfrcrb[2].opcode:                     0 ; 0x004: 0x0000
kfrcrb[3].opcode:                     0 ; 0x006: 0x0000
kfrcrb[4].opcode:                     0 ; 0x008: 0x0000
kfrcrb[5].opcode:                     0 ; 0x00a: 0x0000
kfrcrb[6].opcode:                     0 ; 0x00c: 0x0000
kfrcrb[7].opcode:                     0 ; 0x00e: 0x0000
kfrcrb[8].opcode:                     0 ; 0x010: 0x0000
kfrcrb[9].opcode:                     0 ; 0x012: 0x0000
kfrcrb[10].opcode:                    0 ; 0x014: 0x0000
kfrcrb[11].opcode:                    0 ; 0x016: 0x0000
kfrcrb[12].opcode:                    0 ; 0x018: 0x0000
kfrcrb[13].opcode:                    0 ; 0x01a: 0x0000
kfrcrb[14].opcode:                    0 ; 0x01c: 0x0000

kfrcrb[i] 区域跟踪了所有活跃的rollback类型操作,上面的信息可以看到有一个操作正在进行中,kfrcrb[0]的值为1,从操作代码我们可以知道这是一个文件的创建操作,rollback操作类型的代码参照表如下:

1 - Create a file
2 - Delete a file
3 - Resize a file
4 - Drop alias entry
5 - Rename alias entry
6 - Rebalance space COD
7 - Drop disks force
8 - Attribute drop
9 - Disk Resync
10 - Disk Repair Time
11 - Volume create
12 - Volume delete
13 - Attribute directory creation
14 - Set zone attributes
15 - User drop

上面的操作是11G,如果是10G,kfrcrb[i]则是不一样的多了kfrcrb[i].inum,kfrcrb[i].iser,kfrcrb[i].pnum例如:

[oracle@jyrac3 ~]$ kfed read /dev/raw/raw5 aun=7 blkn=1 aus=16777216 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           15 ; 0x002: KFBTYP_COD_RBO
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       1 ; 0x004: T=0 NUMB=0x1
kfbh.block.obj:                       4 ; 0x008: TYPE=0x0 NUMB=0x4
kfbh.check:                    17797779 ; 0x00c: 0x010f9293
kfbh.fcn.base:                     4247 ; 0x010: 0x00001097
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfrcrb[0].opcode:                     0 ; 0x000: 0x0000 --表示具体的操作类型,该opcode有很多种属性值
kfrcrb[0].inum:                       0 ; 0x002: 0x0000 --表示asm instance number
kfrcrb[0].iser:                       0 ; 0x004: 0x00000000
kfrcrb[0].pnum:                       0 ; 0x008: 0x00000000
kfrcrb[1].opcode:                     0 ; 0x00c: 0x0000
kfrcrb[1].inum:                       0 ; 0x00e: 0x0000
kfrcrb[1].iser:                       0 ; 0x010: 0x00000000
kfrcrb[1].pnum:                       0 ; 0x014: 0x00000000
kfrcrb[2].opcode:                     0 ; 0x018: 0x0000
kfrcrb[2].inum:                       0 ; 0x01a: 0x0000
kfrcrb[2].iser:                       0 ; 0x01c: 0x00000000
kfrcrb[2].pnum:                       0 ; 0x020: 0x00000000
kfrcrb[3].opcode:                     0 ; 0x024: 0x0000
kfrcrb[3].inum:                       0 ; 0x026: 0x0000
kfrcrb[3].iser:                       0 ; 0x028: 0x00000000
kfrcrb[3].pnum:                       0 ; 0x02c: 0x00000000
kfrcrb[4].opcode:                     0 ; 0x030: 0x0000
kfrcrb[4].inum:                       0 ; 0x032: 0x0000
kfrcrb[4].iser:                       0 ; 0x034: 0x00000000
kfrcrb[4].pnum:                       0 ; 0x038: 0x00000000
kfrcrb[5].opcode:                     0 ; 0x03c: 0x0000
kfrcrb[5].inum:                       0 ; 0x03e: 0x0000
kfrcrb[5].iser:                       0 ; 0x040: 0x00000000
kfrcrb[5].pnum:                       0 ; 0x044: 0x00000000
kfrcrb[6].opcode:                     0 ; 0x048: 0x0000
kfrcrb[6].inum:                       0 ; 0x04a: 0x0000
kfrcrb[6].iser:                       0 ; 0x04c: 0x00000000
kfrcrb[6].pnum:                       0 ; 0x050: 0x00000000
kfrcrb[7].opcode:                     0 ; 0x054: 0x0000
kfrcrb[7].inum:                       0 ; 0x056: 0x0000
kfrcrb[7].iser:                       0 ; 0x058: 0x00000000
kfrcrb[7].pnum:                       0 ; 0x05c: 0x00000000
kfrcrb[8].opcode:                     0 ; 0x060: 0x0000

接下来才是COD DATA

[grid@jyrac1 ~]$ kfed read /dev/raw/raw3 aun=36 blkn=2 
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           16 ; 0x002: KFBTYP_COD_DATA
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       2 ; 0x004: blk=2
kfbh.block.obj:                       4 ; 0x008: file=4
kfbh.check:                   916174568 ; 0x00c: 0x369bb6e8
kfbh.fcn.base:                     4320 ; 0x010: 0x000010e0
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000

这部分是COD DATA内容,从上面可以看到,基本上就是只要头部信息,唯一更新的也就是check值和bash。

小结:
ASM的COD目录跟踪所有长时间运行的ASM操作,对于由于任何原因导致的问题,COD目录中相关记录可以用来把这些操作完成或回退。这些操作可能由另一个实例来完成或者由故障实例重启后来完成。

Leave a Reply

Your email address will not be published.

Proudly powered by WordPress | Indrajeet by Sus Hill.