某网友的数据库TB 数据库恢复
本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客
本文链接地址: 某网友的数据库TB 数据库恢复
这是一个网友的数据库,据说是非归档,不知道为啥主机强制重启后就无法打开数据库。首先我们来看下他这里在open的时候所报的错误:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
SQL> alter database open ; alter database open * 第 1 行出现错误: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [2662], [3429], [661240178], [3429], [661259589], [12583040], [], [], [], [], [], [] ORA-00600: internal error code, arguments: [2662], [3429], [661240177], [3429], [661259589], [12583040], [], [], [], [], [], [] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2662], [3429], [661240173], [3429], [661259589], [12583040], [], [], [], [], [], [] 进程 ID: 14048 会话 ID: 1072 序列号: 3 |
对于这个错误而言,我想大家都非常熟悉了,不就是可以直接推进SCN 就可以解决吗?根据我们常规的恢复方式,那么肯定是 alter session set events ‘10015 trace name adjust_scn level 13697’;
最开始也让该网友才有这样的方式进行尝试,得到的回复是数据库是11.2.0.4。这就比较悲剧了,因为从oracle 11.2.0.3版本开始Oracle已经不再支持通过这种event或者隐含参数的方式来推进数据库SCN了。 唯一的方式就是oradebug 修改数据库scn。
据说这是windows环境,那么修改数据库SCN就相对麻烦一些。如下是我自己做的一个windows 虚拟机修改SCN的例子,供参考:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
SQL> oradebug DUMPvar SGA kcsgscn_ kcslf kcsgscn_ [149876FA0, 149876FD0) = 00000002 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 49876C30 00000001 SQL> alter database open; 数据库已更改。 SQL> select checkpoint_change# from v$datafile; CHECKPOINT_CHANGE# ------------------ 957197 957197 957197 957197 SQL> oradebug DUMPvar SGA kcsgscn_ kcslf kcsgscn_ [149876FA0, 149876FD0) = 000E9C20 00000000 00000000 00000000 00000048 00000000 00000000 00000000 00000000 00000000 49876C30 00000001 SQL> SQL> oradebug poke 0x149876FA4 4 0x00000002 BEFORE: [149876FA4, 149876FA8) = 00000000 AFTER: [149876FA4, 149876FA8) = 00000002 SQL> oradebug DUMPvar SGA kcsgscn_ kcslf kcsgscn_ [149876FA0, 149876FD0) = 000E9C43 00000002 00000000 00000000 00000069 00000000 00000000 00000000 00000000 00000000 49876C30 00000001 SQL> alter system checkpoint; 系统已更改。 SQL> select checkpoint_change# from v$datafile; CHECKPOINT_CHANGE# ------------------ 8590892105 8590892105 8590892105 8590892105 SQL> shutdown immediate 数据库已经关闭。 已经卸载数据库。 ORACLE 例程已经关闭。 SQL> |
我想大家已经知道,其实windows x64环境而言,修改SCN也很简单,前面4个byte是bas scn,后面4个byte是wrap scn;因此这里如果我们要推进scn,那么直接修改wrap 即可。直接修改wrap scn值需要后移动4个offset,然后直接修改即可。
不幸的是,我告诉网文这种博客中有类似的修复例子,他修改之后仍然无法打开数据库,错误仍然一样。比较麻烦了,对于比较难的问题对于我而言是比较有吸引力的。
首先让对方做个10046 trace 跟踪,得到如下类似信息:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
WAIT #92370008: nam='db file sequential read' ela= 7059 file#=1 block#=128 blocks=1 obj#=0 tim=110663534040 WAIT #92370008: nam='db file sequential read' ela= 5317 file#=1 block#=539 blocks=1 obj#=0 tim=110663539502 ...... ===================== CLOSE #410498856:c=0,e=60,dep=1,type=0,tim=110663542332 WAIT #92370008: nam='db file sequential read' ela= 262 file#=1 block#=225 blocks=1 obj#=15 tim=110663542646 ===================== PARSING IN CURSOR #410498856 len=142 dep=1 uid=0 oct=3 lid=0 tim=110663543442 hv=361892850 ad='e37e371c0' sqlid='7bd391hat42zk' select /*+ rule */ name,file#,block#,status$,user#,undosqn,xactsqn,scnbas,scnwrp,DECODE(inst#,0,NULL,inst#),ts#,spare1 from undo$ where us#=:1 END OF STMT PARSE #410498856:c=0,e=526,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,plh=0,tim=110663543440 BINDS #410498856: Bind#0 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=1877b2e0 bln=22 avl=02 flg=05 value=1 EXEC #410498856:c=0,e=845,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=3,plh=906473769,tim=110663544412 WAIT #410498856: nam='db file sequential read' ela= 211 file#=1 block#=321 blocks=1 obj#=34 tim=110663544688 FETCH #410498856:c=0,e=302,p=1,cr=2,cu=0,mis=0,r=1,dep=1,og=3,plh=906473769,tim=110663544757 STAT #410498856 id=1 cnt=1 pid=0 pos=1 obj=15 op='TABLE ACCESS BY INDEX ROWID UNDO$ (cr=2 pr=1 pw=0 time=297 us)' STAT #410498856 id=2 cnt=1 pid=1 pos=1 obj=34 op='INDEX UNIQUE SCAN I_UNDO1 (cr=1 pr=1 pw=0 time=285 us)' CLOSE #410498856:c=0,e=5,dep=1,type=0,tim=110663544849 WAIT #92370008: nam='db file sequential read' ela= 5460 file#=3 block#=128 blocks=1 obj#=0 tim=110663550361 |
从上面的信息来看,目前数据库在open时在执行CURSOR# 92370008时处于wait状态,然后失败。
从上述信息不难看出,这里涉及到几个block:file 1 block 225;file 1 block 539;file 3 block 128.
很明显file 1 block 225 是undo$。而file 3也是undo文件。
让对方提供dump file 1 block 128信息,发现确实是存在活动事务,如下所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
buffer tsn: 0 rdba: 0x00400080 (1/128) scn: 0x0d65.2769b95b seq: 0x01 flg: 0x04 tail: 0xb95b0e01 frmt: 0x02 chkval: 0xb308 type: 0x0e=KTU UNDO HEADER W/UNLIMITED EXTENTS Hex dump of block: st=0, typ_found=1 Dump of memory from 0x000000000570AA00 to 0x000000000570CA00 00570AA00 0000A20E 00400080 2769B95B 04010D65 [......@.[.i'e. 。。。。。 index state cflags wrap# uel scn dba parent-xid nub stmt_num ------------------------------------------------------------------------------------------------ 0x00 9 0x00 0x0020 0x0003 0x0d4c.ff0b433f 0x0040021a 0x0000.000.00000000 0x00000001 0x00000000 ...... 0x1a 10 0x00 0x0020 0x0003 0x0d65.2769b95b 0x0040021b 0x0000.000.00000000 0x00000001 0x00000000 0x1b 9 0x00 0x001f 0x0002 0x0d4b.c0108b44 0x00400219 0x0000.000.00000000 0x00000001 0x00000000 0x1c 9 0x00 0x001f 0x001f 0x0d4b.c0108ab9 0x00400218 0x0000.000.00000000 0x00000001 0x00000000 ...... 0x60 9 0x00 0x001f 0x0005 0x0d4c.ff0b4349 0x0040021a 0x0000.000.00000000 0x00000001 0x00000000 0x61 9 0x00 0x001f 0x005d 0x0d4c.ff0b4337 0x0040021a 0x0000.000.00000000 0x00000001 0x00000000 |
很明显,上面第0x1a 事务是活动事务,而涉及到的块地址为:0x0040021b
同时如下是file 3 block 128 的dump信息:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
index state cflags wrap# uel scn dba parent-xid nub stmt_num cmt ------------------------------------------------------------------------------------------------ 0x00 9 0x00 0x29b7f 0x0014 0x0d65.2769f946 0x00c05312 0x0000.000.00000000 0x00000001 0x00000000 1451269228 0x01 9 0x00 0x29b8c 0x0018 0x0d65.276a039a 0x00c05314 0x0000.000.00000000 0x00000001 0x00000000 1451269303 0x02 9 0x00 0x29b78 0x0009 0x0d65.2769f84d 0x00c05311 0x0000.000.00000000 0x00000001 0x00000000 1451269223 0x03 9 0x00 0x29b6d 0x0021 0x0d65.2769fd49 0x00c05313 0x0000.000.00000000 0x00000001 0x00000000 1451269263 0x04 9 0x00 0x29b84 0x001f 0x0d65.2769fa76 0x00c05312 0x0000.000.00000000 0x00000001 0x00000000 1451269236 ..... 0x1f 9 0x00 0x29b5c 0x000b 0x0d65.2769fb1e 0x00c05312 0x0000.000.00000000 0x00000001 0x00000000 1451269247 0x20 9 0x00 0x29b84 0x001e 0x0d65.276a04b8 0x00c05314 0x0000.000.00000000 0x00000001 0x00000000 1451269311 0x21 9 0x00 0x29b76 0x0007 0x0d65.2769fd90 0x00c05313 0x0000.000.00000000 0x00000001 0x00000000 1451269264 EXT TRN CTL:: usn: 1 sp1:0x00000000 sp2:0x00000000 sp3:0x00000000 sp4:0x00000000 sp5:0x00000000 sp6:0x00000000 sp7:0x00000000 sp8:0x00000000 ...... |
从dump 来看,file 3 block 128 并没有问题。那么也就是问题可能出在前面file 1 block 128和file 1 block 539 这2个block上。
进一步dump file 1 block 539,发现如下:
1 2 3 4 5 |
buffer tsn: 0 rdba: 0x0040021b (1/539) scn: 0x0d65.2769b95b seq: 0x01 flg: 0x04 tail: 0xb95b0201 frmt: 0x02 chkval: 0x10a0 type: 0x02=KTU UNDO BLOCK Hex dump of block: st=0, typ_found=1 ...... |
很明显,这是一个undo block,而且是系统回滚段。而最前面的2662 错误的rdba地址,其实是比较容易让人产生错误判断的:
1 2 3 4 5 6 7 8 |
SQL> select 2 dbms_utility.data_block_address_block(12583040) "BLOCK", 3 dbms_utility.data_block_address_file(12583040) "FILE" 4 from dual; BLOCK FILE ---------- ---------- 128 3 |
因此,我们可以断定,数据库无法open,那么跟undo有关系,而且是system 回滚段。
接着让对同时设置如下event并同时设置_corrupted_rollback_segments参数。:alter system set event=’10513 trace name context forever,level 2 : 10512 trace name context forever,level 1: 10511 trace name context forever,level 2: 10510 trace name context forever,level 1′ scope=spfile;
这里需要说明一下,windows环境比较麻烦,可以借用dd fow windows版本进行copy block,然后过滤得到回滚段信息,并全部进行屏蔽。
尽管把我的杀手锏都告诉了对方,得到的答复是仍然无法打开数据库,报错ORA-01555,如下所示:
1 2 3 4 5 6 7 8 9 |
SQL> alter database open resetlogs; alter database open resetlogs * 第 1 行出现错误: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00604: error occurred at recursive SQL level 1 ORA-01555: snapshot too old: rollback segment number with name "" too small 进程 ID: 14728 会话 ID: 1072 序列号: 3 |
对于这个错误,我深有体会,本质上是因为open时访问的数据块需要利用undo而出现的错误。换句话讲,该block存在活动事务。
再次建议通过10046 event跟踪定位到了有问题的数据块,如下所示:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
CLOSE #91852808:c=0,e=10,dep=2,type=3,tim=320065736255 ===================== PARSING IN CURSOR #652929312 len=102 dep=1 uid=0 oct=3 lid=0 tim=320065736448 hv=3967354608 ad='e17b60c00' sqlid='axmdf8vq7k1rh' select increment$,minvalue,maxvalue,cycle#,order$,cache,highwater,audit$,flags from seq$ where obj#=:1 END OF STMT PARSE #652929312:c=0,e=10981,p=1,cr=29,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=320065736448 BINDS #652929312: Bind#0 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=26e966f0 bln=22 avl=03 flg=05 value=1229 EXEC #652929312:c=0,e=720,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=2203911306,tim=320065737260 WAIT #652929312: nam='db file sequential read' ela= 168 file#=1 block#=705 blocks=1 obj#=79 tim=320065737468 WAIT #652929312: nam='db file sequential read' ela= 9242 file#=1 block#=665 blocks=1 obj#=74 tim=320065746793 FETCH #652929312:c=0,e=9589,p=2,cr=2,cu=0,mis=0,r=0,dep=1,og=4,plh=2203911306,tim=320065746870 STAT #652929312 id=1 cnt=0 pid=0 pos=1 obj=74 op='TABLE ACCESS BY INDEX ROWID SEQ$ (cr=0 pr=0 pw=0 time=4 us)' STAT #652929312 id=2 cnt=1 pid=1 pos=1 obj=79 op='INDEX UNIQUE SCAN I_SEQ1 (cr=1 pr=1 pw=0 time=252 us)' ORA-00604: ֝ک SQL ܶҰ 1 ԶЖխϳ ORA-01555: ࠬ֕ڽ߉: ܘۅ (ĻԆΪ "") ڽС ORA-00604: ֝ک SQL ܶҰ 1 ԶЖխϳ ORA-01555: ࠬ֕ڽ߉: ܘۅ (ĻԆΪ "") ڽС ...... EXEC #91860440:c=764405,e=3108794,p=207,cr=4638,cu=43,mis=0,r=0,dep=0,og=1,plh=0,tim=320067880179 ERROR #91860440:err=1092 tim=320067880257 |
从上面的信息来看,file 1 block 665 和 block 705 存在异常。 建议对方进行bbed修改,但是。。。。。。
通过对上述2个block 的dump 内容如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 |
seg/obj: 0x4f csc: 0xd4f.c723a2d itc: 2 flg: - typ: 2 - INDEX fsl: 0 fnx: 0x0 ver: 0x01 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x0000.000.00000000 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000 0x02 0x000b.00d.000721f5 0x00c00a77.44c3.27 --U- 1 fsc 0x0000.0c723a2e Leaf block dump =============== header address 90745436=0x568aa5c kdxcolev 0 KDXCOLEV Flags = - - - kdxcolok 0 kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y kdxconco 1 kdxcosdc 0 kdxconro 282 kdxcofbo 600=0x258 kdxcofeo 3625=0xe29 kdxcoavs 3883 kdxlespl 0 kdxlende 0 kdxlenxt 0=0x0 kdxleprv 0=0x0 kdxledsz 6 kdxlebksz 8036 .... row#281[3625] flag: ------, lock: 2, len=13, data:(6): 00 40 02 9b 00 5c col 0; len 4; (4): c3 0b 1a 38 Object id on Block? Y seg/obj: 0x4a csc: 0xd65.27694f07 itc: 2 flg: - typ: 1 - DATA fsl: 0 fnx: 0x0 ver: 0x01 Itl Xid Uba Flag Lck Scn/Fsc 0x01 0x000b.017.001daa38 0x00c0246f.4f3d.40 --U- 1 fsc 0x0000.2769dbd2 0x02 0x000b.012.001da924 0x00c048f5.4f2e.1a --U- 1 fsc 0x0000.27694f08 bdba: 0x00400299 data_block_dump,data header at 0x568aa5c =============== tsiz: 0x1fa0 hsiz: 0xd6 pbl: 0x0568aa5c 76543210 flag=-------- ntab=1 nrow=98 frre=-1 fsbo=0xd6 fseo=0x280 avsp=0x34e tosp=0x34e ..... tab 0, row 64, @0x42a tl: 67 fb: --H-FL-- lb: 0x2 cc: 10 col 0: [ 3] c2 3c 44 col 1: [ 2] c1 02 col 2: [ 2] c1 02 col 3: [ 6] c5 2b 5f 61 49 60 col 4: [ 1] 80 col 5: [ 1] 80 col 6: [ 2] c1 0b col 7: [ 4] c3 23 2d 0e col 8: [32] 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d col 9: [ 1] 80 ...... tab 0, row 67, @0xcf7 tl: 76 fb: --H-FL-- lb: 0x1 cc: 10 col 0: [ 3] c2 3d 45 col 1: [ 2] c1 02 col 2: [ 2] c1 02 col 3: [15] ce 64 64 64 64 64 64 64 64 64 64 64 64 64 64 col 4: [ 1] 80 col 5: [ 1] 80 col 6: [ 2] c1 15 col 7: [ 4] c3 39 0f 45 col 8: [32] 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d col 9: [ 1] 80 .... |
好人做到底,就虚拟机帮忙修改一下把,如下是手工提交事务修改block的过程,供参考:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 |
BBED> p ktbbh.ktbbhitl[1].ktbitflg -------------------------- ub2 ktbitflg @84 0x2001 (KTBFUPB) BBED> modify /x 0080 Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) y File: /recover/SYSTEM01.DBF (1) Block: 705 Offsets: 84 to 85 Dba:0x004002c1 ------------------------------------------------------------------------ 0080 <32 bytes per line> BBED> d /v offset 3715 count 20 File: /recover/SYSTEM01.DBF (1) Block: 705 Offsets: 3715 to 3734 Dba:0x004002c1 ------------------------------------------------------- 00000002 0040029b 005c04c3 0b1a3800 l .....@...\....8. 00004002 l ..@. <16 bytes per line> BBED> modify /x 00 offset 3718 File: /recover/SYSTEM01.DBF (1) Block: 705 Offsets: 3718 to 3737 Dba:0x004002c1 ------------------------------------------------------------------------ 00004002 9b005c04 c30b1a38 00000040 029b005b <32 bytes per line> BBED> sum apply Check value for File 1, Block 705: current = 0x1aef, required = 0x1aef BBED> verify DBVERIFY - Verification starting FILE = /recover/SYSTEM01.DBF BLOCK = 705 DBVERIFY - Verification complete Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 1 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 BBED> set file 1 block 665 FILE# 1 BLOCK# 665 BBED> p ktbbh struct ktbbh, 72 bytes @20 ub1 ktbbhtyp @20 0x01 (KDDBTDATA) union ktbbhsid, 4 bytes @24 ub4 ktbbhsg1 @24 0x0000004a ub4 ktbbhod1 @24 0x0000004a struct ktbbhcsc, 8 bytes @28 ub4 kscnbas @28 0x27694f07 ub2 kscnwrp @32 0x0d65 b2 ktbbhict @36 2 ub1 ktbbhflg @38 0x02 (NONE) ub1 ktbbhfsl @39 0x00 ub4 ktbbhfnx @40 0x00000000 struct ktbbhitl[0], 24 bytes @44 struct ktbitxid, 8 bytes @44 ub2 kxidusn @44 0x000b ub2 kxidslt @46 0x0017 ub4 kxidsqn @48 0x001daa38 struct ktbituba, 8 bytes @52 ub4 kubadba @52 0x00c0246f ub2 kubaseq @56 0x4f3d ub1 kubarec @58 0x40 ub2 ktbitflg @60 0x2001 (KTBFUPB) union _ktbitun, 2 bytes @62 b2 _ktbitfsc @62 0 ub2 _ktbitwrp @62 0x0000 ub4 ktbitbas @64 0x2769dbd2 struct ktbbhitl[1], 24 bytes @68 struct ktbitxid, 8 bytes @68 ub2 kxidusn @68 0x000b ub2 kxidslt @70 0x0012 ub4 kxidsqn @72 0x001da924 struct ktbituba, 8 bytes @76 ub4 kubadba @76 0x00c048f5 ub2 kubaseq @80 0x4f2e ub1 kubarec @82 0x1a ub2 ktbitflg @84 0x2001 (KTBFUPB) union _ktbitun, 2 bytes @86 b2 _ktbitfsc @86 0 ub2 _ktbitwrp @86 0x0000 ub4 ktbitbas @88 0x27694f08 BBED> modify /x 0080 File: /recover/SYSTEM01.DBF (1) Block: 665 Offsets: 60 to 61 Dba:0x00400299 ------------------------------------------------------------------------ 0080 <32 bytes per line> BBED> modify /x 0080 offset 84 File: /recover/SYSTEM01.DBF (1) Block: 665 Offsets: 84 to 85 Dba:0x00400299 ------------------------------------------------------------------------ 0080 <32 bytes per line> BBED> sum apply Check value for File 1, Block 665: current = 0xe6ab, required = 0xe6ab BBED> verify DBVERIFY - Verification starting FILE = /recover/SYSTEM01.DBF BLOCK = 665 Block Checking: DBA = 4194969, Block Type = KTB-managed data block data header at 0xb7e9125c kdbchk: row locked by non-existent transaction table=0 slot=64 lockid=2 ktbbhitc=2 Block 665 failed with check code 6101 DBVERIFY - Verification complete Total Blocks Examined : 1 Total Blocks Processed (Data) : 1 Total Blocks Failing (Data) : 1 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 BBED> map File: /recover/SYSTEM01.DBF (1) Block: 665 Dba:0x00400299 ------------------------------------------------------------ KTB Data Block (Table/Cluster) struct kcbh, 20 bytes @0 struct ktbbh, 72 bytes @20 struct kdbh, 14 bytes @92 struct kdbt[1], 4 bytes @106 sb2 kdbr[98] @110 ub1 freespace[426] @306 ub1 rowdata[7456] @732 ub4 tailchk @8188 BBED> p *kdbr[64] rowdata[426] ------------ ub1 rowdata[426] @1158 0x2c BBED> x /rncccccccccccccccccccccc rowdata[426] @1158 ------------ flag@1158: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@1159: 0x02 cols@1160: 10 col 0[3] @1161: 5967 col 1[2] @1165: .. col 2[2] @1168: .. col 3[6] @1171: .+_aI` col 4[1] @1178: . col 5[1] @1180: . col 6[2] @1182: .. col 7[4] @1185: .#-. col 8[32] @1190: -------------------------------- col 9[1] @1223: . BBED> d /v offset 1159 count 1 File: /recover/SYSTEM01.DBF (1) Block: 665 Offsets: 1159 to 1159 Dba:0x00400299 ------------------------------------------------------- 02 l . <16 bytes per line> BBED> modify /x 00 offset 1159 File: /recover/SYSTEM01.DBF (1) Block: 665 Offsets: 1159 to 1159 Dba:0x00400299 ------------------------------------------------------------------------ 00 <32 bytes per line> BBED> p *kdbr[67] rowdata[2679] ------------- ub1 rowdata[2679] @3411 0x2c BBED> x /rccccccccccccccccccc rowdata[2679] @3411 ------------- flag@3411: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@3412: 0x01 cols@3413: 10 col 0[3] @3414: .=E col 1[2] @3418: .. col 2[2] @3421: .. col 3[15] @3424: .dddddddddddddd col 4[1] @3440: . col 5[1] @3442: . col 6[2] @3444: .. col 7[4] @3447: .9.E col 8[32] @3452: -------------------------------- col 9[1] @3485: . BBED> modify /x 00 offset 3412 File: /recover/SYSTEM01.DBF (1) Block: 665 Offsets: 3412 to 3412 Dba:0x00400299 ------------------------------------------------------------------------ 00 <32 bytes per line> BBED> sum apply Check value for File 1, Block 665: current = 0xe4aa, required = 0xe4aa BBED> verify DBVERIFY - Verification starting FILE = /recover/SYSTEM01.DBF BLOCK = 665 DBVERIFY - Verification complete Total Blocks Examined : 1 Total Blocks Processed (Data) : 1 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 |
修改完毕后,然后通过如下类似的dd命令替换掉system文件中的问题block:
dd if=blk_665.665 of=SYSTEM01.DBF seek=665 bs=8192 count=1 conv=notrunc
dd if=blk_705.705 of=SYSTEM01.DBF seek=705 bs=8192 count=1 conv=notrunc
据说替换掉block后,最后recover 一把,就直接open打开了数据库,比较顺利。
对于通过非常规手段打开的数据库,我们建议进行导出重建,比较保险一些。到此结束吧!
Leave a Reply
You must be logged in to post a comment.