ORA-600(12235)错误

在数据库后台查询到了这个错误，但是开始并没有发现导致这个错误的原因，直到今天的一次手误重现了错误，才找到问题的原因。

 

 

首先先看一下错误信息：

Errors in file /opt/oracle/admin/data01/bdump/data01_ora_29840.trc:
ORA-00600: internal error code, arguments: [12235], [], [], [], [], [], [], []

而详细的trace描述为：

bash-2.03$ more /opt/oracle/admin/data01/bdump/data01_ora_29840.trc
/opt/oracle/admin/data01/bdump/data01_ora_29840.trc
Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
ORACLE_HOME = /opt/oracle/product/9.2.0
System name:    SunOS
Node name:      bjdb03
Release:        5.8
Version:        Generic_108528-22
Machine:        sun4u
Instance name: data01
Redo thread mounted by this instance: 1
Oracle process number: 0
29840

Oracle program name: oracle@bjdb03
*** 2008-05-20 14:26:18.808
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [12235], [], [], [], [], [], [], []
Current SQL information unavailable - no session.
----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------
ksedmp()+328         CALL     ksedst()+0           000000009 ? 000000000 ?
                                                   000000000 ? 00000004A ?
                                                   FFFFFFFF7FFFE248 ?
                                                   1031D6908 ?
kgeriv()+208         PTR_CALL 0000000000000000     000000000 ? 000103400 ?
                                                   0001035DA ? 000102C00 ?
                                                   1035DA000 ? 1035DAE28 ?
kgesiv()+108         CALL     kgeriv()+0           1035DB088 ? 000000000 ?
                                                   000002FCB ? 000000000 ?
                                                   FFFFFFFF7FFFEB78 ?
                                                   1035DC458 ?
ksesic0()+92         CALL     kgesiv()+0           1035DB088 ? 000000000 ?
                                                   000002FCB ? 000000000 ?
                                                   FFFFFFFF7FFFEB78 ?
                                                   000000000 ?
opirip()+1528        CALL     ksesic0()+0          000002FCB ? 00000000D ?
                                                   FFFFFFFF7FFFEBE0 ?
                                                   000000000 ? 000000800 ?
                                                   38001F568 ?
opidrv()+1012        CALL     opirip()+0           000000000 ? 000000001 ?
                                                   000380000 ? 1035DAE28 ?
                                                   1035DFFC8 ? 000002C00 ?
sou2o()+16           CALL     opidrv()+0           000000000 ? 000000000 ?
                                                   1035DABAC ? 000000032 ?
                                                   1035DB088 ? 000103400 ?
main()+308           CALL     sou2o()+0            FFFFFFFF7FFFF930 ?
                                                   000000032 ? 000000000 ?
                                                   000000000 ? 000039858 ?
                                                   000000000 ?
_start()+380         CALL     main()+0             000000001 ? 000000000 ?
                                                   FFFFFFFF7FFFFA88 ?
                                                   000000000 ? 000000000 ?
                                                   100000000 ?

无论是从上面的Oracle进程号码看，还是从会话信息看，这个trace文件都与众不同。首先这个trace文件并没有对应任何的会话信息，而且从Oracle进程号看也和普通的trace文件不同。

简单了查询了一下metalink，当时并未发现和这个现象比较相似的问题。由于又缺少会话信息，不知道是谁做了什么，因此也一直没有办法进行诊断。

知道今天一时手误，认为telnet还没有登陆，于是输入用户名oracle并回车。输入完成后才发现这个telnet窗口已经是登陆上的，换句话说，实际上执行了一个oracle命令。

查询后台alert文件，发现了这个ORA-600 [12235]错误。

其实这个错误以前也碰到过，alert文件中前面出现的那次就是这样引起的，还记得当时特意查询了metalink，文档上描述说这个错误可以忽略，只是由于手工执行了oracle命令造成的。只是当时还没有记录bug的习惯，因此在检查以往的错误信息的时候，就想不起这件事了。

不过这次查询文档确实也并不是很仔细，因为在文档Doc ID:  Note:33174.1中描述了下面的文字：

  Ignore the error.

  One of the most common reasons for this error to be reported is that someone typed 'oracle' manually at the OS prompt.

如果刚刚不小心执行了oracle命令，并在后台检查到了这个错误，那么问题很容易定位，但是如果是在后台日志中看到了这个错误，恐怕很难联想到是这个错误造成的。因此这里还是记录下来，避免以后再次碰到同样的错误时，仍然需要花大量的事件定位才发现是一个碰到过多次的问题。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/4227/viewspace-293468/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/4227/viewspace-293468/