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

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

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

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

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

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