Oracle ORA-00600 [15764] 解決方案

剛到公司收到一朋友的留言，說RAC的一個節點掛了。 因為他昨晚6點重建過一個索引，跑了2個多小時還沒結束， 後來他就手工取消了。 晚上11點多，其中一個節點就出現問題了。

DB 環境是：AIX 6.1 + Oracle 10.2.0.4，2節點。現在一個節點在撐著，壓力很大。嘗試啟動掛掉的節點，可以正常啟動，一旦執行DML 操作，節點就掛掉了。

Alert log 資訊：

ORA-00600: internal error code, arguments:[15764], [], [], [], [], [], [], []
Wed Sep 7 00:26:42 2011
Errors in file /apps/oracle/admin/sfc3db/udump/sfc3db2_ora_5054706.trc:
ORA-00600: internal error code, arguments: [15764], [], [], [], [], [], [], []
Wed Sep 7 00:26:44 2011
Trace dumping is performing id=[cdmp_20110907002644]
Wed Sep 7 00:27:10 2011
Errors in file /apps/oracle/admin/sfc3db/udump/sfc3db2_ora_2756730.trc:
ORA-00600: internal error code, arguments: [15764], [], [], [], [], [], [], []
Wed Sep 7 00:28:11 2011
Errors in file /apps/oracle/admin/sfc3db/udump/sfc3db2_ora_2756730.trc:
ORA-00600: internal error code, arguments: [15764], [], [], [], [], [], [], []

我問朋友是否還有其他的錯誤，朋友說只有這些。  

部分Trace 資訊如下：

/apps/oracle/admin/sfc3db/udump/sfc3db2_ora_5054706.trc:calls aborted: 0, num est exec limit hit: 0
/apps/oracle/admin/sfc3db/udump/sfc3db2_ora_5054706.trc: name=update seq$ setincrement$=:2,minvalue=:3,maxvalue=:4,cycle#=:5,order$=:6,cache=:7,highwater=:8,audit$=:9,flags=:10where obj#=:1
/apps/oracle/admin/sfc3db/udump/sfc3db2_ora_5054706.trc: name=selectdecode(failover_method, NULL, 0 , 'BASIC', 1, 'PRECONNECT', 2 , 'PREPARSE', 4 ,0), decode(failover_type, NULL, 1 , 'NONE', 1 , 'SESSION', 2, 'SELECT', 4, 1),failover_retries, failover_delay, flags from service$ where name = :1
/apps/oracle/admin/sfc3db/udump/sfc3db2_ora_5054706.trc:selectSYS_CONTEXT('USERENV', 'SERVER_HOST'), SYS_CONTEXT('USERENV','DB_UNIQUE_NAME'), SYS_CONTEXT('USERENV', 'INSTANCE_NAME'),SYS_CONTEXT('USERENV', 'SERVICE_NAME'), INSTANCE_NUMBER, STARTUP_TIME,SYS_CONTEXT('USERENV', 'DB_DOMAIN') from v$instance whereINSTANCE_NAME=SYS_CONTEXT('USERENV', 'INSTANCE_NAME')
/apps/oracle/admin/sfc3db/udump/sfc3db2_ora_5054706.trc: name=select value$from props$ where name = 'GLOBAL_DB_NAME'
/apps/oracle/admin/sfc3db/udump/sfc3db2_ora_5054706.trc: name=selectprivilege#,level from sysauth$ connect by grantee#=prior privilege# andprivilege#>0 start with grantee#=:1 and privilege#>0
/apps/oracle/admin/sfc3db/udump/sfc3db2_ora_5054706.trc: name=select privilege#from sysauth$ where (grantee#=:1 or grantee#=1) and privilege#>0

之前整理過一篇文章：

ORA-600 各個參數含義說明

根據這篇文章裡的說明，可以判斷：

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

是與並行查詢有關。

朋友問我是否和中斷的索引rebuild有關係，我說不會。

對於手工中斷的重建索引，會遺留一些temporary segments。 因為rebuild index時，會在使用者索引空間的segments，會分配一個temporary segment 來儲存索引的資訊，當rebuild 結束之後，old index 被droped 掉，之前分配的temporary segments 會定義為permanent segment。

如果我們中斷了rebuild 操作，那麼SMON會三分鐘清理一次(前提是接到post)，如果SMON過於繁忙那麼可能temporary segment長期不被清理。temporary segment長期不被清理可能造成一個典型的問題是:在rebuild index online失敗後，後續執行的rebuild index命令要求之前產生的temporary segment已被cleanup，如果cleanup沒有完成那麼就需要一直等下去。

下面兩篇文章有詳細的說明：

Oracle alter index rebuild 說明

Oracle rebuild index 報ORA-01652 解決辦法 

我對問題的定位還是在並行查詢的SQL 上。 但是朋友提供的trace 並沒有得到相關的資訊。

在MOS 上搜了一下，有一篇相關文章：

ORA-600 [15764] Running Parallel Query on RAC [ID839536.1]

An ORA-600[15764] is highly transient in nature.  Most bugs filed for thisissue have been closed as not reproducible.   The purposeof this note is to document a known workaround if you see this error withsimilar circumstances.

The followingselect statement failed in a 10.2.0.3, 3-node, RAC database when runningin parallel:

ksedmp: internal or fatal error 
ORA-00600: internal error code, arguments: [15764], [], [], [], [], [], [], [] 
Current SQL statement for this session:
SELECT /*+ PARALLEL (ORG,3,3)*/   
ORG.X_EFX_SSN,   
ORG.X_EFX_BIRTH_DT,   
COUNT(*)   
FROM   
SIEBEL.S_ORG_EXT ORG   
GROUP BY   
X_EFX_SSN,   
X_EFX_BIRTH_DT   
HAVING COUNT(*) > 1 

The tracefile showed the following callstack:

----- Call Stack Trace -----   
kxfprigdb <- kxfpqrgdb <- kxfxgs <- kxfxcw <- qerpxFetch <- opifch2 <- kpoal8 <- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv <- sou2o <- opimai_real <- main <- start

 

The tracefile also showed the process statewas busy holding a child latch:

===================================================  
PROCESS STATE  
-------------  
Process global information:  
     process: 7000004748eaa00, call: 700000443d33870, xact: 0, curses: 700000474e203c8, usrses: 700000474e203c8  
  ----------------------------------------  
  SO: 7000004748eaa00, type: 2, owner: 0, flag: INIT/-/-/0x00  
  (process) Oracle pid=157, calls cur/top: 700000443d33870/700000443d33870, flag: (0) -  
            int error: 0, call error: 0, sess error: 0, txn error 0  
  (post info) last post received: 0 0 249  
              last post received-location: kxfprienq: QC  
              last process to post me: 700000474914f40 186 0  
              last post sent: 0 0 250  
              last post sent-location: kxfprienq: slave  
              last process posted by me: 700000474914f40 186 0  
    (latch info) wait_event=0 bits=10  
      holding    (efd=7) 700000472e4a838 Child process queue reference level=4 child#=99   
      Location from where latch is held: kxfprigdb: KSLBEGIN: addr qref  <---
        Context saved from call: 504403177372952360  
        state=busy, wlstate=free  <----
    Process Group: DEFAULT, pseudo proc: 700000474a384f0  
    O/S info: user: oracle, term: UNKNOWN, ospid: 2351144  
    OSD pid info: Unix process pid: 2351144, image: oraclePPSOLTP1@psoldbap003 

最終的解決方案：

Workaround:

Bounce all instances in the RAC cluster.

重啟RAC 上的所有instance。  朋友在中午申請了停機時間， 重啟之後， RAC 節點正常。