630      阿裏雲  技術社區[雲棲]

DBA生存警示：防範頻發的數據誤刪除操作

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

在數據庫日常管理過程中，有些威脅來自數據庫外部，而有些威脅則來自數據庫內部，對於數據庫外部，破壞性的操作有rm，而在數據庫內部，同樣有破壞性操作，如Truncate。

誤刪除數據表

原來接手一個部門的所有數據庫，結果漏了一個，也沒人告訴我，所以我不知道這個數據庫存在。一天一個程序人員誤按了一個按鈕，把大量的數據全部刪除，找到我後，發現數據庫沒有歸檔，也沒有任何備份。結果是程序人員補了幾天的數據，我的獎金也直接泡湯。

誤刪除用戶

剛從事DBA不久，可已經犯了個讓我終生難忘的錯誤。原本是要將測試環境的一個user給刪掉，由於桌麵上開了多個窗口，結果drop user XXX cascade，直接將正式環境的一個user給drop了，剛按下enter，就感覺怪怪的，心想不會吧！！已經來不急了，還好這個user的信息是從另外一台服務器上同步過來的，要不然死定了。以後做什麼動作我都習慣先看看是在哪個DB上那個服務器上，千萬別搞錯了。

誤刪除表數據

以前公司，有一個程序員寫好的腳本，一個實施人員去執行，腳本裏麵帶了 delete * from xxx; commit; 啥備份，歸檔都沒有。結果我們公司全部人員出動，抱著筆記本，台式機，去北京某區縣所有的機關單位上門錄了一星期人員信息。至今記憶猶新。

誤刪除數據表

測試環境導出的腳本中包含drop語句，結果看都沒看就直接在生產環境中做了，一下子物料表就沒了，整個生產停線，後來做了恢複，丟了半天的數據。教訓：執行的腳本一定要認真檢查。

1.通過觸發器約束或禁用特定的DDL操作

對於TRUNCATE等高風險的數據庫DDL操作，可以考慮通過觸發器進行禁用，防止未授權的操作損害數據。 很多輕忽的數據災難都來自於Truncate，這個類似於係統級別的rm命令極具破壞性，而且DDL不可以回退，即便發現已經為時過晚。所以我們建議用戶可以考慮使用DDL觸發器來禁用Truncate之類的危險操作，以達到安全防範的目的。

2.以最小權限原則進行授權

過度授權即是為數據庫埋下安全隱患，在進行用戶授權時一定要遵循最小權限授予原則，避免因為過度授權而帶來的安全風險。

3.明確用戶職責

應當明確不同的數據庫用戶能夠用於的工作範圍，應當使用普通用戶身份的，就絕對不應該使用DBA的用戶身份，隻有職權相稱，才能夠避免錯誤。 即便是擁有管理員職責的用戶，也應當遵循以不同身份執行不同任務的習慣，比如SYS和SYSTEM用戶的使用就應當進行區分和界定。

4.在任何數據破壞之前進行備份

在進行數據表的截斷、刪除之前，進行備份，將備份養成一種習慣，這樣才能夠避免誤操作之後的措手不及。

5.以重命名代替刪除操作

不論操作係統級別還是數據庫級別的刪除操作，盡量以重命名替代刪除，如重命名數據表，重命名數據文件，然後通過一段時間的觀察和確認後再徹底刪除。 Oracle10g中引入的回收站功能，就是將我們執行的DROP操作變更為重命名進行保護，當我們發現了失誤之後，可以通過回收站找回，但是注意回收站保存對象的時間和空間有關，如果存儲空間不足，對象會被自動釋放。 我們在管理中借鑒這個回收站思想是很有幫助的。

6.盡量爭取充足的時間

不要低估任何一次簡單的維護操作，因為一個意外就可能大幅延長你的維護時間。所以，應當盡量爭取充足的時間，包括做好充足的準備工作，加快無關緊要步驟的執行，減少不必要的時間消耗，時間越充裕，你用來應對可能出現的故障的時間就越多。

7.審核你的剪貼板

很多錯誤是由於粘貼剪貼板的內容引起的，所以，當你準備向一個窗口或者命令行粘貼你看不到的內容時，提高你的警惕性。在Windows上，有很多剪貼板增強工具，可以幫助我們記錄和展現剪貼板的內容，可以考慮選用。 審核你的剪貼板，確保其中的內容是你期望的。

8.沒有認真看過的腳本就絕不要執行

對於DBA來說，如果一個腳本你從來沒有認真讀取了解過，就不要去執行，腳本中的一個錯誤就可能導致嚴重的數據災難。我們遇到過案例，由於腳本中的一個變量錯誤，導致所有數據文件被刪除，教訓慘痛。 如果實在無法審核腳本的內容，那麼在進行重要操作之前，備份你的數據。

以上內容摘錄自蓋國強《OracleDBA手記4數據安全警示錄》。

文章轉自數據和雲公眾號，原文鏈接

最後更新：2017-07-17 17:33:17

  上一篇：  自相矛盾：一個進程可以自成死鎖麼？

  下一篇：  DBA生存警示：主備環境誤操作案例及防範建議