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

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

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

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

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

圖片

Load Profile是大家必須關(guān)注的重要數(shù)據(jù)，很多經(jīng)驗(yàn)不足的DBA往往會(huì)跳過(guò)這個(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ù)庫(kù)的是一般系統(tǒng)，可能會(huì)出問(wèn)題。不過(guò)考慮到這套數(shù)據(jù)庫(kù)是跑在EXADATA X9上的，這種強(qiáng)度的負(fù)載也應(yīng)該不是大問(wèn)題了。從后面的TOP EVENTS和前臺(tái)后臺(tái)進(jìn)程的EVENTS上，我們可以看到IO延時(shí)是很正常的。

圖片

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

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

圖片

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

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

圖片

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

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

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