使用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的时候以串行方式运行。