CT was initially receiving an ORA-600[25012][1][3]
This was doing an insert into a user table.  CT attempted
to do an index rebuild on an index on the table, and the
instance crashed.  Now, all attempts to open the DB
result in ORA-600[ktssdro_segment1][1][12621530][0].
* Since we are committing after freeing every eight extents it is
* possible that the number of extents as indicated by the seg$ entry
* is different from the number of used extents in uet$. This will
* happen if the earlier instance had crashed in the midst of freeing
* extents. However since the segment header is itself freed only at
* the end the extent number should not be zero
   ASSERTNM3(key.ktsukext != 0, OERINM("ktssdro_segment1"),
          segtid->tsn_ktid, segtid->dba_ktid, key.ktsukext);
   KSTEV4(key.ktsuktsn, key.ktsukfno, key.ktsukbno, key.ktsukext,
From reading this, it looks like a possible corruption in UET$ or seg$ ?
I have suggested that CT set Event 10061 to disable SMON freeing up free
extents.  This would mean no deletes from uet$, but not sure if this will
solve it. 
Unfortunately, CT does not have a good backup or backup strategy.
unload data using ORACLE DUL Data Unloader.

Refer  http://parnassusdata.com/en/emergency-services  for more info.

If you cannot recover the data by yourself, ask Parnassusdata, the professional ORACLE database recovery team for help.

Parnassusdata Software Database Recovery Team

Service Hotline:  +86 13764045638

E-mail: service@parnassusdata.com




沪公网安备 31010802001379号