資料庫負載急劇提高的應急處理

今天處理了一起緊急問題，回過頭來看還是有不少需要注意的地方。
首先是收到了報警，有一臺DB伺服器的負載有一些高，但是會快就恢復了。所以自己也沒有在意，但是過了大概40多分鐘，又接到一封報警郵件，而且隨著報警頻繁，感覺真是出了問題，在中控機器上使用ssh連線竟然都丟擲了異常。
# ssh 10.127.xxxx
Connection timed out during banner exchange
對於這類問題，是因為超出了預設的超時引數，不過我沒有糾結在超時的時長，因為這個本身已經不重要，既然中控超時連線，那麼伺服器端看來是出了點狀況。

可以看到SWAP很嚴重，已經到了岌岌可危的地步，遠遠超出了預設的閾值範圍60%，而記憶體空間也是所剩無幾，導致SWAP被過度使用。
到底有多慢呢，在iLO端切換使用者差不多得等30秒，結果使用sqlplus  / as sysdba登入竟然幾分鐘沒有響應，取消又是幾十秒，在這種龜速的情況下，服務端的響應情況可想而知。
好不容易執行了一個top命令，一看CPU使用率極高。
下面的圖形來自於Zabbix監控，可以看到問題發生的時間段裡，CPU使用率極高，而且紅色的部分是系統級使用率，佔用極高，iowait也很高。

當然情況緊急，在緊急情況下，是考驗基本功的時刻。儘管我可以看到有一些程式佔用CPU嚴重，但是我連線到資料庫出了點問題，我也知道需要繫結v$process和v$session就可以得到對應的SQL語句，但是思路是通的，實現起來就是個問題。這種情況該怎麼辦。
有的同學說切換備庫，或者停止資料庫我們來說一說。
首先是切換備庫，這無疑是一個不錯的方案，但是也有侷限性，切換本身需要簡單評估一番，如果前期準備充分，這個地方就不用花太多的時間，而關注的點就是是否需要替換IP，而問題就來了，原來的伺服器還沒有當機，IP資源還在，switchover是不可行了，還需要把這臺伺服器直接關掉，騰出網路資源再替換IP。這個過程還是存在一些隱患，備庫是否一定好用，現在面臨的問題在備庫是否會迎刃而解，如果是簡單的問題複製，那麼這個主備庫都被搞掛了，而且已經完全不一致了。這可就麻煩了。
而停止資料庫我們就需要考慮集中方式，首先是使用shutdown immediate，這種方式不太可行，在目前的情況下，我想這個操作得持續至少10分鐘，連線數有1000多個。這個資源的釋放本身還是需要不少的時間。如果使用shutdown abort肯定是命令方式最快的了，但是問題是我現在還沒有連線到資料庫端，這個操作還是會讓我很糾結。所以經過評估我們一方面準備備庫環境，一方面準備重啟主庫，因為考慮到SWAP極高，而我們早已經配置了大頁，所以只需要重啟資料庫例項即可生效。怎麼停呢，一種方式就是殺掉程式，我們知道資料庫的5大必備程式，SMON,PMON,CKPT,DBWR,LGWR這個5個任何一個出現問題，例項都會宕掉，所以我們就殺掉一個程式，讓系統資源極快釋放，而這個過程本身還是存在一些風險，我們準備了備庫，有備無患，所以在這種情況我開始了操作。
殺掉SMON程式發現部分的程式資訊還在，我又殺掉PMON，程式資源馬上得到了釋放。這也就充分證明了PMON才是真正的程式管理程式，系統資源釋放後，中控也能連線了，負載一下子降了下來，我們需要簡單驗證，重啟資料庫例項至nomount狀態，檢視大頁開啟了無誤，啟動例項，因為應用是自動連線，所以這個時候看問題就會簡單需要，因為我們沒有切換伺服器，不需要修改IP,不需要考慮其他的許可權影響。這種代價最低，而且恢復業務最快。看著資料庫日誌都在期望之中，所以這個問題後續關注，系統資源都趨於穩定。
當然問題的原因都需要經得起推敲，為什麼在指定的時間會突然多出幾百個程式（資料庫會話），為什麼SWAP的爭用問題會在哪個時候放大，變得嚴重，而從系統和資料庫層面而看待這個問題就是一個整體的眼光了，系統調優和問題分析都離不開這些必要條件，我們後續來揭曉。

而這個問題一下子讓我想起了當年客戶那邊碰到的一個重大問題，是由於大頁設定不當導致沒有生效在OLTP業務中直接卡住，看到這個問題一下子讓我想起了當年，所以儘快恢復業務是王道。