ORA-00600(kdsgrp1)

今天早上收到一封alter日志的报警邮件

alter日志如下:

Errors in file /tol/app/oracle/admin/coredb/diag/rdbms/dg_111/coredb/trace/coredb_ora_9686.trc  (incident=67937):
ORA-00600: 内部错误代码, 参数: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /tol/app/oracle/admin/coredb/diag/rdbms/dg_111/coredb/incident/incdir_67937/coredb_ora_9686_i67937.trc
Wed Dec 04 09:31:45 2013

trace coredb_ora_9686.trc 的内容：
Dump continued from file: /tol/app/oracle/admin/coredb/diag/rdbms/dg_111/coredb/trace/coredb_ora_9686.trc
ORA-00600: ?<86><85>é<83>¨é<94><99>èˉˉ??￡??<81>, ?<8f><82>?<95>°: [kdsgrp1], [], [], [], [], [], [], [], [], [], [], []

========= Dump for incident 67937 (ORA 600 [kdsgrp1]) ========

*** 2013-12-04 09:31:41.554
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=20hf68y2skdh6) -----
select * from user_course_unit where user_id=:1 and account_id=:2 and course_id=:3  order by lasttime desc

trace coredb_ora_9686_i67937.trc的内容
* kdsgrp1-1: *************************************************
            row 0x090c1fee.22 continuation at
            0x090c1fee.22 file# 36 block# 794606 slot 34 not found
KDSTABN_GET: 0 ..... ntab: 1
curSlot: 34 ..... nrows: 35
kdsgrp - dump CR block dba=0x090c1fee
Block header dump:  0x090c1fee
 Object id on Block? Y
 seg/obj: 0x3817  csc: 0x02.13bc3e84  itc: 2  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x90c0486 ver: 0x01 opc: 0
     inc: 0  exflg: 0

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0027.00d.000c7249  0x03414823.259e.20  C---    0  scn 0x0002.13bc3aa1
0x02   0x000a.002.0042a7d5  0x0781021b.722d.07  C---    0  scn 0x0002.13bc3aac
bdba: 0x090c1fee

ORA-00600(kdsgrp1) 之前没有遇到过，查了一下，这个错误很多情况下可能是跟表或者索引有逻辑坏块有关，也有可能是bug

从上面的信息，我们很容易看到是哪个对象引起的错误

----- Current SQL Statement for this session (sql_id=20hf68y2skdh6) -----
select * from user_course_unit where user_id=:1 and account_id=:2 and course_id=:3  order by lasttime desc

or

seg/obj: 0x3817 ---object id

or

file# 36 block# 794606  ---根据file id 和block id，可以从dba_extents里查到

检查是否真的有坏块：
SQL> select name from v$datafile where file# = 36;
NAME
------------------------------------------------------------------------------------------------------------------------
/tol/oradata/datafile/coredb/newcourse12.dbf

[oracle@dg_111 ~]$ dbv file='/tol/oradata/datafile/coredb/newcourse12.dbf' blocksize=8192

DBVERIFY: Release 11.2.0.1.0 - Production on Wed Dec 4 10:32:58 2013
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
DBVERIFY - Verification starting : FILE = /tol/oradata/datafile/coredb/newcourse12.dbf

DBVERIFY - Verification complete
Total Pages Examined         : 820224
Total Pages Processed (Data) : 605670
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 124147
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 56518
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 33889
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Total Pages Encrypted        : 0
Highest block SCN            : 331511232 (2.331511232)

检查发现没有坏块，再查询上面的sql，也没有再报错

由于这个是DG的物理备库，我感觉应该是因为redo应用导致的，如果报错不是频繁，没有引起系统性能等问题，暂时可以忽略不管。