使用utlrp.sql编译失效对象引发的ORA-600错误。

错误信息如下：

Sat Dec 19 05:29:59 2009
Completed: ALTER DATABASE OPEN
Sat Dec 19 05:30:20 2009
SERVER COMPONENT id=UTLRP_BGN: timestamp=2009-12-19 05:30:20
Sat Dec 19 05:31:09 2009
Errors in file /oraclelog/admin/orcl3/bdump/orcl31_cjq0_24952.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 576 bytes of shared memory ("shared pool","update seq$ set increment$=:...","sql area","ckydef : kkdlcky")
Sat Dec 19 05:31:10 2009
Errors in file /oraclelog/admin/orcl3/bdump/orcl31_cjq0_24952.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","select job, nvl2(last_date, ...","sql area","tmp")
Sat Dec 19 05:31:14 2009
Errors in file /oraclelog/admin/orcl3/bdump/orcl31_j001_25676.trc:
ORA-00600: internal error code, arguments: [koksadqb1], [4031], [], [], [], [], [], []
Sat Dec 19 05:31:14 2009
Errors in file /oraclelog/admin/orcl3/bdump/orcl31_j008_25697.trc:
ORA-12012: error on auto execute of job 136625
ORA-04031: unable to allocate ORA-04031: unable to allocate 248 bytes of shared memory ("shared pool","update seq$ set increment$=:...","Typecheck","qsmksol : qsmg_alloc_sol")
ORA-06512: at "SYS.UTL_RECOMP", line 636
ORA-06512: at line 1
bytes of shared memory ("","","","")
Sat Dec 19 05:31:15 2009
Errors in file /oraclelog/admin/orcl3/bdump/orcl31_cjq0_24952.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 1048 bytes of shared memory ("shared pool","select job, nvl2(last_date, ...","Typecheck","kgghteInit")
Sat Dec 19 05:31:23 2009
Trace dumping is performing id=[cdmp_20091219053123]
Sat Dec 19 05:31:39 2009
SERVER COMPONENT id=UTLRP_END: timestamp=2009-12-19 05:31:39
Sat Dec 19 05:35:09 2009
SERVER COMPONENT id=UTLRP_BGN: timestamp=2009-12-19 05:35:09
SERVER COMPONENT id=UTLRP_END: timestamp=2009-12-19 05:35:18

这个ORA-600错误在METALINK上找不到任何记录，不过从之前的ORA-4031错误，以及这个错误的第二个参数可以判断，导致这个错误的原因就是ORA-4031错误。

根据错误之前的信息可以看到，数据库刚刚启动完毕，而马上就出现ORA-4031错误是很不正常的，检查了启动参数中共享池的配置，更是达到了3G以上，这就更没有道理出现ORA-4031错误了。

观察报错之前的上一条信息发现，原来在报错之前在运行UTLRP.SQL脚本对失效对象进行编译。这个现象和一个未确定的BUG描述Bug 8442907 : ORA-4031 RUNNING UTLRP.SQL OR ANY PX QUERY非常接近。

虽然第一次运行编译脚本失败，根据日志信息，马上进行的第二次UTLRP.SQL调用成功了，这说明无论这个ORA-600还是ORA-4031错误的出现都是比较偶然的，考虑到Oracle没有任何关于当前问题的描述，如果碰到了类似的问题，可以考虑在调用UTLRP的时候以串行方式运行。