八月二十六日晚上接到使用者反饋，一套Oracle11.2.0.4 rac for redhat6.9 資料庫業務連線異常，工程師第一時間介入，於當晚緊急處理，恢復資料庫正常執行。隨後對資料庫相關日誌進行分析，定位此次發生故障原因，並提出相關建議。

從資料庫的日誌來看：

晚上02:00:00  資料庫開始自動統計資訊收集任務，收集統計資訊。

晚上03:22:07  資料庫報錯：minact-scn: useg scan erroring out with error e:12751 。這個報錯意思是：當資料庫中存在長和大的事務時，MMON 開始強烈（aggressively ）掃描undo 表空間，導致資料庫錯誤並不能生成AWR 。MMON 程式與AWR 直接相關，這個程式負責為AWR （Automatic Workload Repository ）收集資料。當存在大量後臺任務等待服務的佇列或伺服器資源耗盡的情況時，MMON 可能會暫停操作。

上圖顯示awr  報告缺失的三個時間段。後續五點的awr  也無法生成。說明此段時間資料庫十分繁忙，由於缺少相關快照，無法檢視資料庫相關狀態，所以此段時間內資料庫發生了什麼無法排查。但是資料庫在如此繁忙的情況下影響正常連線，也是合理的。

 

應用發現資料庫無法連線後，05:52:35 對資料庫進行關機並重啟。隨後大約在06:11:51 左右機器重啟，從資料庫叢集日誌來看，由於gpnp  程式異常，直到07:07 左右資料庫才完全啟動。

而這段時間資料庫二節點的情況是這樣的：

在一節點的停機後約3 秒，二節點開始資源重組，隨後接管業務。但是由於二節點的部分光纖鏈路異常，二節點無法滿足接管業務的需求。

從作業系統日誌可以看出，在當天凌晨，系統就報了io  錯誤。

在接管業務沒多久，資料庫asm 磁碟組就異常了。導致表面上看資料庫是open  狀態，實際資料庫不可用。

直到工程師處理故障的時候，拉起二節點資料庫，asm  例項還在報磁碟心跳超時。在溝通中，現場人員拔掉了一根光纖。隨後資料庫恢復正常連線。在今天的測試中，也發現，當插入那根光纖後系統日誌會報io 錯誤。

至於為啥，資料庫在停機過程中多次出現無法關閉或者無法拉起的情況，根據相關資料庫日誌來看：

1.      ORA-01089: immediate shutdown in progress - no operations are permitted

關庫的時候，資料庫還有連線未釋放

2.      kkjcre1p: unable to spawn jobq slave process, slot 0, error 1089

命中Oracle  bug23102157

3.      ORA-00600: internal error code, arguments: [4194], [], [], [], [], [], [], [], [], [], [], []

暴力關機導致undo  損壞

從本次故障的事後日誌分析來看，是由多重因素導致整個叢集故障。但是資料庫沒有有效的監控系統，在故障發生前無法獲取有效的資料庫狀態和業務當時連線資料庫的異常報錯，導致資料庫連線異常問題無法得到有效分析，在分析故障中我們發現資料庫未打補丁，且部分引數需要分析後在進行最佳化。

最終確認是HBA卡的問題。

1.       建議對相關光纖鏈路進行故障分析，確儲存儲鏈路無異常。

2.       建議資料庫進行補丁升級，目前資料庫版本較舊，較容易觸發BUG 。

3.       建議對資料庫進行一次深度巡檢，並對部分引數進行引數最佳化。

4.       建議對資料庫部署有效的監控系統，做到隱患問題事前通知，故障事中處理，事後溯源。

5.       建設有效可靠的資料庫容災系統，實時監測資料同步狀態。利用容災管理軟體定期進行容災切換演練工作。在生產系統出現故障時，可以第一時間切換到容災系統接管業務，將損失降到最低。

做好所有資料的定期備份工作，制定詳細的備份計劃。也可以藉助第三方集中備份軟體進行資料統一管理。