性能問題導(dǎo)致的數(shù)據(jù)庫嚴(yán)重故障案例之一

好久不來這里寫東西，今天有點時間，來這里寫點最近遇到的事情。前段時間，某電信業(yè)務(wù)用戶因某核心生產(chǎn)庫最近多次宕機重啟，多方人員介入無果后，給我發(fā)來了郵件，大概意思就是現(xiàn)在該問題已經(jīng)造成了比較嚴(yán)重的后果，希望能幫助介入分析、診斷并解決該問題。

好久不來這里寫東西，今天有點時間，來這里寫點最近遇到的事情。前段時間，某電信業(yè)務(wù)用戶因某核心生產(chǎn)庫最近多次宕機重啟，多方人員介入無果后，給我發(fā)來了郵件，大概意思就是現(xiàn)在該問題已經(jīng)造成了比較嚴(yán)重的后果，希望能幫助介入分析、診斷并解決該問題。通過之前介入該問題的人員了解到，到目前為止，已經(jīng)是第三次宕機重啟了，時間區(qū)間大概為2個多月的樣子。第一次重啟后，因為運維人員并未獲取到當(dāng)時有價值的信息，因此，并沒有一個結(jié)論；第二次其他數(shù)據(jù)庫相關(guān)人員定位到可能是該版本（11.2.0.4,3）的某個bug引起的，并給出了解決方案，他們之所以這么解決，是因為在數(shù)據(jù)庫的alert.log中發(fā)現(xiàn)了該bug的信息，因此，都堅信這就是該問題的根源所在，實施該方案后，大家心里就踏實了?？闪畲蠹覜]想到的是，過了不久，同樣的故障依舊重現(xiàn)了，至此，給我發(fā)來了郵件。通過和相關(guān)人員的溝通，并獲得了問題發(fā)生時僅有的信息（獲取的信息并不全），只是聽到他們說，該問題發(fā)生時很奇怪，系統(tǒng)突然hang住的樣子，而且期間，無論是DB還是OS層面的操作，都沒什么反應(yīng)，他們也有的懷疑OS或DB層面的異常，甚至懷疑到了硬件的問題。。，當(dāng)然，他們的懷疑也不無道理。通過運維人員提供的DB日志，發(fā)現(xiàn)了一個奇怪的問題，該數(shù)據(jù)庫在問題發(fā)生期間，并不是因為故障導(dǎo)致的自動宕機，而極可能是人為關(guān)閉了數(shù)據(jù)庫，這有點出人意料，其他相關(guān)人員也極力否認(rèn)，這是預(yù)料中的，沒人愿意承認(rèn)這種事情，況且，其中一次在23點左右發(fā)生的，他們用這個時間來反駁我：這個時間點，誰還會操作數(shù)據(jù)庫？想想也是，這畢竟只是一個線索而已，如下就是當(dāng)時的日志信息:

會不會CLUSTER因為某些因素主動重啟了數(shù)據(jù)庫呢？因為運維人員幾乎沒提供什么信息，于是，又讓他們采了OS層面的信息，進一步證實了我的猜測：

那么，什么因素導(dǎo)致了cluster主動重啟了數(shù)據(jù)庫呢？繼續(xù)看看運維提供的awr報告，定位到了異常過程和相應(yīng)sql如下：<喎?http://www.2cto.com/kf/ware/vc/" target="_blank" class="keylink">vcD4KCjxwPjxpbWcgc3JjPQ=="http://www.2cto.com/uploadfile/Collfiles/20141015/201410150912294.jpg" alt="">

反饋用戶后，用戶側(cè)人員很快定位到問題所在，處理后，至今近半年，故障沒再發(fā)生，一切正常。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com