问题描述：

一个客户的数据库从9201升级到9208之后，数据库alert日志中出现以下错误：
Fri May 10 12:23:57 2013
Errors in file d:\oracle\admin\lssgsj\udump\lssgsj_ora_2960.trc:
ORA-00600: internal error code, arguments: [12700], [45510], [79797362], [20], [48083965], [25], [], []

Fri May 10 12:28:13 2013
Errors in file d:\oracle\admin\lssgsj\udump\lssgsj_ora_1760.trc:
ORA-00600: 内部错误代码，参数: [12700], [30385], [80155466], [7], [47216891], [25], [], []

Fri May 10 12:34:50 2013
Errors in file d:\oracle\admin\lssgsj\udump\lssgsj_ora_1188.trc:
ORA-00600: 内部错误代码，参数: [12700], [31400], [79923206], [14], [0], [79], [], []

有些业务查询会报错，需要注意的是，业务前台（使用weblogic）报的并不是ora-00600错误,而是JDBC连接错误。

处理过程：
根据ORA-00600错误的提示，检查d:\oracle\admin\lssgsj\udump\lssgsj_ora_2960.trc
得到如下信息：

*** 2013-05-10 12:23:57.234
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [12700], [45510], [79797362], [20], [48083965], [25], [], []
Current SQL statement for this session:
SELECT ID, STEP_ID, ACTION_ID, OWNER, START_DATE, DUE_DATE, FINISH_DATE, STATUS, CALLER FROM OS_HISTORYSTEP WHERE ENTRY_ID = :1 ORDER BY ID DESC

检查这张表格：OS_HISTORYSTEP 是否有坏块：

ANALYZE TABLE BASE1.OS_HISTORYSTEP VALIDATE STRUCTURE ;

分析成功！

分析OS_HISTORYSTEP的索引：

ANALYZE TABLE BASE1.OS_HISTORYSTEP VALIDATE STRUCTURE CASCADE;

报错：
ORA-01499: table/index cross reference failure – see trace file

可以确定是这张表格的索引出现问题。

检查这张表格的所有索引：

SQL> select owner,index_name,table_owner,table_name,table_type,uniqueness from dba_indexes where table_name=’OS_HISTORYSTEP’;

OWNER INDEX_NAME TABLE_OWNER TABLE_NAME TABLE_TYPE UNIQUENESS

————————- —————————— —————————— —————————— ———BASE1 PK_OS_HISTORYSTEP BASE1 OS_HISTORYSTEP TABLE UNIQUE

SQL> select * from dba_ind_columns where index_name=’PK_OS_HISTORYSTEP’;

INDEX_OWNE INDEX_NAME TABLE_OWNER TABLE_NAME COLUMN_NAME

—————- —————————— —————————— —————————— BASE1 PK_OS_HISTORYSTEP BASE1 OS_HISTORYSTEP ID

在重建这张索引之前，使用这个索引做一次查询,会报ORA-00600错误：

select * from base1.OS_HISTORYSTEP where id=41;

而做全表扫描，则不会报错：

select * from base1.OS_HISTORYSTEP;

可以确认PK_OS_HISTORYSTEP索引损坏。

重建这张索引：
alter index base1.PK_OS_HISTORYSTEP rebuild online;

重建完成后再次查询，不再报错：
select * from base1.OS_HISTORYSTEP where id=41;

再次执行有问题的业务查询，恢复正常。

对于索引坏块，一般只需要重建（online）即可解决，如果是表格坏块，可以考虑以下思路：

1、如果有完整的备份（可以使用dbv校验备份文件是否损坏），可以通过完全恢复、表空间恢复甚至数据文件恢复来消除坏块。

2、如果没有可用备份，可以考虑跳过冲突块重建表格，一般使用DBMS_REPAIR.FIX_CORRUPT_BLOCKS标记坏块，使用DBMS_REPAIR.SKIP_CORRUPT_BLOCKS跳过坏块。

3、在有些时候，业务是允许某些坏块的存在的，这时候可以使用DBMS_REPAIR.FIX_CORRUPT_BLOCKS对坏块进行标记。

一次ORA-00600: internal error code, arguments: [12700]排查修复