1. 程式人生 > >DBA生存警示:系統級誤刪除案例及防範建議

DBA生存警示:系統級誤刪除案例及防範建議

編輯手記:對於資深的老DBA們,他們在漫長的職業生涯中養成了很多稀奇古怪的守則,以在複雜多變的環境中“倖存”,這源於無數血淚的教訓,我曾經在《資料安全警示錄》一書收錄了大量現實案例,現在整理分享給大家,共為警示。

DBA

案例分享

誤刪除Oracle軟體

硬體維護人員刪除歸檔日誌的時候,把節點2的整個ORACLE_HOME都刪除了。在刪除的時候沒有注意到目錄改變了,還鍵盤做了一個向上的動作,剛好就是剛剛使用的 rm -rf *,然後一個下意識的動作回車就這麼按下去了。

空格導致的誤刪除

我最難忘的:root使用者在根目錄下rm -rf abc *,abc和*之間有個空格,結果把OS刪除了。已經成為佳話。什麼事情都可能發生的。從此,整個人好像變了一樣,做什麼事情,都三思而後行了。

空格導致的誤刪除

偶的教訓不是很深刻,不過意義很重大:

刪除一些 trace 檔案,然後就直接刪除rm orcl*, 結果通過VPN到生產的,網路太慢,命令剛剛慢慢的顯示出來,看都沒看直接按回車,結果執行的命令卻是rm orcl *,因為orcl和星號中間有個空格,所以把這個目錄下面所有的內容全部刪除了。出了一身冷汗,試想,如過是刪除資料檔案目錄下的內容,那立馬死翹翹了到現在為止,每次都要等命令完全顯示出來,從頭到尾看一遍再執行。不過大多數錯誤都是在很繁忙或者很疲勞的情況下發生的,呵呵,看來DBA應該多休息才是。

空格導致的誤授權

安裝資料庫的時候su – chmod 777 -R /oracle ,多輸入一個空格變成chmod 777 -R / oracle ,許多系統檔案屬性變壞,Unix癱瘓這個錯誤犯了兩次,用系統恢復磁帶重做系統,幸好是測試機。從此以後系統部門的同事不肯給root口令。

誤刪除資料檔案

當時,那幾天都是很疲勞的。在開發環境作資料檔案分佈調整時,先cp完某個表空間所有檔案到其他地方,然後作*匹配rm了此表空間在此目錄的資料檔案。但是rename時發現居然有一資料檔案沒cp過來,忘了說了,此表空間是system表空間。沒辦法,開發人員明天還要使用這個環境。幸虧之前有一備份,不過當時磁碟空間不是很充裕,足足折騰了一夜才搞定!想起來都後怕哦,幸虧不是正式環境了!再以後,就很少用cp,rm了,特別是rm *,一般是此類操作用mv來完成。需要rm的東西,一般mv到一臨時目錄了,再rm了!呵呵,可能都有點謹慎過頭了哦。

指令碼中誤刪除檔案

自己寫了個rman備份以及備份成功後rm舊log的shell指令碼,log的目錄賦值給變數,結果執行時目錄賦值沒成功,該變數指向了另一個目錄,結果下面的東東全沒了,系統立即報錯(把使用者的home目錄刪了)。幸好當時頭腦還很清醒,也沒誤刪什麼重要的資料,很快就搞定了。以後指令碼中要rm某個目錄的東東再也不敢用變量表示了,直接hardcode進去算了,這樣也放心。另外出問題後一定要冷靜,定位出問題原因後再動。

誤刪除目錄中掛載

一次生產環境linux系統,做整個專案目錄的移植,cp一份確認正常執行後直接rm原來的目錄,沒想到子目錄中居然有mount到其他server的XX目錄,結果可想而知…linux啊……

誤刪除資料檔案

剛進現在的公司不久時,做一個數據倉庫專案,同事週日加了一天班把資料抽到一個大表空間裡,大概 100G,第二天因為臨時表空間增長很快,決定重建,這個 臨時表空間的開頭和那個大表空間名字是一樣的,只是後面加了一個_temp,當時也是因為事情比較多,認為這是很簡單的,結果輸入名字就忘了輸入_temp,把大表空間刪除了,同事白加了一個星期天,雖然沒影響什麼進度(資料可以重抽),但這次教訓是深刻的。個人教訓:

1.rm的時候一定不要用*之類的,要用的話要看好再用,否則會有意想不到的效果。

2.人在累的時候最容易出錯誤,所以每一次回車都要看好。

上面僅僅是我們摘錄的一小部分誤刪除案例,但是這些案例帶來的影響有些是深遠的。如何在日常工作中避免這樣的低階錯誤發生?有一些簡單可操作的建議。

防範建議

1. 通過別名或重定義方式提示或禁用 rm 操作

或者制定一個規範,通過mv的方式進行檔案轉移,通過一定時間段(如一週)觀察無誤後,再徹底清除資料檔案rm操作的危險性必須得到技術人員的充分重視。

2. 加強資料環境的空間監控

很多使用者是在空間達到100%之後才去匆忙進行空間清理,匆忙常常會帶來考慮不周,誤操作等意外發生。所以我們建議加強資料環境的儲存空間監控,不要等到100%再去應急,應當總是使空間留有閾量,提前 進行空間維護,避免手忙腳亂的應急處理。

3. 在緊急刪除之前做好備份 

如果不可避免的要進行緊急的檔案刪除工作,那麼在條件允許的情況下,應當做好備份轉移到其他主機或儲存,避免無法回退恢復的災難。通常檔案的轉移並不會花費太多的時間,在可能情況下用轉移替代刪除,在必須刪除時,也要考慮能否保留最後一個備份。

4. 避免在持續工作或者凌晨倉促的進行檔案刪除等工作

人在疲勞和不清醒的狀態下極易犯下錯誤,所以應當儘量避免在連續工作的疲憊狀態下,或者在夢中驚醒的凌晨迷糊狀態下進行維護工作,比如檔案刪除,在這種狀態下,極易出現誤判,造成誤操作。另外,在操作之前確認你的當前路徑,很多災難是由於當前路徑錯誤導致的,在 Unix/Linux下,可以通過pwd命令來確認。

5. 重要的操作實現人員備份

前面提到過這點建議,再次重申,在執行重要操作時,最好有兩個人同時在場,互相監督稽核,避免一個人草率或者考慮不周導致的誤操作。

以上內容摘錄自蓋國強《Oracle DBA手記4 資料安全警示錄》。