很多刚入行的DBA往往一看有ORA-600这类错误就不知所措，直接就想寻求中高级DBA支持，甚至在网上还看到有人说，判断一个Oracle DBA是否达到中级以上，就是看其是否可以独立思考处理ORA-600这类问题，而实际上ORA-600这个错误集合中的确有很多跟bug相关，有些甚至是MOS也搜不到的，但同样也有很多是很简单的，并不需要你去深入分析trc，比对call stack匹配bug什么的。就比如今天遇到的一则案例，客户发现DG备库应用出现了问题，进一步查看告警日志发现有报错ORA-600[2619]，并因此导致mrp进程异常终止。
整个处理过程因为非常简单，文字描述记录下处理过程：
- 1.了解到客户之前有做过清理归档的动作，因为之前告警目录空间满；
- 2.尝试手工拉起mrp进程，发现不成功，尝试应用日志时同样是报错ORA-600[2619]；
- 3.通过MOS查询匹配到：ORA-600[2619] During Physical Standby Recovery [1138913.1]
ORA-600[2619] is raised due to an invalid next_change# detected in archive log.
In this case, it is caused by the archive log disk space ran out on standby site, causing that archive log not fully written on disk. This lead to ORA-600[2619] when the archive log was applied.
- 4.结合之前空间满的事实，怀疑是否该归档文件也存在尚未完全写入到磁盘的情况；
- 5.主备库比对这个归档日志的大小，发现大小是一致的；
- 6.通过md5sum比对主备库该归档日志，发现md5不一样，这说明该归档文件还是存在差异；
- 7.将备库的这个归档文件mv重命名备份，然后将主库的这个归档文件重新拷贝到备库，重新比对md5确认一致；
- 8.再次尝试拉起mrp进程，发现不再报错，解决问题。
总结：整个处理过程完全没有难度，即便是初级DBA，只要对原理有基本了解，也是可以轻松搞定的。
来源：oschina
链接：https://my.oschina.net/u/4315748/blog/4327271