本站文章除注明转载外，均为本站原创： 转载自love wife & love life —Roger 的Oracle技术博客
本文链接地址: 某网友的数据库TB 数据库恢复
这是一个网友的数据库,据说是非归档，不知道为啥主机强制重启后就无法打开数据库。首先我们来看下他这里在open的时候所报的错误：
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的例子，供参考：
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 跟踪，得到如下类似信息：
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信息，发现确实是存在活动事务，如下所示：
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信息：
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，发现如下：
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地址，其实是比较容易让人产生错误判断的：
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，如下所示：
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跟踪定位到了有问题的数据块，如下所示：
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 内容如下：
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的过程，供参考：
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打开了数据库，比较顺利。
对于通过非常规手段打开的数据库，我们建议进行导出重建，比较保险一些。到此结束吧！
Related posts: