點擊上方“IT那活兒”，關注后了解更多精彩內容！！！

問題描述

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

首先排查操作系統根文件系統使用率，確認當前根文件系統可用總容量不足1T，數據庫表空間合計占用超過900G。因此，排出掉操作系統本身占用及db2軟件（實例為循環日志模式，事務日志以及診斷日志合計不足12G），若要解決問題，只能表空間容器上下手。

解決方案

思路1：

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

實際情況為，當前系統搭建的較早，當初直接將sda的某個分區給了根，無法實現擴容。

思路2：

db2數據庫的DMS表空間容器（類似于Oracle數據庫表空間的datafile）可以實現縮容，語法：

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

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

思路3：

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

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

思路4：

經過多方驗證之后，既然無法在數據庫側解決掉此問題，那么便選擇欺騙數據庫，通過軟連接的方式解決，即關閉數據庫將表空間DMS_IDX的容器mv到新的文件系統，掉釋放空間，然后創建軟連接到原來的位置，此方案有以下優勢：

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

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

執行：

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

（截圖為測試環境問題復現）

關閉數據庫，mv容器，并且創建軟連接。

db2stop force

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

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

db2start

重新啟動數據庫，檢查表空間狀態一切正常，走索引查詢部分表數據測試正常。

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

檢查文件系統使用率已釋放。

Perfect！完成！

END

更多精彩干貨分享

點擊下方名片關注

IT那活兒