ORA-600

http://www.oracledatabase12g.com/archives/ora-00600.html

ORA-600 Internal Error 是我们在学习使用Oracle的过程中，必然会经历的一个站点。

很多同学一遇到ORA-600 错误信息，就认为自己碰到了Oracle Database软件的Bug，实际上这一观点是不准确的。

ORA-600可能由多种原因造成，包括软件漏洞、Bug、程序运行异常、内存讹误和数据讹误造成。

举例来说在数据异常恢复过程中常遇到的ORA-600[2662](Block SCN is ahead of Current SCN) 和ORA-600[4000](回滚段rollback数据块时发现rollback segment存在讹误)错误 均是数据讹误引起的而非bug 。

我们在分析ORA-600 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-600[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-600 argument 一般我们可以通过 在Metalink 上搜索 ORA-600 + 第一位 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