Oracle 10g 一主多備的搭建技巧

Oracle 10g 一主多備的搭建技巧

在Oracle資料庫環境中，一主一備是比較傳統的使用方式，在災難發生的時候，可以靈活的切換主備角色，依然可以保持服務的可訪問性。但是一些核心系統來說還是會有更多的過濾，一主一備似乎還是不夠穩妥，如果主備出現問題，如果有另外一個備庫還是有可選的餘地，這種情況不是不可能發生，正是因為核心業務的需要還是需要保證資料的安全。

很多情境下，一主兩備會保持這樣的情境，一主一備在同一個地區內，這樣在出現問題的時候方便切換，如果地區出現故障，可以保證異地的機房可以順利承接服務。

比如下面的這種方式是比較傳統的一主一備的方式。因為是在10g的環境中，所以備庫還是Mount，不能open線上接收資料變更。

在這種結構下，如果根據需要去添加另外一個備庫節點，就需要考慮到一些負載的因素。畢竟我們不希望主庫有很多的資料檔案複製工作，儘管duplicate特性還是比較方便的。

這個時候我們可以只動用備庫匯出響應的備份資料來。如果這個時候主庫出現問題，可以隨時終止rman備份，直接切換環境。

[img]http://blog.itpub.net/attachment/201507/30/23718752_1438270167iH25.png[/img]

當然利用備庫匯出rman dump，在另外一個備庫來做恢複，如果檔案路徑等等存在偏差，或者限於dump的大小和磁碟空間，可能會把dump放在不同的路徑下，就可以直接設定catalog來恢複。

大體的四個步驟如下面的藍色方框所示。這個時候主庫和備庫之間還是沒有任何的直接關聯，所以從這個地方，也把主庫的負載降到了最低。

資料庫恢複之後，這就是一個新的備庫，我們可以通過dg broker來建立和主庫的關聯關係。這個時候回在三個節點間進行一些配置資訊的同步，過程還是比較快的。

就這樣，一主兩備的環境就搭建好了。

其實我們還可以這麼思考，把switchover的情境和failover都結合起來，如果在switchover出現失敗的情況下，我們可以動用第二個備庫來做failover.

怎麼理解呢，switchover在一些外部因素的作用下還是可能會失敗，比如在10g版本中，我們把備庫啟動到了read only狀態，結果資料變更都會延遲，如果延遲夠大，rman配置可能會把一些曆史的歸檔給刪除掉，儘管RFS把歸檔傳到了備庫，但是MRP還沒有開始工作，所以備庫中的歸檔還沒有使用到。這個時候主庫奔潰，那個read only的備庫做switchover就很可能失敗。

這個時候我們還是保證另外一個備庫在mount狀態，我們可以直接做failover