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目录中相关记录可以用来把这些操作完成或回退。这些操作可能由另一个实例来完成或者由故障实例重启后来完成。
