上周一個(gè)客戶的系統(tǒng)出故障，一些微服務(wù)在連接數(shù)據(jù)時(shí)報(bào)了一個(gè)未知錯(cuò)誤，因此大家都懷疑數(shù)據(jù)庫的問題導(dǎo)致了本次故障，為了配合問題分析，我們也安排了一個(gè)DBA前往用戶現(xiàn)場做綜合排查。我們的同事到現(xiàn)場的時(shí)候，分析故障的小組也已經(jīng)把數(shù)據(jù)庫的嫌疑排名從第一名往后移而把網(wǎng)絡(luò)放在重點(diǎn)排查的首位。

實(shí)際上在一個(gè)復(fù)雜的系統(tǒng)故障中，數(shù)據(jù)庫想要自證清白有時(shí)候比發(fā)現(xiàn)數(shù)據(jù)庫的故障更加困難。因?yàn)榇蠖鄶?shù)數(shù)據(jù)庫故障都有較為明顯的現(xiàn)象，阻塞、卡頓、性能下降、服務(wù)中斷等都可以從數(shù)據(jù)庫自身的指標(biāo)中發(fā)現(xiàn)問題，尤其是你在分析Oracle數(shù)據(jù)庫的時(shí)候。而大多數(shù)數(shù)據(jù)庫系統(tǒng)平時(shí)都處于亞健康狀態(tài)，雖然沒有大問題，沒有引發(fā)故障，但是某些指標(biāo)或者對(duì)外表現(xiàn)中還是能夠發(fā)現(xiàn)大量不正常的因素的。只有有經(jīng)驗(yàn)的DBA才能逐一將這些現(xiàn)象與故障現(xiàn)象排除。

上周的故障發(fā)生后，問題分析小組的朋友們就發(fā)現(xiàn)了各種監(jiān)控手段的缺失，雖然說云平臺(tái)、應(yīng)用系統(tǒng)都號(hào)稱提供了強(qiáng)大的監(jiān)控工具，但是這些監(jiān)控?cái)?shù)據(jù)在真正問題發(fā)生的時(shí)候顯得十分不夠用。幸虧Oracle數(shù)據(jù)庫有豐富的可觀測性體系，能夠保存大量的歷史運(yùn)行數(shù)據(jù)。今天通過這個(gè)案例我給大家介紹一下當(dāng)一個(gè)復(fù)雜故障發(fā)生時(shí)，Oracle如何甩鍋。

首先看ALERT LOG，在故障時(shí)段前后30分鐘甚至更長時(shí)間范圍內(nèi)對(duì)ALERT LOG中的故障告警做認(rèn)真分析，如果能夠手工寫個(gè)工具，將這段時(shí)間內(nèi)發(fā)生的重要事件記錄下來就最好了。實(shí)際上也很簡單，只要把ORA告警與日志切換等重要事件的時(shí)間點(diǎn)與告警信息采集下來，按照時(shí)間順序輸出就可以了（日志切換只需要一個(gè)時(shí)間）。通過排查ALERT LOG，我們發(fā)現(xiàn)這個(gè)2節(jié)點(diǎn)RAC的ALERT LOG正常到了不能再正常了，日志切換也是正常的，平時(shí)大概5-10分一次，而故障期間內(nèi)照樣有日志切換發(fā)生，只是頻率低了一些。說明數(shù)據(jù)庫的總體是正常的，日志切換頻率降低也有可能是應(yīng)用出現(xiàn)故障導(dǎo)致的。

第二個(gè)我們需要去分析的就是AWR報(bào)告 ，通過AWR報(bào)告我們可以對(duì)數(shù)據(jù)庫的宏觀運(yùn)行狀態(tài)做一個(gè)初步的判斷。在這個(gè)分析中，還是需要一定的技巧和經(jīng)驗(yàn)的。    

圖片

