sitemap

RSS地图

收藏本站

设为首页

Oracle研究中心

当前位置:Oracle研究中心 > 故障案例 >

【案例】Oracle报错ORA-00603 ORA-00600[2662]原因和解决办法笔记

时间:2016-11-12 21:04   来源:Oracle研究中心   作者:网络   点击:

天萃荷净 Oracle研究中心案例分析:运维DBA反映Oracle数据库非归档模式重启后无法启动数据库报错ORA-00603 ORA-00600[2662],分析原因为SCN异常导致。
本站文章除注明转载外,均为本站原创: 转载自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> 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
  -----------------------------------------------------------------Oracle?о?????-------------------------------
   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打开了数据库,比较顺利。
对于通过非常规手段打开的数据库,我们建议进行导出重建,比较保险一些。到此结束吧!

--------------------------------------ORACLE-DBA----------------------------------------

最权威、专业的Oracle案例资源汇总之【案例】Oracle报错ORA-00603 ORA-00600[2662]原因和解决办法笔记

本文由大师惜分飞原创分享,网址:http://www.oracleplus.net/arch/1248.html

Oracle研究中心

关键词:

ORA-00600[2662]

非常规恢复Oracle数据库

ORA-00603

Oracle SCN推进修复数据库