-
Hi there,
I'm using 8.1.6 on Linux. I got "ORA-00600 : internal error code, arguments: [6122], [0], [58], [0], [], [], [], []" when inserting data into a table. I then did dbverify with all the datafiles related to this table and found that the 2 index files in the index tablespace each contains one failed page. Finally I was able to figure out which index was causing the problem. After removing and recreating the index, I was able to insert data without getting the ORA 600 error. But when I did dbverify with the 2 index files, I got the exact same failed pages again! The error msg of one file is:
**** row 60: key out of order
---- end index block validation
Page 201718 failed with check code 6401
The error msg of the other file:
**** actual rows locked by itl 3 = 12 != # in trans. header = 70
---- end index block validation
Page 77152 failed with check code 6401
Should I do something about it or should I ignore it? Please help.
Thanks!
Tianhua
-
Is the table index organized? Sometimes, after parallel creation of a secondary index on an IOT, index key could be out of order. Oracle's workaround is creating the index sequentially.
-
Thanks Julian!
The table is not IOT, the index is a regular B tree index.
Tianhua
-
Did recreating the index help?
-
Yes. I no longer get ORA 600 error after recreating the index. But when I dbverify the index files I still got the same error (see my original post). I also did a full db export afterwards and didn't get any error. So the data should be fine. Maybe when I dropped the index, the DATA itself was not physically cleaned from the datafile, and it will be cleaned later when the space is needed??
-
How did you recreate the index, with rebuild or with drop and create? It is important not to rebuild (a non-partitioned) corrupt index with an "ALTER INDEX INDEX_NAME REBUILD". Thus you just build the new index from the existing index segment, which contains a corrupt block.
-
You are right. I tried to rebuild first and got ora 600 error. So I dropped the index and recreated it.
