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

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

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

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

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

圖片

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

圖片

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

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

圖片

Activity Over Time是快速發現系統存在問題的重要數據，要驗證這個數據庫有沒有和系統故障相關的大問題，基本上看一眼這部分數據就可以了?？梢钥闯錾厦娴臄祿彩菦]有問題的。

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

圖片

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

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

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