性能文章>一次非常艰难的drop多个PDB的恢复>

一次非常艰难的drop多个PDB的恢复转载

3周前
173401

导言

 
关于Oracle的性能优化能保证Oracle性能的保障性,本篇给大家介绍的是Oracle的数据被误删后如何恢复的优化。
 

背景

 
在一次恢复中,遇到了一个非常棘手的case,客户环境中的一套rac cdb中原本存在10个PDB在同一个ASM磁盘组中,但误删除了其中6个PDB,并且使用了including datafiles子句。
 
针对此故障做了多种恢复方式的考虑:
 

1.AMDU

 
通常当ASM磁盘组无法mount的时候常常会想到使用AMDU去抽取数据文件,那么此次故障是否可以使用AMDU呢?
 
当然不行了。AMDU抽取a**文件的原理是通过a**文件号找到该文件对应的FILEDIR(a** 1号文件)的kfffde[0-59]找到file extent信息,如果extent个数大于60还需要借助kfffde[60+]指向的INDIRECT的kffixe来获取a** file每个extent所在的disk#,au#,从而完成抽取的。
 
如果a** 1号文件FILEDIR损坏或者清空的情况下,AMDU是无法完成文件抽取的。而drop datafile操作正好会清理掉FILEDIR的kfffde[0-59]和kfffde[60+]指向的INDIRECT的kffixe。
 
另外AMDU还依赖at,ODU cp方式不依赖at,只依赖FILEDIR。
 

2.ODU

 
那么当a** 1号文件FILEDIR损坏或者清空的情况,该如何去恢复呢?这时ODU工具就应该登场了。
 
ODU在a** 1号文件FILEDIR损坏或者清空的情况下,通过配置a**disk.txt,可以扫描该配置文件中所有的磁盘,会产生很多.odu文件,其中一个非常重要的文件是a**_fileext_meta.odu。该文件以最小au也就是1M为1行记录,记录磁盘每个au所在的a**disk#、au#、au_block#,第一个块的rdba、rfile#和block#,数据块大小等信息,相当于通过扫描磁盘建立数据文件的fileext,唯一不同的是FILEDIR记录的是a**文件号,这里记录的是相对文件号,随后即可通过extract命令根据rfile#来按照rdba的是顺序来抽取数据文件,具体操作详见http://www.oracleodu.com/cn/。
 
但是此案例是删除了多个PDB,单纯的使用ODU也无法实现(ODU都不能恢复了,不敢想象),原因是PDB之间会存在相同rdba的情况,也就是说rfile#是一样的。在rdba相同的情况下此时ODU根本不知道数据块是属于哪个PDB哪个数据文件的(除了数据文件头所在的第一个au,因为有且只有数据文件头中存在绝对文件号),从而就无法做出正确的抽取。
 

3.解析ACD和COD

 
想通过对a** metamata的日志记录,找出drop之前的FILEDIR里file extent的信息。
 
ACD是a** 3号文件,全称Active Change Directory,其作用是记录metadata block的变化,相当于a**的redo
 
COD是a** 4号文件,全称Continuing Operation Directory,其作用是记录metadata block中未完成的操作记录,ASM crash时可以恢复这些操作,相当于a**的undo
 
当时连续查看了好几个ACD块,确实记录有a**文件删除extent的记录,如下所示:
 
