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:

针对ORA-00600 的解决一般 Oracle Support 会给出补丁修复和 Workaround 绕过该问题的 2 类解决方案，当然也还是存在Oracle 研发部门无法在他们的环境中重现你所遇到的ORA-00600的可能性，这意味着部分600错误可能是官方无解的，也可能是Oracle Support 已经掌握某种Workaround 的方法，但是没有在现有的Note 文档中提交的情况，当然这都是少数现象。

如果实在找不到可用的解决方案，或者您的产品数据库有极高的服务等级要求，那么提交Service Request (SR) 有些老人还是习惯于称其为Tar的服务请求，可能是一种终极手段。但是我不得不说一句并非所有的问题都是有解的，您使用的TV 电视机的制造商可以解决所有其在使用环节中遇到的问题吗？理论上是可以的，但是当解决一个问题的成本非常高时，制造商可能更情愿给你换一台电视，但是您的产品数据库可以轻易更换吗？这是一个值得深思的问题，也是RDBMS市场的一条悖论。

来读读由Maclean Liu 所编写的ORA-00600 Oracle Internal Error 的相关文章：

ORA-00600

Comments

Comment 取消回复