暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

Oracle ASM Virtually addressed metadata- Continuing Operations Directory

原创 李翔宇 2021-11-04
663

Continuing Operations Directory简称COD,是ASM的4号文件,该文件的作用是记录一些持续性的操作,当操作意外终止时,可以利用COD来实现继续完成或者回滚,如果说ACD是ASM实例的redo的话,那么COD就是ASM实例的undo。

COD的持续性操作类型分为Background operation和Rollback operation。

所谓Background operation就是由ASM实例后台进程发起的操作,由COD的0号block记录,所以0号block也称为COD BackGround Operations block,最经典的例子就是rebalance操作,当ASM实例在rebalance操作未完成时crash,或者磁盘组意外dismount,那么当磁盘组重新mount之后,COD BackGround Operations block会告诉ASM实例继续完成rebalance操作,直至完成;

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:                    17407171 ; 0x00c: 0x01099cc3
kfbh.fcn.base:                     7878 ; 0x010: 0x00001ec6
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
  • KFBTYP_COD_BGO:COD BackGround Operations block
  • kfrcbg.op:BackGround Operation的opcode,由KFRCBG_OPDEF定义,1为rebalance
  • kfrcbg.inum:执行Background operation的ASM实例号
  • 手动去触发rebalance会发现有kfrcbg.bgdata为1,说明rebalance正在进行,当reblance完成时kfrcbg.bgdata将变回0
[grid@rac1 ~]$ kfed read /dev/asmdisk-data4 aun=17 
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:                    17341748 ; 0x00c: 0x01089d34
kfbh.fcn.base:                     7981 ; 0x010: 0x00001f2d
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfrcbg.size:                         20 ; 0x000: 0x0014
kfrcbg.op:                            1 ; 0x002: 0x0001
kfrcbg.inum:                          1 ; 0x004: 0x00000001
kfrcbg.iser:                          8 ; 0x008: 0x00000008
kfrcbg.bgdata[0]:                     1 ; 0x00c: 0x00000001
kfrcbg.bgdata[1]:                     0 ; 0x010: 0x00000000

而Rollback operation是由ASM实例的前台进程发起,比如添加文件、删除文件等等,由COD的1号block记录,所以1号block也成为COD RollBack Operations block,该block非常类似undo表空间的undo segment header,当有Rollback operation操作类型的操作发起,首先会在COD RollBack Operations block的kfrcrb slot上去绑定opcode,这与oracle实例的事务绑定undo segment header的事务表slot非常类似,当该操作完成或者操作失败回滚之后,对应的kfrcrb slot将被释放变成0。

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           15 ; 0x002: KFBTYP_COD_RBO
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                       1 ; 0x004: blk=1
kfbh.block.obj:                       4 ; 0x008: file=4
kfbh.check:                    34577688 ; 0x00c: 0x020f9d18
kfbh.fcn.base:                     7964 ; 0x010: 0x00001f1c
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfrcrb[0].opcode:                     0 ; 0x000: 0x0000
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
  • KFBTYP_COD_RBO:COD RollBack Operations block:
Rollback operation的opcode定义:
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

RollBack Operations的相关操作记录是从COD的2号块开始存放,也称之为COD rollback Data block,与undo block非常类似,当操作失败可以利用COD rollback Data block进行回滚。

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:                  1051941057 ; 0x00c: 0x3eb358c1
kfbh.fcn.base:                     7958 ; 0x010: 0x00001f16
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000

