昨天上午数据库alert日志突然出现600错误：
Thu Jan 28 10:29:48 2010
Errors in file /u01/admin/erpdb/udump/erpdb1_ora_447360.trc:
ORA-00600: internal error code, arguments: [17285], [0x110467578], [4294967295], [0x7000003EB46A690], [], [], [], []
ORA-00604: error occurred at recursive SQL level 1
ORA-01013: user requested cancel of current operation
Thu Jan 28 10:29:50 2010
Trace dumping is performing id=[cdmp_20100128102950]Thu Jan 28 10:30:03 2010
Errors in file /u01/admin/erpdb/udump/erpdb1_ora_447360.trc:
ORA-00600: internal error code, arguments: [17285], [0x110467578], [4294967295], [0x7000003EB46A690], [], [], [], []
Thu Jan 28 10:30:04 2010
Errors in file /u01/admin/erpdb/udump/erpdb1_ora_447360.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
ORA-00600: internal error code, arguments: [17285], [0x110467578], [4294967295], [0x7000003EB46A690], [], [], [], []
这里也明确提示了是执行SQL导致的问题，而用户取消了这个操作。通过查看trace文件也确实发现了干坏事的人：
O/S info: user: sxw, term: ITB_SXW_XP, ospid: 5392:4416, machine: XC\ITB_SXW_XP
program: plsqldev.exe
application name: PL/SQL Developer, hash value=1190136663
action name: Test Window - Script for procedu, hash value=3367543201
经过确认确实是有开发人员执行一个大存储过程，长时间没出来结果后强制取消了操作。通过AWR报告也印证了这一点：
可见这个SQL花费了13分钟，而执行次数确是0次。
虽然没引起实例崩溃，但在生产环境调试程序仍然要小心，数据库是脆弱的，我们必须对其心存敬畏。
以前出过类似的问题：
http://www.eygle.com/archives/2009/12/ora_600_17285.html