記一次遠端協助的排錯案例

前幾天的時候幫助一個網友看了他遇到的一個問題，在問題處理中也讓我有不少的感悟。
最開始的時候這位網友的問題是一個10gR2的單例項資料庫，監聽無法正常關閉和啟動，他在嘗試了殺程式之後，重新啟動還是會一直卡在那裡。

看到這個地方，感覺是一個新環境，看來是網路哪裡出現了問題，要麼就是配置出現了問題。
在這種情況，配置情況很難一一去確認猜測，所以我就問他能否遠端協助，很快就連了過去。
當他開啟/etc/hosts檔案的時候，感覺裡面的配置資訊似乎有些過於簡單了，裡面只有localhost和127.0.0.1的配置，我準備朝這個方向來分析，是否配置出現了問題，檢查了網路配置，目前所看到的的配置都是取預設值，正在我分析的時候，他告訴我說，這個資料庫以前好好的，今天出了點問題，不知道怎麼的監聽就無法重啟了。而話外之意，為什麼要重啟還是有應用的同學反饋連線問題，這樣聽來也蠻有道理。
    所以聽到這裡，我就停下來手中正在進行的配置資訊檢查。而準備換一個思路來考慮這個問題。
在重啟的間隙裡，我讓他再開啟一個視窗，使用top檢視，發現CPU idle竟然是0，也就意味著現在的系統負載極高，CPU資源是已經被全部佔完了，看到這裡這位網友就有些不知所措了。我想了想，首先停止正在重啟的監聽工作，然後檢視目前系統的CPU瓶頸究竟在哪裡。從top結果來看，主要的CPU資源都是在資料庫的會話程式上，而且從程式資訊可以看出這些會話的持有時間已經超過20多個小時了，佔用率都不低。這種情況下初步感覺就是相關的SQL語句出現了問題，當然要連線資料庫檢查還是要徵得這位網友的同意，結果使用sqlplus登入竟然毫無反應，所以資料庫層面的檢查工作就很有限了。那我就從資料庫日誌中來嘗試得到一些有用的資訊，但是奇怪的是系統從昨天開始到現在竟然沒有任何的日誌輸出，這個就極為奇怪了，總得切一次歸檔吧，竟然一丁點日誌都沒有。所以這個資料庫不光是因為資源消耗高而完全阻塞了，從目前的情況來看是有僵死的感覺。
  但是凡事不能太肯定，所以我們還是先做保守的工作，我看了下資料庫目前有近80個使用者程式，資源消耗都很高，所以我的建議就是先釋放系統資源，即從作業系統層面來殺掉一些資源使用較高的會話，從實際來看，大量的會話持續20多個小時，肯定是有問題的。先保證業務可以恢復為先，所以在告訴網友要旨之後，讓他來從本地操作一下。清理了近30多個程式之後，檢視系統資源，CPU idle依然是0，從top來看資源使用依舊很高。所以逐步加大了殺掉程式的幅度，最後差不多了，檢視top發現idle還是很低，所以這個問題就讓人很糾結。
最後相關的會話都殺掉了，資料庫的負載依舊是CPU 100%，這就讓人無奈了，然後開啟第二套方案，既然殺掉會話依然無濟於事，我們開始嘗試停止資料庫，資料庫例項有5個後臺必備程式，但是我在嘗試kill了smon,pmon之後，檢視dbwr,lgwr,ckpt程式竟然依舊存在，而且資源佔用依舊很高。最後一一殺掉會話，我想這下總會可以了吧，沒想到這次確實有效果了，CPU資源一下子釋放了，我建議這位網友嘗試重啟資料庫，看看是否有大問題，但是我在遠端執行sqlplus -v竟然沒有任何反應，所以感覺問題又出現了。在這種情況下，sqlplus沒有響應，後面的工作是壓根沒法做了。感覺問題越來越縹緲，這個時候我的一個基本建議就只剩下了重啟系統，但是前提是先備份資料然後重啟，因為按照這種情況重啟如果失敗，那資料就全丟了，這個庫目前沒有開啟歸檔，所以丟資料的機率極高，在這一點上我還是很謹慎的。所以我是強烈建議先備份，然後重啟資料庫。
     碰到這種情況著實讓我有些擔心，而且這臺伺服器存在一些硬傷，硬體配置太老舊了，記憶體是4G，而且上面竟然還跑了幾個其他的業務，資料庫的版本過低，很有可能觸發一些bug之類的，對於這個問題還真是糾結，看來只能看看重啟大發是否生效了，當然為了表明我的態度，不要出現二義性，我還專門打了一個電話給他，想他確認了一些資訊。做完之後就等待他的進度反饋了，在我坐車回家之後，這位網友告訴我說，已經重啟系統了，重啟之後，資料庫就自動啟動了，監聽使用也沒有問題。而他也是帶著賭一賭的感覺，沒有做備份，當然這是大家都願意看到的境地，問題解決了，但是我還是建議他以後需要及時保留備份，在問題真正出現的時候，能夠少一些扯皮和推諉。
    後面又幫他看了幾個小問題，不過已經不重要了，因為主要的問題已經解決了。這個案例著實讓我很糾結，不斷調整著對於操作的最低要求，這個案例還是需要大家保持冷靜，要不資料丟失就不是簡單的技術問題了。