點擊上方“IT那活兒”，關(guān)注后了解更多精彩內(nèi)容！?。?/span>

問題描述

某日接到某銀行的故障請求，Linux系統(tǒng)根目錄使用率100%，而當前服務(wù)器上只運行了一個db2數(shù)據(jù)庫，因此希望我們遠程幫助釋放一部分空間（至少釋放到不會觸發(fā)告警的使用率），并且為當前服務(wù)器已經(jīng)新申請了磁盤（存儲）。

首先排查操作系統(tǒng)根文件系統(tǒng)使用率，確認當前根文件系統(tǒng)可用總?cè)萘坎蛔?T，數(shù)據(jù)庫表空間合計占用超過900G。因此，排出掉操作系統(tǒng)本身占用及db2軟件（實例為循環(huán)日志模式，事務(wù)日志以及診斷日志合計不足12G），若要解決問題，只能表空間容器上下手。

解決方案

思路1：

首先排查根文件系統(tǒng)是否為卷組。若為邏輯卷組，只需要將新申請的磁盤做成pv分配給VG，然后在線擴容lv即可。

實際情況為，當前系統(tǒng)搭建的較早，當初直接將sda的某個分區(qū)給了根，無法實現(xiàn)擴容。

思路2：

db2數(shù)據(jù)庫的DMS表空間容器（類似于Oracle數(shù)據(jù)庫表空間的datafile）可以實現(xiàn)縮容，語法：

db2 “alter tablespace tablespace_name resize (file file_name  size )”

經(jīng)過查詢表空間的使用率，用戶自定義的表空間有兩個，分別為DMS_DATA和DMS_IDX，使用率都較高，而且數(shù)據(jù)下發(fā)庫的表不允許清理，再考慮碎片的影響，因此容器縮容方案預估只能釋放極少數(shù)空間。

思路3：

基于db2數(shù)據(jù)庫表空間的容器無法像Oracle數(shù)據(jù)庫那樣實現(xiàn)數(shù)據(jù)文件移動（甚至是12C可以在線rename），按照IBM正規(guī)的解決表空間移動的方式為備份再恢復，需要先將數(shù)據(jù)庫全量備份，然后restore redirect generate script，通過手動修改恢復腳本，將表空間容器重新指定，然后執(zhí)行腳本恢復即可。

理論上可行，實際驗證時發(fā)現(xiàn)時間過長，允許的停機窗口遠遠不夠。經(jīng)過最簡單的cp測試，發(fā)現(xiàn)當前機器連接的存儲每秒讀寫速度低于70MB/s,而數(shù)據(jù)庫大小超過900G，且沒有開啟歸檔（循環(huán)日志模式），備份時只能選擇離線備份（離線備份期間數(shù)據(jù)庫無法連接使用），再包含恢復時間，總時長計算下來超過了7.5小時。

思路4：

經(jīng)過多方驗證之后，既然無法在數(shù)據(jù)庫側(cè)解決掉此問題，那么便選擇欺騙數(shù)據(jù)庫，通過軟連接的方式解決，即關(guān)閉數(shù)據(jù)庫將表空間DMS_IDX的容器mv到新的文件系統(tǒng)，掉釋放空間，然后創(chuàng)建軟連接到原來的位置，此方案有以下優(yōu)勢：

1、DMS_IDX表空間只有100G，按當前的磁盤速度只需要大約25分鐘左右，滿足停機時間窗。并且如果數(shù)據(jù)庫出現(xiàn)異常，可以通過mv回去的方式回退。

2、DMS_IDX為存放索引的表空間，萬一發(fā)生極端情況出現(xiàn)損壞，可以通過rebulid index的方式恢復，最起碼能保證數(shù)據(jù)不丟失。

執(zhí)行：

首先將新申請的磁盤創(chuàng)建為pv，組成新的vg，劃新的lv掛載成新的文件系統(tǒng)（做成vg的目的是若干年后可以直接在線擴容）。

（截圖為測試環(huán)境問題復現(xiàn)）

關(guān)閉數(shù)據(jù)庫，mv容器，并且創(chuàng)建軟連接。

db2stop force

mv /home/db2inst1/others/dms_idx01 /new_datafile/sample/

ln -s /new_datafile/sample/dms_idx01 /home/db2inst1/others/dms_idx01

db2start

重新啟動數(shù)據(jù)庫，檢查表空間狀態(tài)一切正常，走索引查詢部分表數(shù)據(jù)測試正常。

此處檢查容器位置，依然為mv之前的位置，對數(shù)據(jù)庫無感知。

檢查文件系統(tǒng)使用率已釋放。

Perfect！完成！

END

更多精彩干貨分享

點擊下方名片關(guān)注

IT那活兒