使用utlrp.sql编译失效对象引发的ORA-600错误。
[@more@]
错误信息如下:
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的时候以串行方式运行。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-1060694/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/4227/viewspace-1060694/