DataGuard备库遇到krrgv_scn8、krrfro_cachedscn和ORA-00355、ORA-00353、ORA-00312

【背景】

5月29日下午收到备库同步异常告警，检查告警日志发现提示ORA-00600: internal error code, arguments: [krrgv_scn8], [1], [462238206], [1], [433700865], [], [], [], [], [], [], []，查询mos发现是当前版本11.2.0.3已知BUG，Bug 16496896 - standby mrp crashed with ORA-600 [krrgv_scn8] (Doc ID 16496896.8)，提示是一个或多个的redo日志的lowSCN大于NextSCN

【处理过程】

由于mos也未给出明确的处理思路，此时mrp进程已经挂掉，尝试启动mrp进程，启动后发现出现新的错误

应用51437归档日志报错，报错信息与SCN有关，应该与上边的ORA-600 krrgv_scn8报错相关，开始怀疑是归档日志传输存在问题，问题时间点恰好有网络波动，从主库重新拷贝51437日志，启动mrp进程，又出现新的报错。

新的报错提示ORA-00600: internal error code, arguments: [krrfro_cachedscn], [1], [433700860], [1], [462238206], [1], [462384214], [], [], [], [], []，mos并未查到相关信息，通过krrfro_cachedscn判断是否Oracle缓存了错误的SCN，导致应用失败，尝试重启备库，并启动MRP进程，发现可以正常应用51437日志，但很快出现新问题。

提示当前STANDBY REDOLOGFILE 存在坏块，想起早上同事说过有个备库mrp进程挂掉，重新启动后恢复正常，沟通后发现是同一个备库的同一个问题，这种问题还比较好处理，将有坏块的SRL删掉重建就行。

重建后启用mrp进程，日志应用恢复正常。

【总结】

1、问题根本原因应该是SRL存在坏块导致遇到后来的bug，经检查发现，当时同事重新启动MRP进程后也并未正常应用日志，但是MRP进程未中断。

2、后来因krrgv_scn8 bug导致mrp中断，根据其他报错信息逐步恢复。

3、若未解决报错信息，可以尝试增量恢复DG恢复应用状态。

4、监控真的很重要，我们自己写的DG监控脚本，结合ZABBIX，已经帮助我们节省了很多力气