小議應急系統

     本人接觸應急這個概念是從2008年開始的，當時是爲了奧運會的須要，主要是oracle數據庫的應急；2009年國慶60週年保障，應急範圍擴大到幾個核心的平臺組件；到2010年亞運會時，應急範圍進一步擴大，應急要求更高；這些應急主要針對的是oracle數據庫、主要的平臺組件，各業務子系統並無歸入應急範圍以內。

    因爲系統是由一百多臺機器組成的，爲一個省幾千萬用戶提供7×24小時服務，它的業務對數據庫的依賴性很強，因此存在很大的風險：一旦數據庫宕機，那全省的業務就會癱瘓，所以系統的應急核心是oracle的應急。

    應急數據庫的創建過程：
1. 統計線網表及佔用空間、在小型機上劃分相應的文件空間。
2. 安裝同線網相同版本的oracle。
3. 數據庫表空間建立及空間劃分、應急賬號創建。
4. 用exp導出數據庫對象，先導表結構，再導須要的表數據。
5. 先讓應急庫的JOB和觸發器失效，再用imp導入數據庫對象。
6. 添加相關索引，編譯失效對象。

    其它應急服務的創建：
1. 在應急機器上部署其它應急服務，
2. 裝好服務後，拷貝線網的目錄到應急服務進行替換，這樣應急和線網保持同步。
3. 修改各配置文件，進行測試。

應急實施：
1. 先各單模塊進行演練，保證各個應急系統都能使用，並根據演練結果進行修正。
2. 編寫完整的切實可行的應急演練方案。
3. 應急演練方案，要考慮如下:
3.1 應急演練空間和時間,應急的影響範圍。
3.2 應急小組人員名單和職責。
3.3 應急準備檢查，各類資源是否準備齊全。
3.4 什麼條件下啓動應急、步驟是什麼。
3.5 應急過程當中如何進行協調通報、如何進行業務測試。
3.6 什麼條件下進行應急倒回、倒回後的業務測試等。
3.7 應急倒回線網後失敗的處理預案等。
4. 根據上面的方案，進行全系統的應急演練。
5. 根據演練的結果，對應急方案加以更正。
6. 平常要對應急系統和方案不斷的完善更新，使應急和線網系統保持同步更新。
7. 組織按期的應急演練，使系統不斷完善，作到災難發生時從容不迫。

     以上就是本人蔘與應急的一些總結，列出以便參考並加以完善，不足之處望見諒。