【背景】
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，已經幫助我們節省了很多力氣