10.2.0.5.0-RAC关闭一个节点时遭遇ORA-600错误

今天早上刚上班，突然想起来一件事情，上周五晚上升级RAC到10.2.0.5.4时，重启3节点的时候，alert日志里居然报了600错误，具体如下：

ORA-00600: internal error code, arguments: [kjccgmb:1], [], [], [], [], [], [], []

ORA-00600: internal error code, arguments: [kjccgmb:1], [], [], [], [], [], [], []

ORA-00600: internal error code, arguments: [kjccgmb:1], [], [], [], [], [], [], []

ORA-00600: internal error code, arguments: [kjccgmb:1], [], [], [], [], [], [], []

ORA-00600: internal error code, arguments: [kjccgmb:1], [], [], [], [], [], [], []

查询对应的trace文件，详细信息如下：

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

With the Partitioning, Real Application Clusters, OLAP, Data Mining

and Real Application Testing options

ORACLE_HOME = /oracle/product/10.2.0/db_1

System name:    Linux

Node name:      rac3

Release:        2.6.18-128.el5

Version:        #1 SMP Wed Dec 17 11:41:38 EST 2008

Machine:        x86_64

Instance name: yesmynet3

Redo thread mounted by this instance: 0 

Oracle process number: 16

Unix process pid: 3642, image: oracle@rac3 (LMS5)

*** SERVICE NAME:() 2011-11-22 23:00:45.221

*** SESSION ID:(1315.3) 2011-11-22 23:00:45.221

 0 GCS shadows cancelled, 0 closed

 0 GCS resources traversed, 0 cancelled

 LMS 5: 1826496 GCS resources on freelist, 1826616 on array, 1826618 allocated

 0 GCS shadows traversed, 0 replayed, 0 duplicates

RCFG(14) lms 5 finished replaying gcs resources

 0 write requests issued in 1247 GCS resources

 3 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1350 GCS resources

 7 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1130 GCS resources

 1 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1155 GCS resources

 1 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1243 GCS resources

 2 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1263 GCS resources

 9 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1205 GCS resources

 0 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1200 GCS resources

 0 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1256 GCS resources

 1 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1215 GCS resources

 14 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1214 GCS resources

 0 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1188 GCS resources

 1 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1207 GCS resources

 4 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1265 GCS resources

 12 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1175 GCS resources

 3 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1223 GCS resources

 1 PIs marked suspect, 0 flush PI msgs

 0 write requests issued in 1213 GCS resources

 4 PIs marked suspect, 0 flush PI msgs

lms 5 finished fixing gcs write protocol

*** 2011-11-22 23:01:21.605

DRM(40) win(1) lms 5 finished replaying gcs resources

 lms 5 finished fixing gcs write protocol

DRM(40) win(2) lms 5 finished replaying gcs resources

 lms 5 finished fixing gcs write protocol

DRM(40) win(3) lms 5 finished replaying gcs resources

 lms 5 finished fixing gcs write protocol

DRM(40) win(4) lms 5 finished replaying gcs resources

 lms 5 finished fixing gcs write protocol

DRM(40) win(5) lms 5 finished replaying gcs resources

 lms 5 finished fixing gcs write protocol

DRM(40) win(6) lms 5 finished replaying gcs resources

 lms 5 finished fixing gcs write protocol

kjdrvalidRMno: msg type 34 from node 1 dropped

   FUSION MSG 0x2adc1cffc280,34 from[1,11978] ver[14,39] ln 128 sq[1,8]

        CLOSE [0x1eb9.120000, 19.1] shadow [(nil),0] seq 0x2 act 1

          client [0x1d2fb2368,10] reqid 10 ordered 0

          grant 1 convert 0 role 0

          pi [0x0.0x0] flags 0x0 state 0x20

          disk scn 0x0.0 writereq scn 0x0.0 rreqid 0

          msgRM# 39 bkt# 25559 drmbkt# 25559

     pkey 19.1, stat 5, masters[32767, 32767->2], reminc 0, RM# 0 flg 0x6

     hv 61 [stat 0x0, 2->2, wm 32767, RMno 0, reminc 14, dom 0]

     kjga st 0x4, step 0.32.0, cinc 14, rmno 39, flags 0x20

     lb 24576, hb 28671, myb 25559, drmb 25559, apifrz 1

kjmvalidate: drm drop a message RMno 39 from 1 type 34

  mver 14 myver 14 seq 0.759 rseq 0.758 flag x2d

DRM(40) win(7) lms 5 finished replaying gcs resources

 lms 5 finished fixing gcs write protocol

DRM(40) win(8) lms 5 finished replaying gcs resources

 lms 5 finished fixing gcs write protocol

由报错信息，大概可推测是RAC节点间通信造成的，仔细回想当时的情景，在打补丁的时候，RAC1节点打完之后，启动然后停掉RAC2，打完之后启动再停RAC3节点的，当RAC2节点全部启动起来之后，立马停RAC3节点的时候，告警日志就开始抛这个错误了，应该是lms进程在各节点间通信的时候发生了错误，其在 Oracle 10g中的定义：
Global Cache Service (LMS) - In a Real Application Clusters environment, this process manages resources and provides inter-instance resource control

 

之后节点3打完补丁再次启动这个错误就消失了，在此记录一下！

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25618347/viewspace-713539/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25618347/viewspace-713539/