ORA-600 [KTSPSCANINIT-D]

PROBLEM:
--------
Ran the script and came back with table_act_entry.
Can select from table_act_entry table with rownum<200 but other rownum 
options give error. Also attempted to analyze "SA"."TABLE_ACT_ENTRY" table 
but receive same ORA-600 error. You can see from pasted data.  Can't anaylze 
table_act_entry?
 
SQL> select * from TABLE_ACT_ENTRY where rownum>100 and rownum<150;
select * from TABLE_ACT_ENTRY  where rownum>100 and rownum<150
              *
ERROR at line 1:
ORA-600: internal error code, arguments: [ktspScanInit-d], [35758097], 
[],[], [], [], [], []
 
SQL> select * from TABLE_ACT_ENTRY where rownum>18315000;
select * from TABLE_ACT_ENTRY where rownum>18315000
              *
ERROR at line 1:
ORA-600: internal error code, arguments: [ktspScanInit-d], [35758097], 
[],[], [], [], [], []
 
SQL>  analyze table "SA"."TABLE_ACT_ENTRY" validate structure cascade;
 analyze table "SA"."TABLE_ACT_ENTRY" validate structure cascade
*
ERROR at line 1:
ORA-600: internal error code, arguments: [ktspScanInit-d], [35758097], 
[],[], [], [], [], []
 
 
DIAGNOSTIC ANALYSIS:
--------------------
ERROR:              
   ORA-600 [ktspscaninit-d] [a]
 
 VERSIONS:
   versions 9.2
 
 DESCRIPTION:
 
   Oracle has encountered an inconsistency in the metadata for an ASSM
   (Automatic Segment Space Management) segment. 
 
   An ASSM segment has two Highwater marks, a Low Highwater mark (LHWM) and 
   a High Highwater mark (HHWM - this is the same as a traditional HWM).
 
   This error is raised when we fail to locate the Low Highwater mark block.
 
   Stored in the Segment header is information which identifies the Level 1
   Bitmap Block (L1BMB) for the LHWM block, this BMB is managing the range 
   of datablocks holds the LHWM block.
 
   If during a scan of the ranges in this L1BMB we fail to locate the LHWM
   block then this error is raised.
  
 ARGUMENTS:
   Arg [a] Block address of Low HWM block  
  
 FUNCTIONALITY:      
   TRANSACTION SEGMENT PAGETABLE
 
---------------
 
Tried to corrupt the bitmap and rebuild it - this did not work
 
WORKAROUND:
-----------
Drop table and import from backup - this is not an option
the table is critical to the complete operation of the database.

A tool 'DUL' was used to take table data and write it to a flat file, and now  they are trying to use SQLLOADER to load it back into a table;

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: [email protected]