The failure of the ora-00600 [12700] is generally due to an error in the table or index data block
The failure of the ora-00600 [12700] is generally due to an error in the table or index data block
The failure of the ora-00600 [12700] is generally due to an error in the table or index data block
Fault symptom:
The user reported that an error was reported when the next simple select command was executed.
Select * from in_past t where t. Pipeline Code = 'xxxxx'
Xxxxx indicates the index column. If no index column is used, no error is reported.
Processing Process:
1. view the SQL statements with errors in the trace file
2. Check the data block of the table that causes the error. The command is as follows:
Analyze table xxxxx validate structure;
If no error is found, continue to check the index on the table:
Analyze table xxxxx validate structure cascade;
After the preceding two steps, we can conclude that the error is a table or index error.
3. In this case, it was found that the index data is incorrect, the analyze command reported an error, returned ora-00600 12700 error, view the trace file, the prompt said:
The number of records in the table does not match the number of indexed records. For example, the table has 20000 rows, while the index has 20500 rows.
4. Because this index is an ordinary user index, re-create it:
Alter index xxxxx rebuild online;
So far, the problem is solved.
Postscript:
If the index on the data dictionary is damaged, the system cannot be rebuilt because the system reports the error "cannot change the Hot System Object ". On itpub, chensq has an article "ora600 12700 troubleshooting", which mentions how to solve the I _obj2 index damage on the sys. obj $ table.
If I _obj2 is damaged, it is best to use exp data and then rebuild the database. But in the exp process, I _obj2 is also accessible. To disable I _obj2, there are two methods:
1) All SQL statements that use I _obj2 add hint to prohibit the use of I _obj2.
2) Change optimizer_index_cost_adj so that the execution plan accessing sys. obj $ does not use the index, but uses the full table scan method.
In chensq's article, both methods have been successful.