昨日Oracle災難現場的經歷薦

    昨天剛發了要重新出發的帖子，沒想到這麼快就上了前線。
    本來希望早點回家的，不曾想突然接到一個北京本地金融客戶的通知，Oracle RAC當機，交易系統中斷，迅速到現場救急。嗨馬上出發吧……為啥去？還不是因為這個客戶部署了我們的Oracle 容災軟體，隨時要進行切換。於是，懷揣忐忑不安的心情，我和同事上路了。
    現場氣氛是緊張的，CIO是焦急的，DBA是無奈的，外援人員是茫然的，辦公室傳出大聲爭論的聲音，情緒有點失控……Oracle RAC的listener不能啟動，原因不明，業務不能做。不時的有公司領導過來詢問下午3點之前能不能搞定，“一定儘快解決，即使3點不行，也不能耽誤晚上的業務。”CIO嘴上自信，心裡卻彷徨的很，不能在浪費時間找原因了，儘快讓業務恢復是第一要務。於是轉頭對我們說：“程工，先看看Oracle複製軟體執行有沒有問題，如果資料沒問題，我就先把業務切換到深圳災備中心的資料庫上做，這邊的RAC大不了重做了，我們還有個測試系主機可以應急。”聽了這話，我們哪敢大意，馬上在鍵盤上噼裡啪啦一番，還好，雖然listener問題造成業務中斷，可是Oracle復軟體執行正常。“複製軟體顯示最後一筆交易有記錄，14：23分。” CIO終於放心了–災備系統關鍵時刻起了作用–緊張的神情至少放鬆了一半。
    CIO理清了思路，環顧了手下的各位工程師，重新部署工作：1、業務系統連結到深圳資料庫做交易；2、馬上在metalink上填寫問題，向Oracle求助（服務費不能白花）；3、交易做完後，將深圳的資料exp出來，傳到北京測試系統，業務人員進行資料比對，看看容災端的資料有沒有問題；4、修復Oracle RAC，如果不行，明天用測試系統頂上。總之，一切的目標是保證明天的業務能執行……混亂的局面結束了，大家迅速行動起來，各司其職。
    事實證明，Oracle的應急服務是靠不住的，至少我這麼認為。火燒眉毛的時候，沒有人上門，沒有電話支援，DBA和CIO茫然的看著metalink的螢幕期待著遠在美國或者印度的某個工程師傳來的解決問題回帖。10分鐘過去了，終於來了一條系統自動回覆，讓我們等待，失望值+1；20分鐘過去了，看到一條不知誰寫的英文的對我們問題解釋。這真是發揮了全球的資源，哈哈。失望值+2；1個多小時過去了，終於有一個老外專家的留言，可是對解決問題沒有任何幫助。CIO選擇了放棄，他詳細的看了Oracle響應的時間，沒有關注任何其他內容，然後拿起電話不知道找誰抱怨去了。我不能完全想象他當時的心情，但這事兒給我留下了一個疑問，Oracle的服務憑什麼要那麼多錢？怎麼算的？這也許是人世間最不公平的一個數字遊戲。
    不過我還是要感謝oracle，尤其是RAC。看見過好幾次RAC崩潰，都是與其穩定性有關。呵呵，Oracle問題越多，我們的容災軟體就越受歡迎。大家都去用RAC吧……不好意思，心理有點陰暗啊！
    總之後來是一切順利，經過業務人員檢查，容災的資料沒問題，業務也順利的做完了。我們苦等了3個多小時沒有任何遺憾，因為換回了一個滿意的結果–CIO說通過這次問題，驗證了你們的Oracle容災軟體的實用性，可以馬上籤署驗收報告了。
    出來的時候看見了天上的月亮和二環路永不中斷的車流，肚子有點兒餓，很高興大家都得到一個完美的結果。我相信客戶的RAC很快就會修好，至於Oracle是不是會被拉來清算我不知道，不過我對自己的產品還是很滿意的。呵呵，可以去吹牛了。

 

                                                                                                     昨日Oracle災難現場的經歷