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 各个参数含义说明

http://blog.csdn.net/tianlesoftware/article/details/6645809

根据这篇文章里的说明，可以判断：

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 说明

http://blog.csdn.net/tianlesoftware/article/details/6538928

Oracle rebuild index 报ORA-01652 解决办法

http://blog.csdn.net/tianlesoftware/article/details/6656496

我对问题的定位还是在并行查询的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 thisissuehave beenclosed 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, RACdatabase when runningin parallel:

ksedmp:internalorfatalerror
ORA-00600:internalerrorcode,arguments:[15764],[],[],[],[],[],[],[]
CurrentSQLstatementforthissession:
SELECT/*+PARALLEL(ORG,3,3)*/
ORG.X_EFX_SSN,
ORG.X_EFX_BIRTH_DT,
COUNT(*)
FROM
SIEBEL.S_ORG_EXTORG
GROUPBY
X_EFX_SSN,
X_EFX_BIRTH_DT
HAVINGCOUNT(*)>1

The tracefile showed the following callstack:

-----CallStackTrace-----
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:

===================================================
PROCESSSTATE
-------------
Processglobalinformation:
process:7000004748eaa00,call:700000443d33870,xact:0,curses:700000474e203c8,usrses:700000474e203c8
----------------------------------------
SO:7000004748eaa00,type:2,owner:0,flag:INIT/-/-/0x00
(process)Oraclepid=157,callscur/top:700000443d33870/700000443d33870,flag:(0)-
interror:0,callerror:0,sesserror:0,txnerror0
(postinfo)lastpostreceived:00249
lastpostreceived-location:kxfprienq:QC
lastprocesstopostme:700000474914f401860
lastpostsent:00250
lastpostsent-location:kxfprienq:slave
lastprocesspostedbyme:700000474914f401860
(latchinfo)wait_event=0bits=10
holding(efd=7)700000472e4a838Childprocessqueuereferencelevel=4child#=99
Locationfromwherelatchisheld:kxfprigdb:KSLBEGIN:addrqref<---
Contextsavedfromcall:504403177372952360
state=busy,wlstate=free<----
ProcessGroup:DEFAULT,pseudoproc:700000474a384f0
O/Sinfo:user:oracle,term:UNKNOWN,ospid:2351144
OSDpidinfo:Unixprocesspid:2351144,image:oraclePPSOLTP1@psoldbap003

最终的解决方法：

Workaround:

Bounce all instances in the RAC cluster.

重启RAC 上的所有instance。 朋友在中午申请了停机时间， 重启之后， RAC 节点正常。

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

Blog： http://blog.csdn.net/tianlesoftware

Weibo: http://weibo.com/tianlesoftware

Email: dvd.dba@gmail.com

DBA1 群：62697716(满); DBA2 群：62697977(满)DBA3 群：62697850(满)

DBA 超级群：63306533(满); DBA4 群：83829929(满) DBA5群： 142216823(满)

DBA6 群：158654907(满) DBA7 群：69087192(满)DBA8 群：172855474

DBA 超级群2：151508914 DBA9群：102954821 聊天 群：40132017(满)

--加群需要在备注说明Oracle表空间和数据文件的关系，否则拒绝申请