今天早上刚上班，突然想起来一件事情，上周五晚上升级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
Global Cache Service (LMS) - In a Real Application Clusters environment, this process manages resources and provides inter-instance resource control
之后节点3打完补丁再次启动这个错误就消失了，在此记录一下！
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/25618347/viewspace-713539/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
BUG9949948的处理过程
下一篇：
oracle坏块问题的解决
请登录后发表评论
登录
全部评论
