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,
KSTID(409));
}
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.
Comment