Oracle_RAC宕機(jī)和hang分析處理流程

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

創(chuàng)新互聯(lián)主要為客戶提供服務(wù)項(xiàng)目涵蓋了網(wǎng)頁視覺設(shè)計(jì)、VI標(biāo)志設(shè)計(jì)、營銷網(wǎng)站、網(wǎng)站程序開發(fā)、HTML5響應(yīng)式成都網(wǎng)站建設(shè)公司、移動(dòng)網(wǎng)站建設(shè)、微商城、網(wǎng)站托管及企業(yè)網(wǎng)站維護(hù)、WEB系統(tǒng)開發(fā)、域名注冊、國內(nèi)外服務(wù)器租用、視頻、平面設(shè)計(jì)、SEO優(yōu)化排名。設(shè)計(jì)、前端、后端三個(gè)建站步驟的完善服務(wù)體系。一人跟蹤測試的建站服務(wù)標(biāo)準(zhǔn)。已經(jīng)為成都茶藝設(shè)計(jì)行業(yè)客戶提供了網(wǎng)站營銷服務(wù)。

事件排查：
4:46，機(jī)房值班人員通知DBA及亦莊值班人員分析情況
4:57，按照公司流程在相關(guān)群通告故障
5:23，值班人員反應(yīng)數(shù)據(jù)庫服務(wù)器已自動(dòng)重啟，但一直卡在啟動(dòng)界面
5:30，DBA到達(dá)現(xiàn)場協(xié)助問題排查
5:39，DBA發(fā)現(xiàn)ogg進(jìn)程無法正常啟動(dòng)，原因是數(shù)據(jù)庫連接進(jìn)程達(dá)到上限(3000)，數(shù)據(jù)庫無法連接
6:03, 數(shù)據(jù)分析室人員參與分析ODS問題，確認(rèn)ods 1節(jié)點(diǎn)數(shù)據(jù)庫HANG住
6:56，機(jī)房值班人員嘗試手動(dòng)重啟odsdb2服務(wù)器，仍然卡在啟動(dòng)界面
7:40，嘗試通過封堵應(yīng)用連接數(shù)據(jù)庫的端口的方式，減少應(yīng)用連接數(shù)據(jù)庫的連接數(shù)
8:30，聯(lián)系HP廠商報(bào)障
9:20，kill odsdb1數(shù)據(jù)庫所有的外部連接（先保障主要業(yè)務(wù)）
9:30，對odsdb1數(shù)據(jù)庫做hang analyze，分析數(shù)據(jù)庫HANG住的原因
10:11，重啟oddsdb1數(shù)據(jù)庫實(shí)例
10:28，odsdb1恢復(fù)正常
10:30，ogg進(jìn)程恢復(fù)正常
10:40，放開過封堵應(yīng)用的端口

事件分析：
1、 odsdb2節(jié)點(diǎn)宕機(jī)重啟，且無法啟動(dòng)，一直卡在啟動(dòng)界面，懷疑由于數(shù)據(jù)庫硬件問題導(dǎo)致數(shù)據(jù)庫宕機(jī)重啟。通知服務(wù)器廠商進(jìn)行報(bào)障

2、 odsdb1數(shù)據(jù)庫HANG住無法正常提供服務(wù)，導(dǎo)致與ods數(shù)據(jù)庫相關(guān)的所有應(yīng)用及ogg受到影響
3、 odsdb1達(dá)到設(shè)置的最大連接進(jìn)程數(shù)(3000)，導(dǎo)致數(shù)據(jù)庫無法登錄，無法分析情況。

4、 分析哪個(gè)應(yīng)用服務(wù)器連接ods數(shù)據(jù)庫，封堵其連接數(shù)據(jù)庫的端口，減少數(shù)據(jù)庫的外部連接

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

通過hang analyze分析，數(shù)據(jù)庫是由于gc domain validation 及parallel recory coord wait for reply。
這兩個(gè)等待事件是數(shù)據(jù)庫節(jié)點(diǎn)2宕機(jī)后，節(jié)點(diǎn)1要接管節(jié)點(diǎn)2的服務(wù)，回滾節(jié)點(diǎn)2上未提交的數(shù)據(jù)，恢復(fù)節(jié)點(diǎn)2的數(shù)據(jù)時(shí)的等待事件。

從上圖的的信息可以知道，SMON進(jìn)程在進(jìn)行節(jié)點(diǎn)2的數(shù)據(jù)恢復(fù)，但是等待了289min41sec。且該進(jìn)行阻塞了1456個(gè)進(jìn)程sessions，由些可以知道節(jié)點(diǎn)1是在恢復(fù)節(jié)點(diǎn)2的數(shù)據(jù)時(shí)SMON進(jìn)程異常，導(dǎo)致數(shù)據(jù)庫1456個(gè)進(jìn)程被阻塞。
查詢Oracle官方網(wǎng)站MOS，發(fā)現(xiàn)與gc domain validation相關(guān)的一些BUG

6、 重啟數(shù)據(jù)庫，數(shù)據(jù)庫恢復(fù)正常，可以對外提供服務(wù)。進(jìn)而ODS相關(guān)的應(yīng)用也都恢復(fù)正常。

后續(xù)的優(yōu)化方案：
1、定期對數(shù)據(jù)庫進(jìn)行硬件檢查防止此類問題再次發(fā)生（節(jié)后與數(shù)據(jù)中心溝通，爭取每月做一次檢查）
2、后續(xù)增加對ODS數(shù)據(jù)庫的切換應(yīng)急演練

本文標(biāo)題：Oracle_RAC宕機(jī)和hang分析處理流程
鏈接URL：http://m.jiaotiyi.com/article/pgoegs.html