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

问题描述：

一个客户的数据库从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对坏块进行标记。