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

 

經過這個重建表的統計信息和官方的重建表，能夠看出，致使問題的緣由是表的統計信息出問題。