ORA-00600: internal error code, arguments: [6731], [1], [0], [62], [], [], [], [ ]


I am getting the following error when trying to update a table in Oracle 8.1.6 ,
I tried to update other tables but the error is coming while updating this table !!!

Any Ideas Please
Who is Participating?
johnsoneConnect With a Mentor Senior Oracle DBACommented:
If the data is good in a copy of the table, then I suspect indexes.  We had problems with indexes generating ORA-00600 errors back in 8i.  One of the indexes is corrupt on that table.  It is most likely the one with object id 6731 (check in DBA_OBJECTS), but I would recommend dropping and recreating all the indexes on that table.
Gerwin Jansen, EE MVETopic Advisor Commented:
Besides the fact that your Oracle version is ancient (you probably have some reason not to upgrade) can you clarify whether updates to other tables are working or not? And when did this issue start? Did anything change that needs to be mentioned?
m_jundiAuthor Commented:
Update other tables are working fine,started yesterday when I killed a session while it is updating a huge table.
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

slightwv (䄆 Netminder) Commented:
The ORA-600 is one of those errors that pretty much needs Oracle Support to diagnose.  Since 8i has LONG been desupported, you may be out of luck.

Since you killed a session that was in the middle of an update statement you may have some data, block or table corruption.

I would first try to see if you can create a new table copy:
create table my_table_bkup as select * from my_table;

Verify the data is all there (a couple of minus queries).  Then try the update on the new table.

If all that works, then it is probably some corruption somewhere.

I would look at a permanent recreation of the table.
m_jundiAuthor Commented:
I have created a new copy of that table and it works fine, Do u think dropping the table and import a new backup file will solve the issue ?
Gerwin Jansen, EE MVETopic Advisor Commented:
If you created a copy like slightwv above is suggesting then all data is already in the copy of your table. Then there would be no need to import from backup. Why would you want to import from backup?
slightwv (䄆 Netminder)Connect With a Mentor Commented:
>>and it works fine

Did you verify ALL the data is 100% accurate between the tables?

If so, I agree that restoring from a backup probably isn't necessary.

There are a couple of things you can do but it would be based on your database and how things are set up:

1:  Truncate the current table and insert all the data back into it.
2:  drop the current table and rename the new one to the original name.

There are potential issues with either.

Constraints and indexes are the main issues.  Dropping the table would require rebuilding all the indexes and constraints.  Truncating might be bad if there are foreign key constraints on the table.
slightwv (䄆 Netminder) Commented:
>>then I suspect indexes

Excellent suggestion!  I forgot about indexes.

Yes, try a rebuild before all the trouble of a copy/rename of tables.
m_jundiAuthor Commented:
What I did , I restarted the DB for and everything worked fine
Steve WalesSenior Database AdministratorCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.