oracle数据库TB 数据恢复方法

时间：2022-06-29 09:42:23 编辑：袖梨来源：一聚教程网

这是一个网友的数据库,据说是非归档，不知道为啥主机强制重启后就无法打开数据库。首先我们来看下他这里在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 [email protected].
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打开了数据库，比较顺利。
对于通过非常规手段打开的数据库，我们建议进行导出重建，比较保险一些。到此结束吧！

推荐专题

最新下载

热门教程

oracle数据库TB 数据恢复方法

相关文章

热门栏目

php教程

asp.net教程

手机开发

css教程

网页制作

办公数码

jsp教程