ACD记录的indirect extent block的改变情况:
kfracdb2.lge[0].bcd[0].kfbl.blk:    323 ; 0x020: blk=323
kfracdb2.lge[0].bcd[0].kfbl.obj:      1 ; 0x024: file=1
kfracdb2.lge[0].bcd[0].kfcn.base:4325033 ; 0x028: 0x0041fea9
kfracdb2.lge[0].bcd[0].kfcn.wrap:     0 ; 0x02c: 0x00000000
kfracdb2.lge[0].bcd[0].oplen:        12 ; 0x030: 0x000c
kfracdb2.lge[0].bcd[0].blkIndex:    323 ; 0x032: 0x0143
kfracdb2.lge[0].bcd[0].flags:        28 ; 0x034: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[0].opcode:      133 ; 0x036: 0x0085
kfracdb2.lge[0].bcd[0].kfbtyp:        4 ; 0x038: KFBTYP_FILEDIR
kfracdb2.lge[0].bcd[0].redund:       17 ; 0x039: SCHE=0x1 NUMB=0x1
kfracdb2.lge[0].bcd[0].pad:       63903 ; 0x03a: 0xf99f
kfracdb2.lge[0].bcd[0].KFFFD_EXT.xtntcnt:7263 ; 0x03c: 0x00001c5f
kfracdb2.lge[0].bcd[0].KFFFD_EXT.xtntblk:61 ; 0x040: 0x003d
kfracdb2.lge[0].bcd[0].KFFFD_EXT.xnum:0 ; 0x042: 0x0000
kfracdb2.lge[0].bcd[0].KFFFD_EXT.xcnt:0 ; 0x044: 0x0000
kfracdb2.lge[0].bcd[0].KFFFD_EXT.setflg:0 ; 0x046: 0x00
kfracdb2.lge[0].bcd[0].KFFFD_EXT.flags:0 ; 0x047: O=0 S=0 S=0 D=0 C=0 I=0 R=0 A=0
kfracdb2.lge[0].bcd[0].au[0]:        10 ; 0x048: 0x0000000a
kfracdb2.lge[0].bcd[0].disks[0]:      0 ; 0x04c: 0x0000
kfracdb2.lge[0].bcd[1].kfbl.blk:2147483663 ; 0x050: blk=15 (indirect)
kfracdb2.lge[0].bcd[1].kfbl.obj:    323 ; 0x054: file=323
kfracdb2.lge[0].bcd[1].kfcn.base:4325033 ; 0x058: 0x0041fea9
kfracdb2.lge[0].bcd[1].kfcn.wrap:     0 ; 0x05c: 0x00000000
kfracdb2.lge[0].bcd[1].oplen:        16 ; 0x060: 0x0010
kfracdb2.lge[0].bcd[1].blkIndex:     15 ; 0x062: 0x000f
kfracdb2.lge[0].bcd[1].flags:        28 ; 0x064: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[1].opcode:      161 ; 0x066: 0x00a1
kfracdb2.lge[0].bcd[1].kfbtyp:       12 ; 0x068: KFBTYP_INDIRECT
kfracdb2.lge[0].bcd[1].redund:       17 ; 0x069: SCHE=0x1 NUMB=0x1
kfracdb2.lge[0].bcd[1].pad:       63903 ; 0x06a: 0xf99f
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xtntblk:3 ; 0x06c: 0x0003
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xnum:3 ; 0x06e: 0x0003
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xcnt:1 ; 0x070: 0x0001
kfracdb2.lge[0].bcd[1].KFFIX_EXT.ub2spare:0 ; 0x072: 0x0000
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xptr[0].au:4294967295 ; 0x074: 0xffffffff
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xptr[0].disk:65535 ; 0x078: 0xffff
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xptr[0].flags:0 ; 0x07a: L=0 E=0 D=0 S=0
kfracdb2.lge[0].bcd[1].KFFIX_EXT.xptr[0].chk:42 ; 0x07b: 0x2a
kfracdb2.lge[0].bcd[1].au[0]:     28230 ; 0x07c: 0x00006e46
kfracdb2.lge[0].bcd[1].disks[0]:      7 ; 0x080: 0x0007
LGE为ACD redo log record,BCD为ACD block change descriptor。改动向量0和1组成的重做记录0,这点和redo基本一样。
 
以上描述了a** file 323的FILEDIR kfffde60所指向的INDIRECT(disk#为28230 au#为7)的kffixe[3]被清空。即a** file号为323的extent号为7263的file extent map被清理。
 
备注:对于indirect,extent#=KFFFD_EXT.xtntcnt=KFFIX_EXT.xnum+60+indirect block#480=3+60+15480=7263,一个indirect block包含480个extent信息。
 
ACD记录的direct extent block变动情况:
ACD记录的direct extent block变动情况:
kfracdb2.lge[12].valid:               1 ; 0x3c4: V=1 B=0 M=0
kfracdb2.lge[12].chgCount:            1 ; 0x3c5: 0x01
kfracdb2.lge[12].len:                68 ; 0x3c6: 0x0044
kfracdb2.lge[12].kfcn.base:     4363270 ; 0x3c8: 0x00429406
kfracdb2.lge[12].kfcn.wrap:           0 ; 0x3cc: 0x00000000
kfracdb2.lge[12].bcd[0].kfbl.blk:   321 ; 0x3d0: blk=321
kfracdb2.lge[12].bcd[0].kfbl.obj:     1 ; 0x3d4: file=1
kfracdb2.lge[12].bcd[0].kfcn.base:4363269 ; 0x3d8: 0x00429405
kfracdb2.lge[12].bcd[0].kfcn.wrap:    0 ; 0x3dc: 0x00000000
kfracdb2.lge[12].bcd[0].oplen:       20 ; 0x3e0: 0x0014
kfracdb2.lge[12].bcd[0].blkIndex:   321 ; 0x3e2: 0x0141
kfracdb2.lge[12].bcd[0].flags:       28 ; 0x3e4: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[12].bcd[0].opcode:     133 ; 0x3e6: 0x0085
kfracdb2.lge[12].bcd[0].kfbtyp:       4 ; 0x3e8: KFBTYP_FILEDIR
kfracdb2.lge[12].bcd[0].redund:      17 ; 0x3e9: SCHE=0x1 NUMB=0x1
kfracdb2.lge[12].bcd[0].pad:      63903 ; 0x3ea: 0xf99f
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xtntcnt:48 ; 0x3ec: 0x00000030
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xtntblk:48 ; 0x3f0: 0x0030
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xnum:48 ; 0x3f2: 0x0030
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xcnt:1 ; 0x3f4: 0x0001
kfracdb2.lge[12].bcd[0].KFFFD_EXT.setflg:0 ; 0x3f6: 0x00
kfracdb2.lge[12].bcd[0].KFFFD_EXT.flags:0 ; 0x3f7: O=0 S=0 S=0 D=0 C=0 I=0 R=0 A=0
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xptr[0].au:4294967295 ; 0x3f8: 0xffffffff
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xptr[0].disk:65535 ; 0x3fc: 0xffff
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xptr[0].flags:0 ; 0x3fe: L=0 E=0 D=0 S=0
kfracdb2.lge[12].bcd[0].KFFFD_EXT.xptr[0].chk:42 ; 0x3ff: 0x2a
kfracdb2.lge[12].bcd[0].au[0]:       10 ; 0x400: 0x0000000a
kfracdb2.lge[12].bcd[0].disks[0]:     0 ; 0x404: 0x0000
 
以上描述了a** file 321的FILEDIR的kfffde[48] extent信息被清空,即a**文件号为321的extent号为48的file extent map被清理。
 
备注:对于direct extent#=KFFFD_EXT.xtntcnt=KFFFD_EXT.xnum=48。
 
但是始终没有看到drop之前的file extent map记录。由于drop datafile已经完成,所以COD也没发现任何有用的信息。
 
正当思路一筹莫展之时,突然发现可以尝试通过ACD记录的AT变更记录找到a**文件的file extent map,这是非常关键的。
 
AT全称Allocation Table,每一块由ASM管理的磁盘都会至少包含一个AT,用来描述磁盘的AU分布情况,AT块的AT条目都代表了磁盘上的一个AU,一旦某个AU被分配/回收,AT表中此条目的内容会被更新,AT条目记录此AU属于的extent号和属于哪一个文件。
 
ACD记录AT块某一个AT条目的变更如下:
 
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            8 ; 0x002: KFBTYP_CHNGDIR
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                    1777 ; 0x004: blk=1777
kfbh.block.obj:                       3 ; 0x008: file=3
kfbh.check:                   918117267 ; 0x00c: 0x36b95b93
kfbh.fcn.base:                  4365702 ; 0x010: 0x00429d86
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfracdb2.aba.seq:                    18 ; 0x000: 0x00000012
kfracdb2.aba.blk:                  1776 ; 0x004: 0x000006f0
kfracdb2.ents:                       23 ; 0x008: 0x0017
kfracdb2.ub2spare:                    0 ; 0x00a: 0x0000
kfracdb2.instNum:                     1 ; 0x00c: 0x00000001
kfracdb2.timestamp:          1004905358 ; 0x010: 2019-4-6 20:22:38
kfracdb2.lge[0].valid:                1 ; 0x014: V=1 B=0 M=0
kfracdb2.lge[0].chgCount:             3 ; 0x015: 0x03
kfracdb2.lge[0].len:                172 ; 0x016: 0x00ac
kfracdb2.lge[0].kfcn.base:      4365703 ; 0x018: 0x00429d87
kfracdb2.lge[0].kfcn.wrap:            0 ; 0x01c: 0x00000000
kfracdb2.lge[0].bcd[0].kfbl.blk:     58 ; 0x020: blk=58
kfracdb2.lge[0].bcd[0].kfbl.obj:2147483656 ; 0x024: disk=8
kfracdb2.lge[0].bcd[0].kfcn.base:4365702 ; 0x028: 0x00429d86
kfracdb2.lge[0].bcd[0].kfcn.wrap:     0 ; 0x02c: 0x00000000
kfracdb2.lge[0].bcd[0].oplen:        24 ; 0x030: 0x0018
kfracdb2.lge[0].bcd[0].blkIndex:     58 ; 0x032: 0x003a
kfracdb2.lge[0].bcd[0].flags:        28 ; 0x034: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[0].opcode:       66 ; 0x036: 0x0042
kfracdb2.lge[0].bcd[0].kfbtyp:        3 ; 0x038: KFBTYP_ALLOCTBL
kfracdb2.lge[0].bcd[0].redund:       18 ; 0x039: SCHE=0x1 NUMB=0x2
kfracdb2.lge[0].bcd[0].pad:       63903 ; 0x03a: 0xf99f
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.curidx:2888 ; 0x03c: 0x0b48
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.nxtidx:8 ; 0x03e: 0x0008
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.prvidx:8 ; 0x040: 0x0008
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.asz:0 ; 0x042: KFDASZ_1X
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.frag:0 ; 0x043: 0x00
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.total:0 ; 0x044: 0x0000
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.free:0 ; 0x046: 0x0000
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.fnum:4294967295 ; 0x048: 0xffffffff
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.xnum:4294967295 ; 0x04c: 0xffffffff
kfracdb2.lge[0].bcd[0].KFDAT_DEALLOC.flags:0 ; 0x050: 0x00000000
kfracdb2.lge[0].bcd[0].au[0]:         0 ; 0x054: 0x00000000
kfracdb2.lge[0].bcd[0].au[1]:        11 ; 0x058: 0x0000000b
kfracdb2.lge[0].bcd[0].disks[0]:      8 ; 0x05c: 0x0008
kfracdb2.lge[0].bcd[0].disks[1]:      8 ; 0x05e: 0x0008
kfracdb2.lge[0].bcd[1].kfbl.blk:2147483659 ; 0x060: blk=11 (indirect)
kfracdb2.lge[0].bcd[1].kfbl.obj:    320 ; 0x064: file=320
kfracdb2.lge[0].bcd[1].kfcn.base:4365702 ; 0x068: 0x00429d86
kfracdb2.lge[0].bcd[1].kfcn.wrap:     0 ; 0x06c: 0x00000000
kfracdb2.lge[0].bcd[1].oplen:        16 ; 0x070: 0x0010
kfracdb2.lge[0].bcd[1].blkIndex:     11 ; 0x072: 0x000b
kfracdb2.lge[0].bcd[1].flags:        28 ; 0x074: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[1].opcode:      163 ; 0x076: 0x00a3
kfracdb2.lge[0].bcd[1].kfbtyp:       12 ; 0x078: KFBTYP_INDIRECT
kfracdb2.lge[0].bcd[1].redund:       17 ; 0x079: SCHE=0x1 NUMB=0x1
kfracdb2.lge[0].bcd[1].pad:       63903 ; 0x07a: 0xf99f
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xtntblk:0 ; 0x07c: 0x0000
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xnum:313 ; 0x07e: 0x0139
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xcnt:1 ; 0x080: 0x0001
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.ub2spare:0 ; 0x082: 0x0000
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xptr[0].au:4294967292 ; 0x084: 0xfffffffc
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xptr[0].disk:8 ; 0x088: 0x0008
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xptr[0].flags:0 ; 0x08a: L=0 E=0 D=0 S=0
kfracdb2.lge[0].bcd[1].KFFIX_PEXT.xptr[0].chk:33 ; 0x08b: 0x21
kfracdb2.lge[0].bcd[1].au[0]:      8360 ; 0x08c: 0x000020a8
kfracdb2.lge[0].bcd[1].disks[0]:      0 ; 0x090: 0x0000
kfracdb2.lge[0].bcd[2].kfbl.blk:      2 ; 0x094: blk=2
kfracdb2.lge[0].bcd[2].kfbl.obj:      4 ; 0x098: file=4
kfracdb2.lge[0].bcd[2].kfcn.base:4365702 ; 0x09c: 0x00429d86
kfracdb2.lge[0].bcd[2].kfcn.wrap:     0 ; 0x0a0: 0x00000000
kfracdb2.lge[0].bcd[2].oplen:         8 ; 0x0a4: 0x0008
kfracdb2.lge[0].bcd[2].blkIndex:      2 ; 0x0a6: 0x0002
kfracdb2.lge[0].bcd[2].flags:        28 ; 0x0a8: F=0 N=0 F=1 L=1 V=1 A=0 C=0
kfracdb2.lge[0].bcd[2].opcode:      211 ; 0x0aa: 0x00d3
kfracdb2.lge[0].bcd[2].kfbtyp:       16 ; 0x0ac: KFBTYP_COD_DATA
kfracdb2.lge[0].bcd[2].redund:       17 ; 0x0ad: SCHE=0x1 NUMB=0x1
kfracdb2.lge[0].bcd[2].pad:       63903 ; 0x0ae: 0xf99f
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.offset:60 ; 0x0b0: 0x003c
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.length:4 ; 0x0b2: 0x0004
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.data[0]:45 ; 0x0b4: 0x2d
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.data[1]:0 ; 0x0b5: 0x00
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.data[2]:0 ; 0x0b6: 0x00
kfracdb2.lge[0].bcd[2].KFRCOD_DATA.data[3]:128 ; 0x0b7: 0x80
kfracdb2.lge[0].bcd[2].au[0]:         6 ; 0x0b8: 0x00000006
kfracdb2.lge[0].bcd[2].disks[0]:      1 ; 0x0bc: 0x0001
 

从ACD记录AT条目的变更记录得到了下列信息:

KFDAT_DEALLOC:回收AU

  • disk#=8
  • AT block#=58
  • a** file#=320
  • indirect block#=11
  • indirect kffixe=KFFIX_PEXT.xnum=313
  • curidx=2888
 
对于file ext#有根据direct,indirect存在两种算法,之前也提到过:
 
 
  • direct ext#=xnum
  • indirect ext#=60+xnum+indirect block#*480
 
所以通过此AT条目变更记录可以得到:
 
  • a**file#=320
  • fileext#=60+313+11*480=5653
  • disk#=8
  • au#=(block#-2)*448+(curidx/8-5)=(58-2)*448+(2888/8-5)=25444
 
完美的还原了file 320 extent 5653的extmap。即a**文件320的5653号extent在磁盘8的25444号au上。
 
对于计算au#的公式这里解释一下,用于通过ACD记录的AT条目变更计算au#。计算au#,其实就是计算该AT条目在整个AT表的位置。
 
  • 每个AT块可以管理448个AT条目
  • 每个磁盘的第一个stride,由于这个case磁盘并不是特别大所以只存在一个stride,磁盘头会记录AT的0号块位置(kfdhdb.altlocn=2),即blk=2为AT的0号块
  • curidx为AT块内偏移量(该AT条目在AT块内的偏移量)
  • AT块内每个AT条目占用8个offset
  • AT块头部(不算a**元数据块头)到AT块第一个AT条目的offset是40
 
所以au#=(block#-kfdhdb.altlocn)*448+(curidx-40)/8=(block#-2)448+(curidx/8-5)。
 
由此就通过AMDU抽取出a** 3号文件ACD,遍历ACD元数据块筛选出drop PDB的时间戳AT条目的所有变更记录,则可以完全的恢复被drop掉的a** file的extent map。当然这个需要写代码来实现(我用shell实现了一个简陋版)。再重新构造a**_fileext_meta.odu文件,用唯一的a**file#去替代可重复的rfile#,就能够使用ODU完美的将删除的数据文件全部抽取出来了。
 
shell如下:
 

 

TIME,AT BLOCK#,DISK#,curidx,ASM FILE#,XNUM,INDIRECT BLOCK#

#!/bin/bash

file_name=$1
max_bs=`du -b $file_name|awk '{ print $1}'`
max_blkn=`bc <<< "$max_bs/4096 - 1"`

for i in $(seq 0 $max_blkn)
do
    isHave=`kfed read $file_name blkn=$i|grep "KFBTYP_ALLOCTBL"|wc -l`
    if [ $isHave > 0 ]
    then
    	time_state=`kfed read $file_name blkn=$i|grep "kfracdb2\.timestamp"|awk '{ printf $(NF-1)" "$NF }'`
    	for j in `kfed read $file_name blkn=$i|grep "KFBTYP_ALLOCTBL"|awk '{ print $1 }'`
    	do
            k=`echo $j|awk -F"[][]" '{ print $2 }'`
            m=`echo $j|awk -F"[][]" '{ print $4 }'`
            n=`expr $m + 1`
            echo -e "$time_state\c"
            kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\].bcd\[$m\]\.kfbl\.blk"|awk -F'[ =]' '{ printf " "$NF }'
            kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\].bcd\[$m\]\.kfbl\.obj"|awk -F'[ =]' '{ printf " "$NF }'
            kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\].bcd\[$m\]\.KFDAT_DEALLOC\.curidx"|awk -F'[].: ;[]' '{ printf " "$10 }'
            for i in `kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\].bcd\[$n\]\.kfbtyp"|awk -F'[ :;.]' '{ print $NF }'`
            do
            if [ $i = "KFBTYP_FILEDIR" ]
            then
            		kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\].bcd\[$n\]\.kfbl\.blk"|awk -F'[ =]' '{ printf " "$NF }'
              kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\].bcd\[$n\]\.KFFFD_EXT\.xnum"|awk -F'[ :;.]' '{ print " "$6" -1" }'
              kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\].bcd\[$n\]\.KFFFD_PEXT\.xnum"|awk -F'[ :;.]' '{ print " "$6" -1" }'
            else
            		kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\]\.bcd\[$n\]\.kfbl\.obj"|awk -F'[ :;.=]' '{ printf " "$NF }'
              kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\]\.bcd\[$n\]\.KFFIX_PEXT\.xnum"|awk -F'[ :;.]' '{ printf " "$6 }'
              kfed read $file_name blkn=$i|grep "kfracdb2\.lge\[$k\].bcd\[$n\]\.kfbl\.blk"|awk -F'[ =]' '{ print " "$(NF-1) }'
            fi
            done
        done
    fi