注意,ACD也记录了该操作使用的所有COD变更记录,这与redo也记录了undo的改动是同样的原理,例如下面添加数据文件的例子,ACD记录了该操作绑定了kfrcrb slot 0,操作类型(opname)为1(create file),COD DATA记录在COD的2号块等等信息。

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            8 ; 0x002: KFBTYP_CHNGDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                     670 ; 0x004: blk=670
kfbh.block.obj:                       3 ; 0x008: file=3
kfbh.check:                   686175035 ; 0x00c: 0x28e6333b
kfbh.fcn.base:                     7957 ; 0x010: 0x00001f15
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfracdb.aba.seq:                      5 ; 0x000: 0x00000005
kfracdb.aba.blk:                    669 ; 0x004: 0x0000029d
kfracdb.ents:                         2 ; 0x008: 0x0002
kfracdb.ub2spare:                     0 ; 0x00a: 0x0000
kfracdb.lge[0].valid:                 1 ; 0x00c: V=1 B=0 M=0
kfracdb.lge[0].chgCount:              4 ; 0x00d: 0x04
kfracdb.lge[0].len:                 340 ; 0x00e: 0x0154
kfracdb.lge[0].kfcn.base:          7958 ; 0x010: 0x00001f16
kfracdb.lge[0].kfcn.wrap:             0 ; 0x014: 0x00000000
kfracdb.lge[0].bcd[0].kfbl.blk:       1 ; 0x018: blk=1
kfracdb.lge[0].bcd[0].kfbl.obj:       4 ; 0x01c: file=4
kfracdb.lge[0].bcd[0].kfcn.base:   7955 ; 0x020: 0x00001f13
kfracdb.lge[0].bcd[0].kfcn.wrap:      0 ; 0x024: 0x00000000
kfracdb.lge[0].bcd[0].oplen:         16 ; 0x028: 0x0010
kfracdb.lge[0].bcd[0].blkIndex:       1 ; 0x02a: 0x0001
kfracdb.lge[0].bcd[0].flags:         28 ; 0x02c: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb.lge[0].bcd[0].opcode:       210 ; 0x02e: 0x00d2
kfracdb.lge[0].bcd[0].kfbtyp:        15 ; 0x030: KFBTYP_COD_RBO
kfracdb.lge[0].bcd[0].redund:        17 ; 0x031: SCHE=0x1 NUMB=0x1
kfracdb.lge[0].bcd[0].pad:        63903 ; 0x032: 0xf99f
kfracdb.lge[0].bcd[0].KFRCOD_RBO.slot:0 ; 0x034: 0x0000
kfracdb.lge[0].bcd[0].KFRCOD_RBO.pad: 0 ; 0x036: 0x0000
kfracdb.lge[0].bcd[0].KFRCOD_RBO.rb.opcode:1 ; 0x038: 0x0001
kfracdb.lge[0].bcd[0].KFRCOD_RBO.rb.inum:1 ; 0x03a: 0x0001
kfracdb.lge[0].bcd[0].KFRCOD_RBO.rb.iser:8 ; 0x03c: 0x00000008
kfracdb.lge[0].bcd[0].KFRCOD_RBO.rb.pnum:23 ; 0x040: 0x00000017
kfracdb.lge[0].bcd[0].au[0]:         17 ; 0x044: 0x00000011
kfracdb.lge[0].bcd[0].disks[0]:       0 ; 0x048: 0x0000
kfracdb.lge[0].bcd[1].kfbl.blk:       2 ; 0x04c: blk=2
kfracdb.lge[0].bcd[1].kfbl.obj:       4 ; 0x050: file=4
kfracdb.lge[0].bcd[1].kfcn.base:   7949 ; 0x054: 0x00001f0d
kfracdb.lge[0].bcd[1].kfcn.wrap:      0 ; 0x058: 0x00000000
kfracdb.lge[0].bcd[1].oplen:         68 ; 0x05c: 0x0044
kfracdb.lge[0].bcd[1].blkIndex:       2 ; 0x05e: 0x0002
kfracdb.lge[0].bcd[1].flags:         28 ; 0x060: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb.lge[0].bcd[1].opcode:       211 ; 0x062: 0x00d3
kfracdb.lge[0].bcd[1].kfbtyp:        16 ; 0x064: KFBTYP_COD_DATA
kfracdb.lge[0].bcd[1].redund:        17 ; 0x065: SCHE=0x1 NUMB=0x1
kfracdb.lge[0].bcd[1].pad:        63903 ; 0x066: 0xf99f
kfracdb.lge[0].bcd[1].KFRCOD_DATA.offset:65535 ; 0x068: 0xffff
kfracdb.lge[0].bcd[1].KFRCOD_DATA.length:64 ; 0x06a: 0x0040
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[0]:4 ; 0x06c: 0x04
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[1]:1 ; 0x06d: 0x01
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[2]:0 ; 0x06e: 0x00
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[3]:0 ; 0x06f: 0x00
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[4]:149 ; 0x070: 0x95
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[5]:196 ; 0x071: 0xc4
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[6]:163 ; 0x072: 0xa3
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[7]:63 ; 0x073: 0x3f
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[8]:0 ; 0x074: 0x00
kfracdb.lge[0].bcd[1].KFRCOD_DATA.data[9]:0 ; 0x075: 0x00

当磁盘组由于cod recover报错导致磁盘组无法mount时,通常可以通过event 15195 level 604去跳过cod recover,从而mount磁盘组。


最后修改时间:2021-11-04 17:31:50
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论