某省電信行業公司資料庫ORA-00600 [15160]處理

Wed Feb 26 10:11:18 2014

Errors in file /oracle/admin/dbrac/udump/dbrac2_ora_14794.trc:

ORA-00600: internal error code, arguments: [15160], [], [], [], [], [], [], []

Wed Feb 26 10:12:29 2014

Errors in file /oracle/admin/dbrac/udump/dbrac2_ora_14794.trc:

ORA-00600: internal error code, arguments: [15160], [], [], [], [], [], [], []

Wed Feb 26 10:13:39 2014

Errors in file /oracle/admin/dbrac/udump/dbrac2_ora_29891.trc:

ORA-00600: internal error code, arguments: [15160], [], [], [], [], [], [], []

/oracle/admin/dbrac/udump/dbrac2_ora_29891.trc

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

With the Partitioning, Real Application Clusters, Data Mining and Real Application Testing options

ORACLE_HOME = /oracle/product/10.2.0/db

System name:    HP-UX

Node name:      dbrac2

Release:        B.11.31

Version:        U

Machine:        ia64

Instance name: dbrac2

Redo thread mounted by this instance: 2

Oracle process number: 121

Unix process pid: 29891, image: oracle@dbrac2

*** ACTION NAME:() 2014-02-26 10:13:39.698

*** MODULE NAME:(BusiMonitor@ccjkp1 (TNS V1-V3)) 2014-02-26 10:13:39.698

*** SERVICE NAME:(dbrac) 2014-02-26 10:13:39.698

*** SESSION ID:(1491.11581) 2014-02-26 10:13:39.698

*** 2014-02-26 10:13:39.698

ksedmp: internal or fatal error

ORA-00600: internal error code, arguments: [15160], [], [], [], [], [], [], []

Current SQL statement for this session:

select 'M-6M-LM-PM-EM-IM-OM-PM-PM-JM-}M->M-]test_waitM-SM-P'||count(1)||'M-LM-uM-<M-GM-BM-<M-QM-OM-VM-XM-3M-,M-JM-1M-#M-,M-NM-4M-<M-0M-JM-1M-GM-eM-@M-mM-#M-!' fr

om test_wait where recvtime < sysdate -10/1440 and stepnow=0 having count(1) >=1

----- Call Stack Trace -----

calling              call     entry                argument values in hex     

location             type     point                (? means dubious value)    

-------------------- -------- -------------------- ----------------------------

ksedst()+64          call     ksedst1()            000000000 ? 000000001 ?

ksedmp()+2176        call     ksedst()             000000000 ?

                                                   C000000000000C9F ?

                                                   4000000003ECA500 ?

                                                   000000000 ? 000000000 ?

                                                   000000000 ?

ksfdmp()+48          call     ksedmp()             000000003 ?

kgeriv()+336         call     ksfdmp()             C000000000000695 ?

                                                   000000003 ?

                                                   4000000009382BA0 ?

                                                   000020127 ? 000000000 ?

                                                   000000000 ? 000000000 ?

                                                   000000000 ?

kgesiv()+192         call     kgeriv()             6000000000031370 ?

                                                   6000000000032428 ?

                                                   40000000018D14C0 ?

                                                   000000000 ?

                                                   9FFFFFFFFFFEE7E8 ?

select 'M-6M-LM-PM-EM-IM-OM-PM-PM-JM-}M->M-]test_waitM-SM-P'||count(1)||'M-LM-uM-<M-GM-BM-<M-QM-OM-VM-XM-3M-,M-JM-1M-#M-,M-NM-4M-<M-0M-JM-1M-GM-eM-@M-mM-#M-!' fr

om test_wait where recvtime < sysdate -10/1440 and stepnow=0 having count(1) >=1

基於表查詢報出的ORA-00600 [15160]一般和SQL的執行相關，關於這種型別問題可以重新收集表統計資訊解決。

具體處理過程如下：

1)檢視該表的OWNER

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

OWNER                          TABLE_NAME

------------------------------ ------------------------------

TEST_OWNER                         TEST_WAIT

2）收集該表統計資訊

SQL> exec DBMS_STATS.GATHER_TABLE_STATS(ownname=>'TEST_OWNER',tabname=>'TEST_WAIT',estimate_percent=>10,no_invalidate=>false,cascade=>true,degree => 10);

PL/SQL procedure successfully completed.

3)、檢視alert日誌驗證結果，發現從收集完統計資訊之後ORA-600沒再出現，問題解決！