Load Profile是大家必須關(guān)注的重要數(shù)據(jù)，很多經(jīng)驗(yàn)不足的DBA往往會(huì)跳過這個(gè)數(shù)據(jù)，直接去看TOP EVENTS，實(shí)際上先看看負(fù)載是否正常更為重要?？梢钥闯霎?dāng)時(shí)系統(tǒng)中的IO負(fù)載很高（RAC兩個(gè)節(jié)點(diǎn)加在一起有8GB/秒），系統(tǒng)負(fù)載也不小。如果跑數(shù)據(jù)庫的是一般系統(tǒng)，可能會(huì)出問題。不過考慮到這套數(shù)據(jù)庫是跑在EXADATA X9上的，這種強(qiáng)度的負(fù)載也應(yīng)該不是大問題了。從后面的TOP EVENTS和前臺(tái)后臺(tái)進(jìn)程的EVENTS上，我們可以看到IO延時(shí)是很正常的。

圖片

一些DBA看到這個(gè)等待事件的時(shí)候會(huì)覺得系統(tǒng)還真的有些問題，實(shí)際上有經(jīng)驗(yàn)的DBA從Top 10 foreground Events中看到的滿滿的都是正常。首先AVG WAIT讀不高，其次是沒有哪個(gè)等待事件能看出來系統(tǒng)存在HANG住或者登錄失敗引起的問題。    

看到上面我就基本上不認(rèn)為這次故障的原因是數(shù)據(jù)庫了。不過為了更加安全起見，我們還是去看看ASH，ASH是能夠從微觀角度發(fā)現(xiàn)數(shù)據(jù)庫問題的重要數(shù)據(jù)，一般用于發(fā)現(xiàn)通過AWR很難發(fā)現(xiàn)的短時(shí)間問題導(dǎo)致的系統(tǒng)卡頓與故障。    

圖片

Activity Over Time是快速發(fā)現(xiàn)系統(tǒng)存在問題的重要數(shù)據(jù)，要驗(yàn)證這個(gè)數(shù)據(jù)庫有沒有和系統(tǒng)故障相關(guān)的大問題，基本上看一眼這部分?jǐn)?shù)據(jù)就可以了?？梢钥闯錾厦娴臄?shù)據(jù)也是沒有問題的。

看到這里，你可以比較自信地去和平臺(tái)組的其他同事互懟了，其他專業(yè)的人可能很難找到對(duì)你十分不利的直接證據(jù)了。不過對(duì)于應(yīng)用無法正常連接數(shù)據(jù)庫的問題，最好再看一眼listener日志。    

圖片

不出所料，監(jiān)聽日志也很干凈，幾乎沒有任何報(bào)錯(cuò)。從上面的三方面的信息可以看出，數(shù)據(jù)庫應(yīng)該是無辜的。而且從監(jiān)聽日志可以看出，起碼應(yīng)用連接數(shù)據(jù)庫的這段網(wǎng)絡(luò)應(yīng)該也是十分正常的，否則監(jiān)聽日志里會(huì)有大量的網(wǎng)絡(luò)超時(shí)或者斷聯(lián)的告警信息。

對(duì)于Oracle這樣具有十分完善的可觀測性體系的數(shù)據(jù)庫來說，只要有經(jīng)驗(yàn)豐富的DBA參與，想要排除數(shù)據(jù)庫的問題還是不算太難的。不過對(duì)于國產(chǎn)數(shù)據(jù)庫來說就困難一些了，因?yàn)槲医裉旖榻B分享Oracle的方法用到國產(chǎn)數(shù)據(jù)庫上的時(shí)候，就會(huì)因?yàn)槿狈?zhǔn)確的數(shù)據(jù)而無法完成了，這也是國產(chǎn)數(shù)據(jù)庫應(yīng)該抓緊完善的地方。

發(fā)現(xiàn)數(shù)據(jù)庫系統(tǒng)沒有問題確實(shí)比發(fā)現(xiàn)數(shù)據(jù)庫存在問題要困難一些，因?yàn)樾枰治稣呔哂惺裁磾?shù)據(jù)是正常的，什么數(shù)據(jù)是不正常的，什么樣的故障在會(huì)反映到哪些指標(biāo)上去，這樣的一些分析經(jīng)驗(yàn)，這些經(jīng)驗(yàn)需要在不斷的運(yùn)維工作中不斷積累。而擁有這些經(jīng)驗(yàn)的人往往不會(huì)去寫書來介紹這些經(jīng)驗(yàn)，因此需要我們通過更廣泛的學(xué)習(xí)來完成積累工作。