淺析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的整個情況了。