DBA生存指南：以嚴謹防範事故

每逢假期，我們總會接收到很多數據庫故障救急請求，因此我甚至經常發出以前的一個總結：警惕數據庫假期綜合症，唿籲大家提高警惕，防範疏忽下發生的故障和問題。

在這個元旦假期中，我們同樣收到了很多的緊急援助請求，這其中大多是熟悉的問題，包括：

1. 數據庫回滾段問題導致的ORA-01555錯誤；

2. SYSTEM表空間壞塊導致的BootStrap失敗，2662錯誤；

3. 誤刪除導致的數據丟失；

4. 空間不足導致的歸檔掛起；

陽光之下，並無新事，這些問題大都是我們以前曾經麵對過的，很多專家已經寫過了很多案例，如果大家對類似的問題感興趣，我甚至總結了一個頁麵，供大家參考：

https://www.eygle.com/blog/special/oracle_recovery.html

然而我想重複的，DBA至關重要的一項素質是：嚴謹。在麵對重要操作時的小心謹慎，反複確認；在可能損壞數據操作時心懷警惕，確認無誤；唯有充分重視這份數據工作，才能在實踐中履險如夷，達成使命。

比如誤刪除操作這樣的事故，直至今天，在很多用戶環境中仍然屢見不鮮。

上周在微信大講堂中還有人提問：是否可以用update user$的方式更改Oracle數據中的用戶名？

以上提及的問題，一步走錯，就可能為生產數據庫帶來災難，企業一方麵我們可以通過加強規範來防範錯誤，一方麵可以通過技術手段去防止問題（比如在一定程度上禁用DDL），而DBA們在進行一個操作之前，一定要足夠嚴謹，把握住最關鍵的執行一環。

在2016年，我們祝願所有的DBA們能夠更加嚴謹順利，更上一層樓。

這次用戶誤刪除的案例，讓我想起多年以前論壇上的一則誤刪除案例，與大家分享共為警醒：

最慘的一次（經曆）是和公司的一個哥們一起出差,那個哥們不知道出於什麼考慮,將主服務器和備份服務器的IP反了一下,但是tnsnames沒做修改,我準備重做備服的時候,使用了drop user cascade,把所有的用戶都幹了一遍。

剛剛幹完,所有科室上夜班的護士小妹妹都給我打電話,說科室裏的電腦全部不能用了,當時急的不行了,還好習慣還不錯,來的前一天做了一個全庫冷備，立刻進行了恢複,不過也丟失了一整天的數據。

一個小時以後，所有的院領導以及信息科的工作人員都出現在我的麵前，並質問我原因,我隻能一臉無奈的告訴他們剛剛來了隻熊貓，那隻熊貓燒了把香,然後數據就全丟了。

然後給了他們一個賣瑞星的兄弟的電話,那個兄弟連夜驅車200公裏趕到目的地,到場以後首先確實了一下那個燒香的熊貓的存在,然後指出了那隻熊貓的巨大危害性，最後建議他們購買一套全院級的殺毒軟件。

大院長聽取匯報後當即指示，立刻購買一套全院級的殺毒軟件，第二天一早就在購買合同上簽字蓋章。

這個事情造成四個後果,

第一,我在所有刪除性操作以前都要核實一下對象的準確性,

第二,我從此拒絕和那個哥們一起出差，

第三,那個賣殺毒軟件的兄弟會經常聯係我，看看我有沒有犯類似的錯誤。

第四,兄弟越多越好

富有戲劇性效果的案例，說出一個心酸的真實故事，但願我們都不要通過跌倒去收獲經驗，而是通過嚴謹去防止錯誤吧。

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