ORA-00600: internal error code, arguments: [6749], [3], [12602196]

环境信息：
Linux5.8 oracle10.2.0.4

问题现象：

现象1：alert日志有大量下面的错误信息：

Wed Aug 27 21:01:27 2014
Errors in file /u01/app/oracle/admin/urpdb/bdump/urpdb_j000_30948.trc:
ORA-00600: internal error code, arguments: [6749], [3], [12602196], [175], [], [], [], []

现象2：每次发生上述报错
bdump目录里会产生一个几百M---几个G的trc文件。

 

现象3：
数据库服务运行还算正常。

 

问题分析：

查询oracle官方文档，发现ORA-600 [6749] Occurring on SYSMAN.MGMT_METRICS_RAW [ID 467439.1]文档。

这是一个bug。

 

解决方法：
SQL> create table SYSMAN.MGMT_METRICS_RAW_COPY
as select * from SYSMAN.MGMT_METRICS_RAW;

Table created.

SQL> truncate table SYSMAN.MGMT_METRICS_RAW;

Table truncated.

SQL> insert into SYSMAN.MGMT_METRICS_RAW
select * from SYSMAN.MGMT_METRICS_RAW_COPY;
insert into SYSMAN.MGMT_METRICS_RAW
*
ERROR at line 1:
ORA-00001: unique constraint (SYSMAN.MGMT_STRING_METRIC_HISTORY_PK) violated
ORA-06512: at "SYSMAN.RAW_METRICS_AFTER_INSERT", line 33
ORA-04088: error during execution of trigger 'SYSMAN.RAW_METRICS_AFTER_INSERT'

SQL> alter trigger SYSMAN.RAW_METRICS_AFTER_INSERT disable;

Trigger altered.

SQL> insert into SYSMAN.MGMT_METRICS_RAW
select * from SYSMAN.MGMT_METRICS_RAW_COPY;

64152 rows created.

SQL> alter trigger SYSMAN.RAW_METRICS_AFTER_INSERT enable;

Trigger altered.

SQL> drop table SYSMAN.MGMT_METRICS_RAW_COPY;

Table dropped.

 

辅助分析:

1.服务器bdump目录里产生的很大trc，你打开trc文件，按文件产生时间，在里面可以查到下面信息
----------------------------------------------
*** 2014-08-27 21:01:27.663
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [6749], [3], [12602196], [175], [], [], [], []
Current SQL statement for this session:
DELETE MGMT_METRICS_RAW WHERE TARGET_GUID = :B3 AND COLLECTION_TIMESTAMP < :B2 AND ROWNUM <= :B1
----- PL/SQL Call Stack -----

 

这就是说：产生该ORA-00600: internal error code, arguments: [6749]报错
是由于系统执行了
DELETE MGMT_METRICS_RAW WHERE TARGET_GUID = :B3 AND COLLECTION_TIMESTAMP < :B2 AND ROWNUM <= :B1
语句导致的。

2.按照常理ORA-00600[6749]错误是因为坏块或者表和索引数据不一致导致,通过ANALYZE可以检查出来.
下面是通过分析块文件检查过程：
注意： 6749 的参数 12602196 是数据块的DBA，通过这个数字转换，应该可以找到相应的数据块

SQL> select DBMS_UTILITY.data_block_address_file (12602196) "file#",
DBMS_UTILITY.data_block_address_block (12602196) "block#"
from dual; 2 3

file#       block#
---------- ----------
3            19284

根据dba查询对象

select * from dba_extents where 19284 between block_id and block_id + blocks and file_id=3;----这一步有点慢
OWNER SEGMENT_NAME SEGMENT_TYPE
---------- ------------------------------- -------------------
SYSMAN SYS_IOT_OVER_10448 TABLE

SQL> select owner,iot_name from dba_tables where table_name = 'SYS_IOT_OVER_108326';

OWNER IOT_NAME
-------- ---------------------------------------------------
SYSMAN MGMT_METRICS_RAW

 

SQL> ANALYZE TABLE SYSMAN.MGMT_METRICS_RAW VALIDATE STRUCTURE CASCADE;

Table analyzed.

这里显示正常。

   

3.该问题网络上其他人员处理办法：
http://www.eygle.com/archives/2012/03/ora-600_6749_8102.html

以DBA身份登录执行:
execute dbms_stats.delete_schema_stats('ZJLM_USER');
ZJLM_USER 是你报错的那个表所属的oracle用户

我没有敢做SCHEMA的删除，重新搜集了下该表的统计信息 ，再次更新时就成功了。

以下是执行步骤：
SQL> exec dbms_stats.gather_table_stats(ownname => 'KMS',tabname=>'DB_TESTRESULTINFO_OLD');

PL/SQL procedure successfully completed

 

通过这个重建表的统计信息和官方的重建表，可以看出，导致问题的原因是表的统计信息出问题。