再分享兩個小問題變成大故障的案例

昨天寫了一篇關於NOTAM系統故障的反思文章，實際上也是一個客戶的領導給他們佈置的作業，我幫他們思考了一下，做了個小總結。我個人感覺NOTAM的問題不在於運維規程的規範性，我想FAA如此重要的系統，其運維規程肯定不會太亂。從故障發生在一次例行檢修說明系統雖然老舊但是維護還是規範的。

NOTAM故障的發生還是在於運維現場的技術管理方面出現了問題，計劃外處置沒有很好的管理，並且在故障處置過程中缺乏高水平專家的指導。在這些年的實際運維工作中，我也經常會遇到一些原本是小毛病，因為處置不當而造成大事故的案例。

這些年經歷過不少這樣的案例，大部分都與處置過程中不規範或者技術水平不足有關。哪怕有些企業運維管理十分嚴格，預案做的也比較完備，但是也很難在遇到運維故障時不犯錯誤。很多類似事情發生的原因是現場的運維人員在認知上的不足，或者考慮問題不夠全面。當故障發生時，為了儘快恢復業務系統執行，運維人員頂著巨大的壓力，很容易發生誤操作。有時候操作一提交，自己就已經發現自己錯了。我經常和我的同事說，遇到運維故障，凡是涉及到寫的操作，一定要經過研判，同行溝通後再做決定，如果有可能，要做好備份以便回退，不過這依然不能避免事故的發生。

十年前，一個客戶的的DSG複製死掉了，現場的運維人員重啟DSG無效束手無策了。諮詢了公司的遠端三線專家後也沒想到什麼好辦法，於是三線專家建議重啟資料庫伺服器。沒想到重啟伺服器之後不但DSG的問題沒有解決，資料庫也起不來了。實際上當時是AIX系統的一個共享VG出故障，有一塊盤找不到了，從而導致資料庫的200多個檔案找不到了。現場的DBA水平一般，無法將現場情況準確的反饋到三線，三線專家對AIX系統也不熟悉，因此當時就沒有正確定位故障。

當時RAC的另外一個節點還是正常的，業務沒有受到影響，按照企業的規程，處於業務高峰期是不能隨意操作的。於是等到6點下班後，現場DBA根據三線專家的建議把另外一個節點的資料庫重啟了，不過沒有沒有效果。於是重啟了另外一個節點的伺服器。經過一通折騰，終於兩個節點都出現了同樣的錯誤，整個資料庫都宕了。

如果此時停止折騰，把問題分析清楚再繼續處理，還是有辦法快速恢復的，因為主要修復了存在問題的PV的卷頭，卷組是能夠恢復的。不過三線專家也是個半吊子，為了拉起資料庫，居然建議現場DBA重建了控制檔案，把有問題的檔案全部去掉了，透過resetlogs強制開啟了資料庫。不過資料庫是開啟了，很多表一訪問就報錯，應用還是無法恢復。最終只能從備份資料中恢復資料庫。十多個TB的資料，整整恢復了三十多個小時。

還有一些系統故障是因為系統中早就埋下了隱患，有句話說“一次事故中至少有七個以上的錯誤”。下面介紹的業是一個十多年前的案例，客戶的一套資料庫系統因為儲存故障而出現SYSTEM表空間和資料表空間有大量的壞塊，無法啟動了，不過幸運的是這套是他們的次核心系統，搭建了DG。

我當時在遠端指導他們的現場恢復，本以為在DG的保護下，這個系統恢復是很容易的，只要從DG側複製檔案過來，再RECOVER一下就可以了，和他們討論完恢復方案後已經快一點了，於是我就睡覺了。沒想早上不到6點我就被電話叫醒了，原來他們的恢復工作失敗了。

現場DBA反饋說備庫無法正常只讀開啟，他們嘗試了多次也不成功，於是我讓他們先把備庫的ALERT LOG發過來。我看到DBA以MOUNT方式啟動資料庫例項，並且備份了控制檔案，不過隨後運維人員重建了控制檔案，這個操作和我說的第一個例子有點類似，重建控制檔案開啟資料庫是最容易被DBA錯誤使用的操作之一。重建完控制檔案後，進行了一次SWITCHOVER。

