[[187323]]

[[187324]]

案例分享

誤刪除數據表

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

誤刪除用戶

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