Oracle RAC宕機和hang分析處理流程

目的：分享一下公司的db故障處理流程，主要是思想。

事件描述及影響：

2023年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資料庫的切換應急演練