ORACLE ORA-00600 [17059][]错误的排除

      真的很长时间没有写些文字了，惭愧。不过真的很忙，管理工作不好做呀。不过“忙里偷闲”老本行不能丢。

      前两天后台日志和线上程序都报了这样的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一厢情愿的事情，时常不会太准确的，并且存在性能上的风险。-:)

©著作权归作者所有：来自51CTO博客作者Larry.Yue的原创作品，如需转载，请注明出处，否则将追究法律责任

ORACLE职场休闲ORACLE足迹