我身邊的一些資料庫事故

最近攜程的資料事故鬧得沸沸揚揚，不管是什麼原因，問題終究發生了。在問題發生的時候，更關鍵的是解決方法和防範措施，一般在升級或者重大的生產演練中，我們都有一個lesson learn,就是總結問題，總結經驗，防範規範。
除此之外，一線人員在各種重大活動中都發揮了重要的作用，我還是喜歡那句華為任正非的那句話：讓聽得見炮聲的人指揮。其餘我只能報以呵呵的態度了。

自己也抽空整理了一下自己經歷的資料相關的重大問題和事故，一總結還真嚇一跳。確認也有不少案例。很多都記錄在自己的技術部落格中了，想了解詳細的內容可以參考一下。
對於這些問題，有些是自己犯過的，有些是同事犯過的，但是都產生了一定的影響，說出來沒什麼丟人的，能夠坦誠布公的總結出來，就是希望自己身邊的經歷能夠讓這些看似簡單的問題不要再犯。

案例1：一條sql語句把資料庫弄宕  連結 http://blog.itpub.net/23718752/viewspace-1141131/
這個案例聽起來好像還真玄妙，是真實的案例。
就是在生產庫中執行了alter system set sga_target=xxxG; 這樣一個語句導致資料庫直接當機。當然問題的發生還是有一些前提條件的。最終發現和一個Oracle bug有關。
Bug 10173135 - Resize SGA_TARGET crashes instance with ORA-600 [kmgsb_resize_sga_target_1] (Doc ID 10173135.8)
看似簡單的一個操作就能導致嚴重的問題。生產中的操作真是慎之又慎，很多特性的使用也是需要斟酌和考究的。不要抱有僥倖心理，沒準就讓你碰上了。所以在生產中執行的語句，幾乎都會在其它環境中反覆測試才會部署。

案例2：kernel配置把資料庫弄hang  http://blog.itpub.net/23718752/viewspace-1417471/ 這個
這個問題其實也是客戶帶著僥倖心理，結果沒想到真出了問題，倒不是把資料庫弄宕。但是系統反應極為緩慢，swap的交換非常頻繁，最後發現是由於調整了sga等引數，但是hugepage的調整給漏掉了。
在啟動資料庫的時候其實也報出了hugepage的問題，但是沒有引起重視。
****************** Huge Pages Information ***************** 
Huge Pages memory pool detected (total: 30000 free: 27287) 
Huge Pages allocation failed (free: 29431 required: 32457) 
Allocation will continue with default/smaller page size 
********************************************************** 
所以問題放大之後，就產生了嚴重的影響。linux核心引數在很多時候會起到決定性的作用，所以影響不容小視。


案例3：使用圖形工具操作失誤 
圖形工具在生產系統中會極大的提高工作效率，但是有時候會產生一些誤導，比如測試環境中的一些配置資訊和生產中是完全不同的。但是透過圖形介面可能很簡單的點一下按鈕就會產生極為嚴重的資料事故，這個問題發生在很多補丁的部署在測試環境中都沒有問題，但是在生產環境中有一個配置略有不同，結果沒有引起重視，一個按鈕點下去，在後臺做了很多的驗證和連線操作，然後就開始了一些意料之外的大動作，比如re-create,比如drop操作。這個問題最後發現是由於配置的問題導致的，最後採用了基於時間點的恢復，很快得以解決。但是雖然之後知道配置問題解決了，但是使用起來還是會有很多顧慮，最後一致決定，採用控制指令碼來完成，在生產環境中完全棄用了這個工具。
所以生產中的操作是重之又重。不確定不明白的地方一定要確認好。存在的隱患一定要提前規避。

案例4:資料庫升級中的exp錯誤，險些導致回退  http://blog.itpub.net/23718752/viewspace-773852/
這個問題印象實在是太深了，和原廠的人折騰了很久，問題在類似生產環境中反覆演練了很多次，都沒有發現，但是在生產中還是碰到了。問題看似是一個小問題，在使用exp 使用consistent=y的時候出現問題，結果導致系統中某一個服務處理不了。

雖然最後得以解決，但是解決方案確實是有些牽強，就是purge recyclebin，即清空回收站。 mealink中的各種帖子都被翻遍了。各種bug和補丁都斟酌了，當時在場的那種壓力可想而知，在緊繃神經近10多個小時之後，終於解決。也算是化險為夷了。

案例4:pl/sql效能問題導致升級差點失敗  http://blog.itpub.net/23718752/viewspace-1172818/
這個問題發生的也是意料之外，但是影響也很大，其實就是在升級前，從開發那邊傳過來一個補丁，在測試環境中測試透過，但是在類生產系統中沒有測試，結果在部署的時候，pl/sql執行了好幾個小時，給業務升級帶來很大的影響，差點導致回退。
其實把pl/sql改為sql語句不到一分鐘就能夠搞定，但是因為這個臨時的問題導致大家都有些手忙腳亂。

.....
其實案例還有很多很多，就此就不一一贅述了。從上面的案例來看很多問題都是意料之外，都是一些細節因素導致的，產生的影響也很大，都需要引起注意。
最後來和大家說一個 我聽過最離譜的資料事故，話說某個運營商的機房運轉正常，但是突然有一天突然機房斷電，最後應該是用UPS給頂上了，很多細節略去幾百字，最後排查問題原因，發現是由於某個掃地大媽在拖地的時候不小心把某個插頭給碰掉了。你說碰到這種問題，真是哭笑不得的感覺。