這次SWITCHOVER是註定要失敗的，因為這個資料庫還沒有完全恢復“END-OF-REDO"，這種災難情況下要運氣十分好才有可能能END-OF-REDO。於是只能開始做recover database。

在recover的時候遇到了一個問題，找不到一個歸檔日誌檔案。客戶覺得他們的歸檔日誌保留週期是一週，不可能缺歸檔日誌。此時DBA沒有仔細分析報錯資訊，而是繼續倔強的重建控制檔案,並且加上了resetlog選項。

其實每次重建控制檔案的時候都有警告訊息：

此時資料庫報錯是當前控制檔案與實際資料檔案不符，需要執行下面的命令才能使之達到一致，不過當時運維人員並未深究其原因。而是直接把這些命令複製了下來執行了!如果說之前的錯誤還都不致命，一旦做了這個操作，那就是致命的了。不幸的是，這個操作被執行了。

執行了這些命令後，控制檔案成功建立了，並且資料庫也成功開啟了。似乎一切都OK了。沒想到，這個開啟的資料庫只是個樣子貨，大量的表無法訪問，一訪問就報錯。

從v$datafile中可以看到，其中有不少OFFLINE的檔案，甚至有很多檔案的checkpoint scn都是0。說明這些檔案從建立之後就一直沒有資料寫入。這又是什麼原因產生的呢?

繼續往前翻看ALERT LOG就會發現，原來那個重建控制檔案還不是第一個錯誤，真正的錯誤在20多天前就造就了。從日誌可以看出，DBA把standby 檔案管理方式設定為manual，然後手工刪除了一些名為UNNAMExxxxx的檔案。然後把這些檔案rename為一個裸裝置名。

這種神操作是幹什麼的呢?現在的很多DBA都沒有使用過裸裝置了，在使用裸裝置的情況下，為主庫準備裸裝置的時候，也一定要在備庫上準備好。如果主庫建立資料檔案的時候，備庫的裸裝置不存在，這樣在備庫中就會生成一個UNNAMEDxxxxxx的檔案。為了將這個檔案重新遷移到裸裝置上，DBA就做了上述操作。這種失誤以前發生過多次，每次都是採用這種方式去解決的。備庫上難免會遇到不小心忘記建立裸裝置的情況，不過只要處置得當也是沒問題的，採用這種方式處理資料檔案缺少了一個步驟，就是執行alter database create datafile ... As '....'。

錯誤的處置方式導致此類資料檔案一直處於未完成修改的狀態，也就是說這條非同步執行的命令並沒有正確執行結束。因此雖然這些裸裝置都已經存在了，DATAGUARD一直未對此檔案進行REDO APPLY。並且在DATAGUARD中檢視這些檔案的狀態是RECOVER狀態。實際上這些檔案大多數是空檔案，裡面從來沒有應用任何資料。

由於DATAGUARD中的這些檔案本身存在問題，導致這類檔案處於非正常狀態，這些檔案最早的是1月份建立的，所以要恢復這些檔案有些需要1月份以來的REDO LOG，有些需要4月7日以後的REDO LOG(DBA分別在1月份和4月份犯過忘記預先在DG庫建裸裝置的錯誤)，那個1_87118.dbf就是1月份的歸檔日誌，此時早就被清理了，當時已經無條件進行修復。

從上面的分析可以看出，雖然這個DG一直在跑著，實際上幾個月前就已經是個樣子貨了。而DG有問題並不影響生產系統，因此這個問題也一直沒有得到糾正，認為有DG保障的核心生產系統實際上一直在裸奔。

從今天舉的這兩個例子中可以看出，大部分的類似事故的發生都與運維團隊在處置問題的過程中缺乏資深的專家支援有關。DBA在做超出其認知能力的操作時，往往就會因為考慮不周或者錯誤的認知而犯更大的錯誤，從而引發更大的問題。此類問題發生時，獲得三線專家的支援尤為重要，因此在國外三線專家遠端支撐服務的市場很大。而在國內大家更願意為現場服務付費，而不願意像買保險一樣買一個遠端的專家服務。而當系統真的出故障的時候，花上買專家服務十倍的價錢去請人搞定故障大多數客戶還是願意的。只不過這種臨時參與的專家，對客戶的系統並不瞭解，要想在短時間內準確的定位問題，正確的解決問題，也是要打折扣的。