done

 

更多思考:

更多关于Oracle的优化,大家可以阅读以下内容加深学习!

Oracle实战优化!一次gc buffer busy acquire诊断

 

分类:
标签:
请先登录,再评论

暂无回复,快来写下第一个回复吧~

为你推荐

构建企业级业务高可用的延时消息中台
业务场景剖析公司业务系统(比如:电商系统)中有大量涉及定时任务的业务场景,例如:实现买卖双方在线沟通的IM系统,为了确保接收方能够收到消息,服务端一般都会有重试策略,即服务端在消息发出的一段时间内,如
5G时代,如何彻底搞定海量数据库的设计与实践
5G时代,业务数据越来越丰富,业务使用MySQL数据库作为后台存储,存储引擎使用InnoDB,会带来哪些挑战?如何针对公司业务特点及MySQL数据库特性,制定若干数据库使用规范供一线RD在设计业务时参
Redis client链接池配置不当引起的频繁full gc
现象笔者负责的一个RPC服务就是简单的从Redis Cluster中读取数据,然后返回给上游。理论上该服务的对象大部分都应该是朝生夕死的,但是笔者查看gc log 的时候发现 age =2 的对象还真
记一次线上请求偶尔变慢的排查
前言最近解决了个比较棘手的问题,由于排查过程挺有意思,于是就以此为素材写出了本篇文章。 Bug现场这是一个偶发的性能问题。在每天几百万比交易请求中,平均耗时大约为300ms,但总有那么100多笔会超过
MySQL之KEY分区引发的血案
需求背景业务表tb_image部分数据如下所示,其中id唯一,image_no不唯一。image_no表示每个文件的编号,每个文件在业务系统中会生成若干个文件,每个文件的唯一ID就是字段id:业务表t
记一次中间件导致的慢SQL排查过程
前言最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章。 Bug现场我们的分库分表中间件在经过一年的沉淀之
Oracle实战优化!一次gc buffer busy acquire诊断
本案例来自某客户两节点rac的一次生产故障,现象是大面积的gc buffer busy acquire导致业务瘫痪。首先查看1节点AWR头部信息和load profile:1节点AWR 得到的关键信息点:对于LCPU 256的系统,AAS=13379.42/59.91
一次非常艰难的drop多个PDB的恢复
导言 关于Oracle的性能优化能保证Oracle性能的保障性,本篇给大家介绍的是Oracle的数据被误删后如何恢复的优化。 背景 在一次恢复中,遇到了一个非常棘手的case,客户环境中的一套rac cdb中原本存在10个PDB在同一个ASM磁盘组中,但误删