求教：ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2]

mapele

数据库突然宕机，求各位大侠帮忙分析,谢谢！警告日志如下：Errors in file e:\app\administrator\diag\rdbms\llcallsb\llcall\trace\llcall_ora_1712.trc  (incident=57049):
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
Incident details in: e:\app\administrator\diag\rdbms\llcallsb\llcall\incident\incdir_57049\llcall_ora_1712_i57049.trc
Thu Jul 26 12:22:04 2012
Trace dumping is performing id=[cdmp_20120726122204]
Thu Jul 26 12:22:05 2012
Errors in file e:\app\administrator\diag\rdbms\llcallsb\llcall\trace\llcall_ora_1712.trc  (incident=57050):
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
Incident details in: e:\app\administrator\diag\rdbms\llcallsb\llcall\incident\incdir_57050\llcall_ora_1712_i57050.trc
Thu Jul 26 12:22:07 2012
Sweep [inc][57050]: completed
Sweep [inc][57049]: completed
Sweep [inc2][57049]: completed
Errors in file e:\app\administrator\diag\rdbms\llcallsb\llcall\trace\llcall_ora_1712.trc  (incident=57051):
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
Incident details in: e:\app\administrator\diag\rdbms\llcallsb\llcall\incident\incdir_57051\llcall_ora_1712_i57051.trc
Trace dumping is performing id=[cdmp_20120726122212]
Thu Jul 26 12:22:17 2012
Trace dumping is performing id=[cdmp_20120726122217]
Thu Jul 26 12:22:17 2012
Errors in file e:\app\administrator\diag\rdbms\llcallsb\llcall\trace\llcall_ora_1712.trc  (incident=57052):
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
Incident details in: e:\app\administrator\diag\rdbms\llcallsb\llcall\incident\incdir_57052\llcall_ora_1712_i57052.trc
Errors in file e:\app\administrator\diag\rdbms\llcallsb\llcall\trace\llcall_ora_1712.trc:
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
Trace dumping is performing id=[cdmp_20120726122223]
Thu Jul 26 12:22:26 2012
Errors in file e:\app\administrator\diag\rdbms\llcallsb\llcall\trace\llcall_dbw0_1356.trc  (incident=56081):
ORA-00600: 内部错误代码, 参数: [kcbo_switch_q_bg_1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: e:\app\administrator\diag\rdbms\llcallsb\llcall\incident\incdir_56081\llcall_dbw0_1356_i56081.trc
Errors in file e:\app\administrator\diag\rdbms\llcallsb\llcall\trace\llcall_dbw0_1356.trc  (incident=56082):
ORA-00600: 内部错误代码, 参数: [kcbo_dump_q_1], [117177736], [0], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_q_bg_1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: e:\app\administrator\diag\rdbms\llcallsb\llcall\incident\incdir_56082\llcall_dbw0_1356_i56082.trc
Errors in file e:\app\administrator\diag\rdbms\llcallsb\llcall\trace\llcall_dbw0_1356.trc:
ORA-00600: 内部错误代码, 参数: [kcbo_switch_q_bg_1], [], [], [], [], [], [], [], [], [], [], []
DBW0 (ospid: 1356): terminating the instance due to error 471

mapele

r\diag\rdbms\llcallsb\llcall\incident\incdir_57050\llcall_ora_1712_i57050.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows NT Version V6.1  
CPU                 : 4 - type 8664, 4 Physical Cores
Process Affinity    : 0x0x0000000000000000
Memory (Avail/Total): Ph:8547M/24559M, Ph+PgF:11805M/28557M
Instance name: llcall
Redo thread mounted by this instance: 1
Oracle process number: 131
Windows thread id: 1712, image: ORACLE.EXE (SHAD)


*** 2012-07-26 12:22:06.005
*** SESSION ID:(1213.12182) 2012-07-26 12:22:06.005
*** CLIENT ID:() 2012-07-26 12:22:06.005
*** SERVICE NAME:(SYS$USERS) 2012-07-26 12:22:06.005
*** MODULE NAME:(fsbill@mywewe (TNS V1-V3)) 2012-07-26 12:22:06.005
*** ACTION NAME:() 2012-07-26 12:22:06.005

Dump continued from file: e:\app\administrator\diag\rdbms\llcallsb\llcall\trace\llcall_ora_1712.trc
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [kcbo_switch_cq_2], [], [], [], [], [], [], [], [], [], [], []

========= Dump for incident 57050 (ORA 600 [kcbo_switch_cq_2]) ========
----- Beginning of Customized Incident Dump(s) -----
BH (0x0000000523E2F898) file#: 34 rdba: 0x08813e9d (34/81565) class: 1 ba: 0x0000000520EB2000
  set: 9 pool 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25
  dbwrid: 0 obj: 469863 objn: 469863 tsn: 14 afn: 34 hint: f
  hash: [0x00000005B2451110,0x00000005B2451110] lru: [0x0000000523E2FD10,0x000000053FF693E0]
  ckptq: [0x0000000417EC8478,0x0000000553EDC648] fileq: [0x00000005AE0AA5F0,0x000000033FFEA1B8] objq: [0x000000049BDFAFB8,0x000000052FE45DE8]
  use: [0x00000005ADFCEDB8,0x00000005ADFCEDB8] wait: [NULL]
  st: XCURRENT md: EXCL tch: 79
  flags: buffer_dirty mod_started block_written_once redo_since_read
  change state: NOT_ACTIVE_YET
  change count: 1
  LRBA: [0x2d71.1991.0] LSCN: [0x0.2328572b] HSCN: [0x0.2328572b] HSUB: [65535]
  cr pin refcnt: 0 sh pin refcnt: 0
Dump of buffer cache at level 10 for tsn=14, rdba=142687901
BH (0x0000000523E2F898) file#: 34 rdba: 0x08813e9d (34/81565) class: 1 ba: 0x0000000520EB2000
  set: 9 pool 3 bsz: 8192 bsi: 0 sflg: 1 pwc: 0,25
  dbwrid: 0 obj: 469863 objn: 469863 tsn: 14 afn: 34 hint: f
  hash: [0x00000005B2451110,0x00000005B2451110] lru: [0x0000000523E2FD10,0x000000053FF693E0]
  ckptq: [0x0000000417EC8478,0x0000000553EDC648] fileq: [0x00000005AE0AA5F0,0x000000033FFEA1B8] objq: [0x000000049BDFAFB8,0x000000052FE45DE8]
  use: [0x00000005ADFCEDB8,0x00000005ADFCEDB8] wait: [NULL]
  st: XCURRENT md: EXCL tch: 79
  flags: buffer_dirty mod_started block_written_once redo_since_read
  change state: NOT_ACTIVE_YET
  change count: 1
  LRBA: [0x2d71.1991.0] LSCN: [0x0.2328572b] HSCN: [0x0.2328572b] HSUB: [65535]
  cr pin refcnt: 0 sh pin refcnt: 0
  Using State Objects
    ----------------------------------------
    SO: 0x00000005ADFCED38, type: 35, owner: 0x00000005A1025728, flag: INIT/-/-/0x00 if: 0x1 c: 0x1
     proc=0x00000005B97C2180, name=buffer handle, file=kcb2.h LINE:2504, pg=0
    (buffer) PR: 0x00000005B97C2180 FLG: 0x0
    class bit: 0x2
     cr[0]:
     sh[0]:
    kcbbfbp: [BH: 0x0000000523E2F898, LINK: 0x00000005ADFCEDB8]
    type: normal pin
    where: kdiwh22: kdifind, why: 0
  Buffer being modified, corruption checks may be unreliable
  buffer tsn: 14 rdba: 0x08813e9d (34/81565)
  scn: 0x0000.22f9166b seq: 0x02 flg: 0x02 tail: 0x166b0602
  frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x0000000520EB2000 to 0x0000000520EB4000
520EB2000 0000A206 08813E9D 22F9166B 02020000  [.....>..k.."....]
520EB2010 00000000 00000002 00072B67 22F9166A  [........g+..j.."]
520EB2020 00000000 00320002 08813E80 001D0011  [......2..>......]

wzq609

也遇到了一样的问题

Maclean Liu(刘相兵

ORA-00600

ORA-00600 Internal Error 是我们在学习使用Oracle的过程中，必然会经历的一个站点。
很多同学一遇到ORA-00600 错误信息，就认为自己碰到了Oracle Database软件的Bug，实际上这一观点是不准确的。
ORA-00600可能由多种原因造成，包括软件漏洞、Bug、程序运行异常、内存讹误和数据讹误造成。
举例来说在数据异常恢复过程中常遇到的ORA-00600[2662](Block SCN is ahead of Current SCN) 和ORA-00600[4000](回滚段rollback数据块时发现rollback segment存在讹误)错误 均是数据讹误引起的而非bug 。
我们在分析ORA-00600 Internal Error， 定位具体故障的时候，从600 trace中能够找到的最为有用的信息就是600所附带的Argument信息：

实际600 Internal Error 的Argument 可以分成 2种：

a.   第一位是数字类型的Argument ， 例如之前说的2662 和 4000 ， 不同的数字代表不同的错误含义。 数字类型的argument 所代表的内部错误相对更为普遍、常见。  实际这些数字Argument 也是来源于 不同的Oracle Kernel Function内核函数，如kddummy_blkchk、kclchkinteg_2 等； 但是因为这些错误较为常见， 一方面为了照顾用户的使用体验( 用户对RDBMS软件的内核函数是不感兴趣的，当然可能我们感兴趣)， 另一方面这些函数涉及到很多Oracle的内部原理，为了不让这些内核函数暴露在外， 所以Oracle开发部门对这些常见的Internal Error状态进行了编码，转换成数字代码的形式， 实际上这些数字代码形式的Argument 都有其与OERR类似的注释，这些注释没有被包含在oraus.msg中，但是在该msg文件中说明了这些注释仅仅是不公开， Oracle公司的员工是可以看到的：

Programmer's Comments
---------------------
If you wish to add comments regarding a message that should not be seen by
the public, use "// *Comment: " as follows:

   e.g.
       32769, 00000, "incompatible SQL*Net version"
        *Cause: An attempt was made to use an older version of SQL*Net that
         is incompatible with current version of ORACLE.

数字编码Argument 的Internal error 如果不只打印出一位的Argument的话，那么后续几位的Argument 一般都是有其实际意义的，如ORA-00600[2662]的后续Argument 的含义为：
ARGUMENTS:
Arg [a] Current SCN WRAP
Arg [b] Current SCN BASE
Arg [c] dependent SCN WRAP
Arg [d] dependent SCN BASE
Arg [e] Where present this is the DBA where the dependent SCN came from.
这就便于Oracle Support 来诊断和解决这些Internal Error。对于数字类型的Argument ，Metalink上一般会公开其后续Argument的含义，且因为这些问题较为常见，所以一般都已经提供专门的Resolved Solution 或者 Workaround 方法来提供。
总而言之数字编码的ORA-00600 argument 一般我们可以通过 在Metalink 上搜索 ORA-00600 + 第一位 Argument ，或者使用<ORA-600/ORA-7445 Error Look-up Tool [ID 153788.1]>诊断工具页面来找到相关的有用Note。

b. 函数名形式的Argument 。 这类Argument 代表的Internal Error 相对于前一种要出现的频率低一些， Oracle开发部门尚来没有在相关版本中将这些Internal Error 编码。 这样我们就可以看到出现问题的完整Kernel Function Name ， 可以使用ORA-600 + 第一位 Argument 在Metalink 上搜索来找到一些相关的Note ， 但是函数名形式的Argument  往往不能精确定位到问题 ，因为 不同的错误原因 可能在同一个内核函数中引发不同的异常 ， 而这个时候我们只能看到 函数名的Argument 信息。 更精确定位的 方式是找出 在调用这个函数时的 详细stack call ， 我们来看一个ORA-600[KCBZ_CHECK_OBJD_TYP_1]的stack call:

ksedst()+40
ksedmp()+168
ksfdmp()+32
kgerinv()+152
kgeasnmierr()+88
kcbassertbd3()+204
kcbz_check_objd_typ
kcbzib()+
kcbgtcr()+
ktecgsc()+168
ktecgetsh()+196
ktecgshx()+40
kteinicnt1()+648
ktssdrbm_segment()+
ktssdro_segment()+3
ktssdt_segs()+1128
ktmmon()+3500
ktmSmonMain()+64
ksbrdp()+1276
opirip()+
opidrv()+1088
sou2o()+120
opimai_real()+496
main()+240
$START$()+

注意以上stack call中 只有 ktmSmonMain -> kcbassertbd3 这部分是有意义的， 开始部分的main()-> ksbrdp() 是很普通的入口函数 ， 而从kgeasnmierr (Kernel generic Error ) 开始的代码是Oracle 报错层使用的函数 ， 都是对定位问题没有帮助的。 将这部分有用的stack call 填入Metalink <ORA-600/ORA-7445 Error Look-up Tool [ID 153788.1]> 600问题诊断页面的 stack call 栏 会以较严格的筛选条件找出问题相关的Note:

Maclean Liu(刘相兵

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!诗檀软件专业数据库修复团队服务热线 ： 400-690-3643 备用电话： 13764045638 邮箱：service@parnassusdata.com

ORACLE PRM是诗檀软件独立研发的ORACLE数据库灾难恢复软件，其具有全程图形化界面、简单高效等特点。
欢迎下载使用ORACLE PRM。 下载地址：http://parnassusdata.com/sites/d ... MForOracle_3206.zip