客户的数据库系统在下午突然报错，作为报表系统的数据是从主生产库通过物化视图刷新的方式定期更新的，但是在错误发生以后，每次物化视图的快速刷新都会产生ORA-600错误。

ORA-12012: error on auto execute of job 467
ORA-20999: HD_GT_DEXM_HYMX refresh failed:-600
ORA-00600: internal error code, arguments: [kghfrf1], [0x000000000], [], [], [], [], [], []
ORA-06512: at "user.REFRESH_ALL_SNAPSHOT", line 31
ORA-06512: at line 1

在Metalink中搜索[kghfrf1]，虽然有相关文章，但是浏览之后发现跟客户的情况都不匹配。首先是症状不相同，并没有任何一个案例是在物化视图刷新的时候报错的；其次是数据库版本不同，客户数据库为Oracle 9208 RAC，在这个版本中并没有任何已知的未修复的bug会导致ORA-600 [kghfrf1]错误；最后通过查看客户trace文件中堆栈信息，也跟Metalink文章中并不匹配。

对于此ORA-600错误的解释是：

@ We are attempting to free a freeable chunk of space and generate this
@ exception trying to free a NULL pointer.
@
@ This is a memory corruption with no data corruption

在系统不繁忙期，让客户尝试执行以下命令用以清理Shared Pool。

ALTER SYSTEM FLUSH SHARED_POOL;

幸运的是，执行完这条命令之后一切错误都消失了。

实际上本文重点不在于解决这个问题的方法，而是试图梳理一下普遍的解决Oracle数据库故障的流程。
1. 检查alertlog，以及发生ORA-600错误时候产生的trace文件，在trace文件中查看是否有Current SQL记录（查找Current SQL statement for this session字样），对过比对确认具体是什么操作引起了ORA-600错误。在本例中，显示为物化视图刷新。

begin dbms_mview.refresh('HD_GT_DEXM_HYMX','f');end;

2. 查询Metalink，明确发生该错误的原因以及可能有的解决方法，在解决方法不确定的时候，继续查看是否有类似的bug，每一份bug报告里面通常都有stack信息，跟trace文件中“—– Call Stack Trace —– ”部分做比较，如果堆栈信息完全匹配，那么基本上可以认定是相同的bug，之后再继续查看该bug是否有解决方法或者是相应的Patch。

3. 如果找不到相应的bug或者是解决方法，那么根据ORA-600的错误原因，运用自己的troubleshooting知识来尝试几种方法，比如本例中清理共享池的提议。或者，重启数据库也是值得尝试的。

4. 仍然无法解决，那么首先需要在Metalink中提交一份SR，别管有用没用，别管响应时间有多长，至少做了该做的本份，其次是寻求Oracle官方支持，如果客户足够大牌，那么可能可以要求Oracle单独为此客户发布一个补丁。

4. 如果都不行，此错误也无可避免，而该错误又将严重影响到生产系统，并且错误发生频率还不低，那么这恐怕是该升级数据库版本的时机了，11gR2，不错的选择。