論Oracle備庫的設計方案

論Oracle備庫的設計方案

Oracle的ADG那是自不必多說，用儲存圈的話說，現在儲存正在從被動被動變為主動，但是總體上是被軟體搶，RAID被ASM搶，快照被Flashback搶，DR被ADG搶。

如果這幾種方案結合在一起那會是什麼結果。這就涉及到一個備庫的設計方法。

我也是拋磚引玉。環境都是基於11g的dg來說。

首先基本的，一個主庫一個備庫是很多系統都在採用的備庫設計方式，如果資料庫比較關鍵，這種方案有什麼缺點呢。

11g的備庫現在也被賦予了更多的責任。

容災，首先就是容災如果主庫掛掉，備庫能夠進行failover，這個沒有問題，那麼11g的備庫現在也被賦予了更多的責任。

批量查詢。可能會有一些批量查詢，報表查詢的任務。那麼這部分功能就可以放到備庫來。

人為操作的防範。如果出現了誤操作和人為操作，是否能夠及時合理的預防。

所以一主一備的方案就會有幾個弊端，

首先批量查詢，如果批量任務壓力較大，本身對於CPU資源消耗較大，如果長年累月，其實本身硬體消耗就不可忽略，如果長此以往，可能出了問題切過來也不見得保險。

如果出現人為誤操作，這種防範怎麼來說，如果延時怕丟太多資料，不延時，人為誤操作不可避免，一年出一次這樣的情況就夠我們好好折騰一番了。

那麼我們設計一主兩備？

如果這樣設計，對於關鍵業務也不錯的。不過有幾個需要考慮的地方，還是要滿足剛剛的幾個需求，災備，支援大查詢，人為誤操作防範。

那麼standby 1就可以設計為在同一個相鄰的地區內，而standby2則可以考慮成為異地災備，異地災備也是很重要的一個考慮，如果機房掉電，幾個備庫都在都一個機房，那就很可能受到牽連。

所以異地災備也很重要。那麼怎麼滿足上面三個需求呢。

首先災備，一主兩備，考慮了異地災備，這個本身就是一個不錯的解決方案。

然後支援大查詢，那麼可以考慮把大查詢的人物分散開來，在兩個備庫上跑，比如一個60%，一個40%等等，也不要讓備庫徹底閑著。同時壓力也降低了不少。

然後就是人為誤操作了。這個怎麼防範，如果按照目前的一主兩備的環境，也有幾種方案，一種就是對另外一個備庫開啟延遲應用歸檔。

比如對於異地災備standby2，設定延時2個小時，那麼這種情況下出現了人為誤操作，比如truncate就還有可能追回被誤刪的資料。不過僅僅是可能，因為到底是幾個小時誰也說不清楚。萬一出現了3個小時前的誤操作，大家最後發現是因為誤操作導致的，那麼這種方案也得掉鏈子了。

可能有的朋友會說了，如果在2個小時之內，比如切換了20個歸檔，truncate操作是在最後的歸檔中，即第20個歸檔中的操作，那麼第20個歸檔中的資料變化可能類似下面的形式。

transaction 1

transaction 2

transaction 3

transaction 4

….

transaction 10

truncate 那麼你怎麼保證一定能夠嚴格恢複回來，可能有的朋友說，可以使用logminer，恩，也可以，不過還是需要點功夫。而且不一定能夠100%保證吧。

還有什麼方案能夠繼續改進呢。可以試試閃回資料庫。

其實在11g中，閃回資料庫早已不是什麼新鮮特性了。那麼他怎麼來完成上面的三個需求呢。

災備自不必說，大查詢也可以支援，那麼人為誤操作呢。那就是下面的綠色箭頭所示。

通過在異地災備2上做閃回，然後穿越之後得到了需要的資料，接著exp匯出，然後部署到主庫中。然後備庫繼續開啟日誌應用即可。

看來這種方法還是能夠滿足這幾個需求了。

那麼我們再把這些需求再梳理一下。那麼在這種情況下，大查詢就可以分擔一下了，在備庫1上可以多分擔一些，備庫2上就可以少分擔一些。還有就是異地災備需要額外再加入一些閃回日誌的空間了。

那麼如果出現了同城機房兩台機器奔潰的情況，而且更為嚴重的是在崩潰的前一分鐘，出現了人為誤刪除操作，那麼異地災備會不會給力呢。

這種情況下，就需要先做閃回資料庫，exp出來需要的資料，然後做failover，然後關掉閃回資料庫的功能，接著就是重新部署搭建災備環境了，所以還是依舊可以保證，可能有一點美中不足就是可能閃回，如果表比較大，可能匯出資料都需要花費些時間了。

所以一主兩備的方式就能玩出這麼多花樣來，只要保證方案的穩定性，這麼來看閃回資料庫在一主兩備的條件下還是可以考慮採用。