淺析Oracle 12c中Data Guard新特性

 

寫在前面

無論是做Oracle運維的小夥伴還是老夥伴，想必對Oracle資料庫的資料級災備核心技術—Data Guard是再熟悉不過了！這項從Oracle 8i就開始大面積普及的資料複製與災備技術以其久經考驗的成熟性、易用性和可靠性，受到了Oracle DBA界的一致好評，曾經一度是HA和DR，甚至資料遷移時的首選技術。然而近年來業界湧現的一系列新型技術方案，如基於日誌的邏輯複製技術和儲存底層複製技術等，有在某些方面超越Data Guard的趨勢，甚至越來越多的DBA相信這項火了十多年的技術也差不多快壽終正寢了。。。

不過Oracle就是這麼任性，在大家都原以為會有顛覆性改變的12c版本中，不但保留了Data Guard作為資料災備尤其是物理級災備的核心地位，而且針對原有技術中的痛點，加入了若干實用又有趣的新特性，使之再次煥發出新的魅力！今天小編就帶大家領略一下，在12c中Data Guard又給我們帶來了什麼~

沒毛病

 

 

無需妥協

為兩地三中心設計的Far Sync

近幾年兩地三中心已經成為大型成熟企業的標準災備架構，而談到災備當然就離不開資料級災備，對於Oracle資料庫來說，就是Data Guard技術。然而架構師和DBA常常苦惱於Data Guard配置方案的權衡：如果採用SYNC同步傳輸模式，雖然備庫與主庫的同步會更緊密，遇到事故時資料保護的更好，但是畢竟對生產效能有一定影響，而絕大多數資料中心的首要任務是保障生產；但是如果配置為ASYNC非同步模式，雖然對於主庫的效能影響小了，但是備庫與主庫之間必然出現一定的延遲，這對於資料完整性要求很嚴格的交易類系統是比較嚴重的風險。而如果使用級聯DG（Cascade Data Guard），又不得不在中轉節點放置一整套儲存來實現DG的搭建，儲存的消耗與主庫是一樣的，這又是一定程度上資源的浪費。想必設計師只能在多種方案間權衡利弊，反覆妥協，左右為難。

而在12c版本中，這個棘手問題的大救星終於來了，它就是Far Sync技術。

 

Far Sync

在Oracle 12c中，新增一種稱為Far Sync的例項型別（instance type），如同rdbms和ASM例項，far sync本身就是一種特殊型別的例項，它不執行資料庫，沒有資料檔案，而只有日誌檔案，是一種專門用於Data Guard配置中負責日誌轉發的輕量級例項。這個far sync例項需要配置在離主庫距離不遠的機房，例如同資料中心的其他機房或者同城災備的機房，以便實現同步日誌傳輸。

       Far Sync例項的建立也是很簡單的：

 

只需要拷貝主庫的引數檔案和密碼檔案，使用standby control file和standby redo logfile即可完成far sync例項的建立；由於far sync不執行實際的資料庫，也就沒有資料檔案，對於儲存的需求量是很低的。

然後我們就可以配置基於far sync的Data Guard架構了，如圖所示，我們可以在主庫（Primary）的附近搭建far sync例項，並在主庫與Far sync，以及Far sync與遠端的備庫（standby）之間分別配置Data Guard。這裡的far sync可以看做主庫傳輸日誌的一個destination，而備庫standby又作為far sync的destination，類似於Cascade Data Guard，但是別忘了，far sync是沒有資料檔案的，只負責轉發日誌。

搭建完畢後，我們就可以開始Data Guard的日誌傳輸了：在這個新式的配置中，主庫與far sync之間採用SYNC同步傳輸模式，而far sync與備庫之間採用ASYNC非同步傳輸模式。這樣做的好處大家應該也能猜到了：由於far sync離主庫距離很近，所以SYNC模式不會造成什麼效能影響，而且又保證了主庫的日誌可以得到災備的保護；同時far sync例項再繼續以ASYNC非同步模式將日誌傳輸到備庫，由於far sync已經有了主庫產生的全部日誌，這些日誌傳輸到備庫只是時間問題，因此主庫也不再需要苦苦地等待備庫傳送ACK回來才能commit事務，而是將後續的日誌轉發工作交給了far sync去完成，自己可以輕裝上陣，保證生產。

值得注意的是，在12c中Oracle強烈推薦使用DG Broker完成DG的管理，尤其是對於多於一個備庫的情況，如果不使用broker，那管理起來簡直就是一場噩夢。複雜的拓撲結構和繁多的屬性，如果沒有使用broker獲得一個自上而下的整體檢視，會讓管理員很快懵逼，而做切換的時候需要協調N多個例項和備庫的角色關係，沒有broker的話就幾乎是mission impossible了！

一個配置完成的far sync結構如下圖所示：（就是我們在broker中看到的）

 

DG

從圖中我們可以清晰的看到整個Data Guard的整體配置情況，哪個是主庫，哪個是備庫，哪個是far sync，一目瞭然。更重要的是我們在後續的修改屬性和角色切換的時候，可以一鍵式管理，大大減輕了管理員的工作負擔，減少了人為失誤的可能性。這裡要為DG broker這款工具點個贊！

 

  中庸之道 

 

