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打开了数据库，比较顺利。
对于通过非常规手段打开的数据库，我们建议进行导出重建，比较保险一些。到此结束吧！

时间： 2024-09-07 04:00:53

oracle数据库TB 数据恢复方法的相关文章

Oracle数据库的备份方法

1.引言 Oracle数据库的备份方法很多,无论使用那种备份方法,备份的目的都是为了在出现故障后能够以尽可能小的时间和代价恢复系统.比如使用export实用程序导出数据库对象.使用Oracle备份数据库.使用Oracle对称复制.使用Oracle并行服务器.使用Oracle冷备份.使用Oracle热备份等各种备份方法都有其优缺点.适用的场合和相应的软硬件要求.本文主要就用export实用程序导出数据库对象.Oracle冷备份.Oracle热备份这三种最基本的备份方法进行详细的探讨,分析各自的优缺

简便实现Oracle数据库文件移动方法

oracle|数据|数据库 Oracle数据库在使用过程中,随着数据的增加数据库文件也逐渐增加,在达到一定大小后有可能会造成硬盘空间不足:那么这时我们可以把数据库文件移动到另一个大的硬盘分区中.下面我就以Oracle for Windows版本中把C盘的数据库文件移动到D盘为例介绍Oracle数据库文件移动的方法和步骤. 1.在sqlplus中连接到要移动文件的Oracle数据库,然后执行如下SQL语句查看Oracle数据库文件位置: SQL> select file_name from sys

Excel导入oracle数据，oracle数据库导出excel方法

导出 导出的话,在PL/SQL的SQL Window中查询结果中选中查询结果右单击就有 COPY TO EXCEL这个选择的 导入 方法一 以下的文章主要是介绍如何用SQL*Loader将Excel相关的数据导出到Oracle数据库,其主要的目的是实现往Oracle数据库里插入excel相关文件中的实际应用数据,以下就是文章的具体内容的介绍. 实现步骤: 1.打开MicroSoft Excel 2.文件(F)→新建(N)→工作簿→ 3.输入SQL*Loader将Excel数据后,存盘为test.

oracle数据库连接数设置方法

用户的最大连接数 查看该用户的最大连接数 select profile from dba_users where username='APP_TEST'; select * from dba_profiles where profile='PF_APP_TEST' and resource_name='SESSIONS_PER_USER'; 查看该用户当前的连接数 select count(*) from v$session where username=' APP_TEST'; 查看实例允许的

asp 连接 oracle数据库两种方法

'oracle 连接方法: set adocon=server.createobject("adodb.connection") adocon.open"driver={microsoft odbc for oracle};server=oraclesever.world;uid=admin;pwd=pass;" 'oracle ole db 连接方法: set adocon=server.createobject("adodb.connection&qu

oracle数据库tns配置方法详解_oracle

TNS简要介绍与应用 Oracle中TNS的完整定义:transparence Network Substrate透明网络底层,监听服务是它重要的一部分,不是全部,不要把TNS当作只是监听器. TNS是Oracle Net的一部分,专门用来管理和配置Oracle数据库和客户端连接的一个工具,在大多数情况下客户端和数据库要通讯,必须配置TNS,当然在少数情况下,不用配置TNS也可以连接Oracle数据库,比如通过JDBC.如果通过TNS连接Oracle,那么客户端必须安装Oracle client

在Mac OS上安装Oracle数据库的基本方法_oracle

基本环境:Snow Leopard10.6.2,Oracle10.2.0.4 打开Mac的终端,执行: sudo -i 创建oinstall组和oracle用户,注意需要保证组合用户的ID与现有系统信息不冲突,这里采用700 创建组: dscl . -create /groups/oinstall dscl . -append /groups/oinstall gid 700 dscl . -append /groups/oinstall passwd "*" 创建用户: dscl .

实例代码讲解Java连接Oracle数据库的各种方法

oracle|数据|数据库 java与oracle的接口: 在数据库中运行JAVA可以说是ORACLE8i的最令人激动的新特性.在你创建的使用ORACLE8i 数据库的应用程序中,你可以使用与JAVA有关的新特征,轻松的将程序发布到INTERNET或INTRANET上. Methods for Using Java in ORACLE 大家都知道JAVA在跨平台开发与INTERNET开发中已经比较流行,ORACLE8i及以后的版本中都包含了对在数据库中运行JAVA的扩展支持,这里有两种方法可以使

linux下oracle数据库重启的方法

网站的服务中断了,重启下发现是oralce服务不存在,又不想重启机器,就重新启动下oralce,再重启服务,搞定. 操作的为oracle9i:(其他应该也可以用吧记录如下)声明:坚挺器(应该理解的哦,信息发不出去,你懂的,就用这个了) (1) 以oracle身份登录数据库,命令:su – oracle (2) 进入Sqlplus控制台,命令:sqlplus /nolog (3) 以系统管理员登录,命令:connect / as sysdba (4) 启动数据库,命令:startup (5) 如果