reply 事件分析 宕機 等待 nal 故障 zab ali 手動

目的：分享一下公司的db故障處理流程，主要是思想。
事件描述及影響：
2018年9月30日04:43點，zabbix告警odsdb2數據庫疑似宕機，機房值班人員通過堡壘機無法登錄數據庫服務器，從其他機器也無法ssh登錄該機器，同時odsdb1數據庫也HANG住，通過命令無法登錄數據庫。根據數據庫業務流程圖初步分析影響的各業務。（涉及公司業務可忽略）

事件排查：
4:46，機房值班人員通知DBA及亦莊值班人員分析情況
4:57，按照公司流程在相關群通告故障
5:23，值班人員反應數據庫服務器已自動重啟，但一直卡在啟動界面
5:30，DBA到達現場協助問題排查
5:39，DBA發現ogg進程無法正常啟動，原因是數據庫連接進程達到上限(3000)，數據庫無法連接

6:03, 數據分析室人員參與分析ODS問題，確認ods 1節點數據庫HANG住
6:56，機房值班人員嘗試手動重啟odsdb2服務器，仍然卡在啟動界面
7:40，嘗試通過封堵應用連接數據庫的端口的方式，減少應用連接數據庫的連接數
8:30，聯系HP廠商報障
9:20，kill odsdb1數據庫所有的外部連接（先保障主要業務）
9:30，對odsdb1數據庫做hang analyze，分析數據庫HANG住的原因
10:11，重啟oddsdb1數據庫實例
10:28，odsdb1恢復正常
10:30，ogg進程恢復正常
10:40，放開過封堵應用的端口

事件分析：
1、 odsdb2節點宕機重啟，且無法啟動，一直卡在啟動界面，懷疑由於數據庫硬件問題導致數據庫宕機重啟。通知服務器廠商進行報障

2、 odsdb1數據庫HANG住無法正常提供服務，導致與ods數據庫相關的所有應用及ogg受到影響
3、 odsdb1達到設置的最大連接進程數(3000)，導致數據庫無法登錄，無法分析情況。

4、 分析哪個應用服務器連接ods數據庫，封堵其連接數據庫的端口，減少數據庫的外部連接

5、 數據庫無法登錄，需要kill odsdb1數據庫所有的外部連接後，可以登錄數據庫，但數據字典查詢緩慢，無法正常分析hang住的原因。且kill掉外部連接後，很快連接數又會漲到最大值。使用hang analyze做trace進行分析。

通過hang analyze分析，數據庫是由於gc domain validation 及parallel recory coord wait for reply。

這兩個等待事件是數據庫節點2宕機後，節點1要接管節點2的服務，回滾節點2上未提交的數據，恢復節點2的數據時的等待事件。

從上圖的的信息可以知道，SMON進程在進行節點2的數據恢復，但是等待了289min41sec。且該進行阻塞了1456個進程sessions，由些可以知道節點1是在恢復節點2的數據時SMON進程異常，導致數據庫1456個進程被阻塞。
查詢Oracle官方網站MOS，發現與gc domain validation相關的一些BUG

6、 重啟數據庫，數據庫恢復正常，可以對外提供服務。進而ODS相關的應用也都恢復正常。

後續的優化方案：
1、定期對數據庫進行硬件檢查防止此類問題再次發生（節後與數據中心溝通，爭取每月做一次檢查）
2、後續增加對ODS數據庫的切換應急演練

Oracle_RAC宕機和hang分析處理流程