ORACLE ORA-00600 [17059][]错误的排除
版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://miracle.blog.51cto.com/255044/69829 |
真的很长时间没有写些文字了,惭愧。不过真的很忙,管理工作不好做呀。不过“忙里偷闲”老本行不能丢。 前两天后台日志和线上程序都报了这样的ORACLE错误 ORA-00600: internal error code, arguments: [17059], [0xC0000000BD85D928], [], [], [], [], [], [] 基本上ORACLE的600错误是非常让人讨厌的错误。查阅了一下: ERROR: ORA-600 [17059] [a] VERSIONS: versions 7.1 to 10.1 DESCRIPTION: While building a table to hold the list of child cursor dependencies relating to a given parent cursor, we exceed the maximum possible size of the table. ARGUMENTS: Arg [a] Object containing the table FUNCTIONALITY: Kernel Generic Library cache manager IMPACT: PROCESS FAILURE NON CORRUPTIVE - No underlying data corruption. SUGGESTIONS: One symptom of this error is that the session will appear to hang for a period of time prior to this error being reported. If the Known Issues section below does not help in terms of identifying a solution, please submit the trace files and alert.log to Oracle Support Services for further analysis. Issuing this SQL as SYS (SYSDBA) may help show any problem objects in the dictionary: select do.obj#, po.obj# , p_timestamp, po.stime , decode(sign(po.stime-p_timestamp),0,'SAME','*DIFFER*') X from sys.obj$ do, sys.dependency$ d, sys.obj$ po where P_OBJ#=po.obj#(+) and D_OBJ#=do.obj# and do.status=1 /*dependent is valid*/ and po.status=1 /*parent is valid*/ and po.stime!=p_timestamp /*parent timestamp not match*/ order by 2,1 ; Normally the above select would return no rows. If any rows are returned the listed dependent objects may need recompiling. 非法的对象是没有了,应该是child cursor过多造成的。联想因为某种原因(不能说了),我修改了一个数据库参数: cursor_sharing = TRUE 立刻捕捉这句SQL SELECT sequence_id,sercode,content,area FROM XXX WHERE sendzt=:"SYS_B_0" AND Checkzt=:"SYS_B_1" AND starttime < :"SYS_B_2" AND starttime > :"SYS_B_3" AND rownum < :"SYS_B_4" 虽然看到的SQL貌似已经完成了绑定,但是一定还是有些问题的。当研发同事查询到这句SQL的时候告诉我:“没有问题是绑定的。”,但是这句SQL的rownum小于的是一个确切数字(10),没错就是它!让研发同事也按照其他变量的方式绑定这个确切的“变量”。将修改的程序重新上线,LOAD=1,VERSION_COUNT=1而执行次数超过12万(程序运行2个小时后),不再报600错! 我的这个解决办法只是根据数据库现有的模式因势利导给出的。这种cursor_sharing = TRUE方式其实一直存在很多争议。毕竟的“偷窥变量”是ORACLE一厢情愿的事情,时常不会太准确的,并且存在性能上的风险。-:) 本文出自 “Be the miracle!” 博客,请务必保留此出处http://miracle.blog.51cto.com/255044/69829 本文出自 51CTO.COM技术博客 |



Larry.Yue
博客统计信息
热门文章
最新评论
友情链接