每天忙的博客都沒時間更新，（近期會更新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）因爲和領導打了電話，領導肯定會問情況，還沒想好怎麼說。
3）工作交接，處理過程，以及建議等後續問題。
然後，我困了，要回家休息了，也許這只是一個意外吧！不知道大家遇到這種情況，該怎麼處理！因爲公司東西是機密，不可以透露，這裏僅僅分析我的個人經歷吧，個人情感，經驗博客，謝絕轉載！