一次核心線上磁盤差點爆滿坑人事件...

每天忙的部落格都沒時間更新，（近期會更新rac，ods等方面）此刻的我可以下班了（夜班一周一兩次吧），因為換了工作，對整體系統架構及業務都沒特别熟悉。本想現在回家休息，可是心情不怎麼美麗，剛剛經曆了一場核心磁盤差點爆滿事件，有點不痛快，吐槽一下，也算是分享一下自己的經驗吧！

情況是這樣的：

夜晚做一個核心跑批（涉及到幾萬使用者的賬戶資金扣款，不容出錯），在二次邏輯導庫（Oracle）的時候，突然接到資料中心的電話，兩台 主機1 主機2 應用伺服器下的/fns目錄96%了，說可不可以快點清理一下。（資料中心有集中式監控，但是操作大部分我們處理，何況是夜晚，技術支援不在）

于是盡快排查，因為應用服務不知道root，而且磁盤空間都很緊張，權限很嚴格。找到資料庫備份目錄後，判斷了一下dmp檔案大小，目前備份增長很快，一會兒%98了。還有8G空間，但是根據備份檔案比較，還有20G才備份完。此刻和時間賽跑...

不爽1：

1）%96了才告警，這不是坑人麼，門檻值怎麼設定的啊！

2）核心應用恰好在導庫，删錯東西，影響批扣，上司肯定不高興，甚至追責任。

目前發現僅僅/tmp下有可憐的空間，和資料中心打電話問有沒有之前備份，貌似不是和資料庫相關的人值班，給不了我确切答案，想和上司打電話确認可不可以臨時删除之前備份，電話不通。

不爽2：

1）為什麼磁盤空間那麼小，真的懷疑我在操作假的核心伺服器，短時間還擴容不了。（機房異地）

2）直屬上司聯系不通，雖然知道有上個月的歸檔，但是沒得到允許不敢删除啊。

于是告訴自己冷靜，冷靜。此刻隻剩下4G空間，如果影響批量，就麻煩了。緊急在/tmp下建立臨時目錄，将一些dmp.gz mv過去，剩餘空間在增長（gz檔案 2-3G，dmp檔案，40-50G），還好先緩解一下，但是我得至少騰出20G，才能解決問題。想想可不可以用tar 壓縮，然後加參數删除源檔案，剛執行壓縮到tmp下，立馬覺得不行，ctrl+c，同時立刻報警 /tmp 使用率 %100。因為檔案太大了。

不爽3：

1）腳本被修改，為什麼沒有接到通知，臨時壓縮有風險啊 哎。。。

2）腦子已經不敢确定xz gzip tar壓縮，壓縮過程會不會有臨時處理檔案，那樣死的更快。

兩台應用挂載同一個目标主機盤，gpfs檔案系統格式，還沒有确定用的什麼方式挂載。（nfs或者其它），但是我已經沒時間想這些了，空間又不夠了 %98了。先在/tmp下建立臨時目錄，緩解一下壓力。

評估了一下，兩個/tmp各分擔一下，恰好批量完成，剩下4G空間。

不爽4：

1）如果兩台tmp空間不夠的話，大家如果是我怎麼辦？（後期嘗試密碼碰運氣進入oracle使用者進去了）

此刻，批量完成，心裡松了口氣。看着可憐的4G空間，心裡不知道該說些什麼。然後我想了一下，gzip，xz壓縮是應該可以的（因為之前從來沒有遇到過磁盤空間不夠的情況，沒深入了解這兩個指令壓縮原理），壓縮之後，空間恢複。

不爽5：

1）腳本被修改沒通知，上司肯定會問。不确定是不是同僚，還是廠家 哎。。。萬一是前者，又涉及到    工作沒交接清楚問題，我也不好說。

2）因為和上司打了電話，上司肯定會問情況，還沒想好怎麼說。