Oracle database TB Data recovery method

This is a user's database, is said to be not archived, do not know why the host forced to restart after the database can not open. First, let's take a look at the error he reported here on open:

sql> ALTER DATABASE open;


ALTER DATABASE Open


*


Line 1th Error:


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], [], [], [], [], [], []


Process id:14048


Session id:1072 Serial Number: 3


For this mistake, I think we are all very familiar with, is it possible to directly promote the SCN can be solved? According to our usual recovery approach, it must be alter session set events ' 10015 trace name ADJUST_SCN level 13697′;


At the beginning also let the netizen have such a way to try, get the reply is the database is 11.2.0.4. This is a bit of a tragedy, since Oracle version 11.2.0.3 is no longer supporting the use of this event or implied parameters to advance the database SCN. The only way is to oradebug modify the database SCN.


This is said to be a Windows environment, so modifying the database SCN is relatively cumbersome. The following is an example of a Windows virtual machine modification SCN that I did myself for reference:

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;





The database has changed.





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;





The system has changed.





Sql> select checkpoint_change# from V$datafile;





checkpoint_change#


------------------


8590892105


8590892105


8590892105


8590892105





sql> shutdown Immediate


The database has been closed.


The database has been unloaded.


The ORACLE routine has been closed.


Sql>


I think you already know that in fact Windows x64 environment, the modification SCN is also very simple, the front 4 byte is bas SCN, the latter 4 byte is wrap SCN; So if we're going to push the SCN, then we can just modify the wrap. Directly modify the Wrap SCN value to move 4 offset, and then directly modify it.


Unfortunately, I told the blogger that there are similar fixes in this blog, and he still can't open the database after his modification, and the error remains the same. More trouble, for the more difficult problem for me is more attractive.


First let the other person do a 10046 trace trace, get the following similar information:

Wait #92370008: nam= ' db file sequential read ' ela= 7059 file#=1 block#=128 Blocks=1 obj#=0


Wait #92370008: nam= ' db file sequential read ' ela= 5317 file#=1 block#=539 Blocks=1 obj#=0


......


=====================


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


=====================


Parsing in CURSOR #410498856 len=142 dep=1 uid=0 oct=3 lid=0 tim=110663543442 hv=361892850 ad= ' e37e371c0 ' sqlid= ' 7bd391hat 42zk '


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 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


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 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


From the information above, the database is currently in a wait state when it executes cursor# 92370008 on open, and then fails.


From the above information it is not difficult to see that there are several Block:file 1 block 225;file 1 blocks 539;file 3 block 128.


It's clear that file 1 Block 225 is undo$. and file 3 is also the undo file.


Let the other person provide the dump file 1 block 128 information and find that there is a real active transaction, as follows:

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 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


Obviously, the above 0X1A transaction is an active transaction and the block address involved is: 0x0040021b


The following is also the dump information for file 3 block 128:

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


......


From the dump point of view, File 3 Block 128 is not a problem. That is, the problem may be in the preceding 2 blocks of file 1 block 128 and file 1 block 539.


Further dump file 1 block 539, found as follows:

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
......
Obviously, this is a undo block and is a system rollback segment. And the first 2662 wrong RDBA address, in fact, is relatively easy to make people wrong judgments:

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
So we can conclude that the database cannot open, so it has to do with undo, and it's system Roll back the segment. The
then lets the pair set the following event simultaneously and sets the _corrupted_rollback_segments parameter at the same time. : Alter system set event= ' 10513 Trace name context Forever,level 2:10512 Trace name context Forever,level 1:10511 Trace The name Context Forever,level 2:10510 the trace name context Forever,level 1 ' scope=spfile;
Here you need to explain that the Windows environment is troublesome, you can borrow the DD fow Windows version for copy block, and then filter the rollback segment information, and all screen.
Even though I have told each other about my killer, the answer is still unable to open the database, the error ORA-01555 as follows:

sql> ALTER DATABASE open resetlogs;
ALTER DATABASE open Resetlogs
*
Line 1th Error:
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
Process id:14728
Session id:1072 Serial Number: 3
I have a deep understanding of this error, essentially because the data blocks that are accessed during open need to use undo to make mistakes. In other words, the block has an active transaction.
Again, it is recommended that you navigate to the problematic block of data through the 10046 event Trace, as follows:

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= ' AXMDF8VQ 7k1rh '


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 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= 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


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 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


From the information above, there are exceptions to file 1 block 665 and block 705. Suggest that the other party make bbed modification, but ...


The dump content of the 2 blocks mentioned above is as follows:

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) 9b 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, @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 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, @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: 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 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


....


Good people do the bottom, the virtual machine to help modify the, the following is a manual commit transaction modification block process, for reference:


?

Bbed> P


Ktbbh.ktbbhitl[1].ktbitflg


--------------------------


UB2 ktbitflg @84 0x2001 (KTBFUPB)





Bbed> modify/x 0080


Warning:contents of previous bifile would be lost. Proceed? (y/n) Y


File:/recover/system01. DBF (1)


block:705 offsets:84 to 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 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, 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], 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], 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 dba:0x00400299


------------------------------------------------------------------------


0080





<32 bytes per line>





bbed> modify/x 0080 Offset 84


File:/recover/system01. DBF (1)


block:665 offsets:84 to 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, Bytes @0





struct KTBBH, Bytes @20





struct KDBH, 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


-------------------------------------------------------


L.





<16 bytes per line>





Bbed> modify/x 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 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


After the modification is complete, the problem block in the system file is replaced with a DD command similar to the following:


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


It is said that after the replacement block, the last recover a, directly open the database, relatively smooth.


For the database opened through unconventional means, we recommend to export the reconstruction, more insurance. This is the end of it!