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

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

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

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

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

圖片

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

圖片

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

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

圖片

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

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

圖片

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

對于Oracle這樣具有十分完善的可觀測性體系的數(shù)據(jù)庫來說，只要有經(jīng)驗豐富的DBA參與，想要排除數(shù)據(jù)庫的問題還是不算太難的。不過對于國產(chǎn)數(shù)據(jù)庫來說就困難一些了，因為我今天介紹分享Oracle的方法用到國產(chǎn)數(shù)據(jù)庫上的時候，就會因為缺乏準(zhǔn)確的數(shù)據(jù)而無法完成了，這也是國產(chǎn)數(shù)據(jù)庫應(yīng)該抓緊完善的地方。

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