最大可用模式中的FAST SYNC

來，敲黑板，我們先複習一下：在Oracle 11g中，DataGuard主要有兩種日誌傳輸模式—同步SYNC AFFIRM和非同步ASYNC NOAFFIRM（當然還有ARCH模式，但是由於LGWR ASYNC的效能已經得到極大優化，ARCH模式已經不再推薦）。通常最大效能模式下使用ASYNC NOAFFIRM，即日誌從主庫傳輸出去之後就可以完成事務commit，而無需收到來自備庫的確認ACK；而在最大保護和最大可用模式下使用SYNC AFFIRM，即必須保證每筆事務都正確傳輸到備庫並寫入磁碟，主庫收到備庫的確認ACK之後才可以完成提交，否則主庫必須等待。

有一定DG維護經驗的DBA會感覺到，最大可用模式作為一種介於最大效能和最大保護之間的折中模式，使用SYNC AFFIRM有些過了，多數情況下可能不需要犧牲這麼大的效能來換取如此嚴苛的資料保護。因此12c給最大可用模式提供了一種稱為 FAST SYNC的模式，也就是SYNC NOAFFIRM，主庫與備庫之間仍然以同步模式傳輸，但是主庫只需等待備庫收到日誌即可，而無需進一步等待備庫的日誌寫入磁碟才能提交，這就大大降低了效能的損耗，同時仍可以保證主庫備庫之間的資料同步。

FAST SYNC的配置也很簡單：

 

我們可以在引數檔案和DG Broker中實現FAST SYNC的配置

當然了FAST SYNC這個FAST也不是白來的，那麼我們考慮一下，什麼情況下FAST SYNC比SYNC的保護弱呢？我們知道，二者的主要區別在於是否等待備庫收到日誌後寫入磁碟。那麼答案也就顯而易見了：如果主庫故障之後，由於繼發性故障或者純粹運氣不好，備庫的記憶體資訊沒有來得及寫入磁碟，那麼記憶體中的最新日誌資訊就會丟失，造成資料不一致。所以是否採用FAST SYNC替代SYNC模式，就要看能否接受這個小概率事件的風險了。

升級神器

Data Guard rolling

作為一名DBA恐怕最害怕聽見的詞彙就是升級/遷移了---那意味著不知多少個不眠之夜，以及各種明處暗處的技術風險。Logical Data Guard作為一種常用的升級/遷移技術方案，因其可靠性高，停業時間短受到了DBA們的歡迎。但是這套方案的一個不足之處就是實施過程過於複雜，小編粗粗一算至少需要42個步驟才能完成一輪最簡單的一主一備升級，如果涉及多套庫，那這個複雜性會指數級地倍增。為了降低採用rolling技術升級的複雜性，減少人為失誤可能帶來的損失，oracle在12c中提供了新的DBMS_ROLLING包來幫助我們自動化地完成一系列升級任務。

DBMS_ROLLING包採用Specification—Compilation—Execution三步走的協議，只需DBA設定幾個引數，即可自動實現後續的一系列配置、切換、啟停庫、驗證等操作。在DBMS_ROLLING中有leading group和trailing group的概念，我們暫時簡單理解為初始的備庫和主庫就好，實施的步驟包括初始化—設定引數—生成計劃—驗證計劃—執行切換—收尾等過程。

 

之後繼續呼叫DBMS_ROLLING.START_PLAN, DBMS_ROLLING.SWITCHOVER, DBMS_ROLLING.FINISH_PLAN這三個儲存過程，即可實現自動化的切換升級。

DG Broker的Routing規則集

在最簡單的一主一備配置中，日誌的傳輸路由是顯而易見的；但是如果Data Guard的配置涉及多個備庫，尤其是我們上面提到的far sync，拓撲結構極為複雜，那麼如果有效管理如此多的資料庫的傳輸路由便成了令人頭疼的難題。好在Oracle 12c的DG Broker為我們提供了Routing Rule這個新特性，可以傻瓜式地設定和管理多庫環境下的傳輸路由。

我們假設Boston是主庫，Cambridge是far sync，Chicago是物理備庫，Shaumburg是反向far sync（切換後才工作），那麼我們需要的路由便是：當Boston是主庫時，日誌先傳輸到Cambridge這個far sync，再轉發到備庫Chicago；而當切換主備庫之後，新的主庫Chicago將日誌先傳輸到Shaumburg這個反向far sync，然後再轉發到Boston。如果使用sqlplus中逐個修改引數的方法，不但容易出錯，而且DBA也無法從整體上監控整個DG的完整拓撲；而我們現在使用DG Broker提供的Routing rule特性，只需簡單的幾條配置命令即可完成配置，還可以利用DGMGRL介面管理整個DG的配置資訊：

 

當我們配置完成後，即可看到DG Broker的配置成功生效了：

 

這樣看是不是清晰多了？各種角色的拓撲關係一目瞭然，而且一鍵式切換之後，可以立刻看到切換成功之後的角色和路由關係，這樣也就不需要挨個登入每套資料庫檢查引數然後再自行腦補出DG的整個情況了。