最近對乙個統計庫做了計畫內的容災切換，即主備切換。操作的過程其實還是蠻順利的。但是災難切換中如果出現在問題，那就是災難中的災難了。
按照計畫對配置資訊做了同步，然後使用dg broker做了switchover操作。
這一次切換速度還是蠻快，我開了幾個視窗看到日誌都在不斷輸出，角色已經替換過來了。dg broker切換的日誌如下：
dgmgrl> switchover to test29;
performing switchover now, please wait...
new primary database "test29" is opening...
operation requires shutdown of instance "test2" on database "sgstatdb3"
shutting down instance "test2"...
ora-01031: insufficient privileges
warning: you are no longer connected to oracle.
please complete the following steps to finish switchover:
shut down instance "statdb2" of database "stest3"
start up instance "statdb2" of database "stest3"
這個時候備庫已經切換為主庫，只要重啟切換前的主庫即可。
但是這麼乙個簡單的操作就出了問題。shutdown immediate命令敲下去之後，客戶端就沒有反應了。
sql> shutdown immediate
ora-01092: oracle instance terminated. disconnection forced
sql> write failed: broken pipe
然後等了一下，從中控端去登入就無法連通了。這個問題確實夠奇怪，我去ilo檢視發現系統已經在自動重啟了。
當然寬慰的是切換已經完成，可以先讓應用的同學去測試他們的業務了。我們可以繼續處理這個意料之外的問題。
在宕機的瞬間，資料庫alert日誌只輸出了一行內容「
ora-1092 : opitsk aborting process
write failed: broken pipe
檢視ilo的介面，發現系統已經在初始化中了。
等了一會就看到系統的介面提示raid資訊貌似不一致了。這個庫里的盤很多，配置這個還真不在行。
簡單諮詢了下同事，還是選擇熱引導重啟，重啟之後，貌似那個問題是過去了，然後就彈出乙個錯誤。已經很明確告訴我是bug，而且是cpu相關的。
再次重啟，還是同樣的問題，這個時候我們就需要兩手準備，如果伺服器無法重啟，就需要馬上開始準備新的備庫的事宜了。
最後我們還是嘗試冷引導，類似斷電重啟的方式，這一次系統竟然起來了，也算是不幸中的萬幸了。
當然對於這個問題。馬上就收到了乙個報警簡訊，提示伺服器的/var目錄空間不足了。
仔細一看原來生成了kdump檔案，有大概6g左右。
-rw------- 1 root root 6446125056 may 26 11:15 vmcore-incomplete
對這個檔案是需要使用命令crash或者其它第三方工具檢視的，根據同事的反饋，在dell 720xd，系統6u3中確實會有這種問題。
我這個問題的必備條件全滿足了，我還在想是否為什麼之前沒有碰到過，仔細一看原來早就有這個坑了，去年的時候這個資料庫就重啟過，已經有了crash的問題了。
# ll
total 8
drwxr-xr-x 2 root root 4096 aug 2 2015 127.0.0.1-2015-08-02-09:50:47
drwxr-xr-x 2 root root 4096 may 26 15:46 127.0.0.1-2016-05-26-11:05:18
後續進行更多的分析。
Oracle容災資料庫 恢復演練方案
測試流程包含以下步驟 1 準備應用客戶端做為測試終端，配置連向容災資料庫的連線字串 2 恢復容災端歸檔日誌 3 在datagurad資料庫上建立還原點 4 啟用dataguard資料庫 5 應用客戶端連線到dataguard資料庫上進行應用測試 6 關閉dataguard，將其還原到還原點 7 檢查...
用PC作資料庫伺服器的容災問題
現在好多小單位都有自己的財務等一些小系統，但是又不想花大價錢購買昂貴的伺服器，基本上是去科技市場攢一台pc來當伺服器用。但是必競是pc機，故障的機率會大一些。尤其是硬碟 資料的心臟，但是壞的可能性也是最大的，這可真是一件頭大的事情。當然可以用raid實現，raid卡也需要主機板的支援，pc機的主機板...
資料庫的災備
資料是企業重要的生產資料，關鍵資料的丟失可能會給企業致命一擊，因為資料是計算機系統存在的原因和基礎。資料往往是不可再生的，一旦發生資料丟失，企業就會陷入困境 客戶資料 技術檔案 財務賬目等客戶 交易 生產資料可能被破壞得面目全非。資料丟失分為三個層次 邏輯錯誤 包括軟體bug 病毒攻擊 資料塊被破壞...