While inserting in a table (having 182 partitions),I came up with ORA-00600: internal error code,
arguments:,[ ],.....[ ].The tablespace containing that table have 4 datafiles,I have already run dbv(DBVERIFY) but did not find any block corruption in the datafiles.The other thing in my mind is to
ANALYZE the table,can any one help me to tell the easiest way to analyze a partitioned table having 182
partitions or any other way to get rid of this error.
your quick response will be highly appreciated as it is an production env.
Hi, We understood the urgency of your problem. But the manual says as follows:
This is the generic internal error number for Oracle program exceptions. It indicates that a process has encountered a low-level, unexpected condition. Causes of this message include:
failed data checks in memory
hardware, memory, or I/O errors
incorrectly restored files
I think, you may have to check-up your system completely to identify any of the above incidents happened in your database. Please check all the alert log files. This is the better time to contact for ORACLE WORLD-WIDE CUSTOMER SUPPORT or any of your senior experts. We don't know the all the details of your database. But you can check for all the possibilities.
..mmm...ora-600 (The DBA-INCUB).
I don't think that dbv can help you (in this case). This kind of error means a structure damege, may bee table structure...may bee internal structure (rollback..tablespaces...etc..)
I will try this first:
analyze table xxx validate structure;
try to produce trace :
1. using alter session set sql_tarce=true or setting 10046 events with level 10
2. dumping process state, etc
Then look into trace files, especialy into data dictionary queries as error can be in system tablespace.
if nothing helps and this is not a big deal, try to recreate the table.
Thanks for the replies,but the problem still persists,Ihave done
Analyze table ..... validate structure cascade; but I din't helped no trace file was generated and the statment was processed. Please have a look at Alert.log and trace file.
The problem seems to be at ORacle Service layer,
Verify there are no tablespace still in backup mode
I feel they still are and checkpoint cannot occur since the
tablespace is not back in normal mode and hence no new data is being entered.
Also Verify your Redologfiles are not corrupt, checkpoint process advances based on Redo block Address in Redolog files and updates controlfile.
Dump you control file header and verify the above tablespace mode and checkpoint SCN.
does it run on test database?
if do not know then try to create a copy of that table somewhere else(at least indifferent tablespace) and try to insert: this at least will show that it is a storage problem, but not SQL bug.