DG、ADG、OGG的解析

以oracle 11G版本爲準進行解析
Data Guard Architecture Overview (Data Guard架構概述)
Data Guard provides the management, monitoring, and automation software to create and maintain one or more synchronized copies of a production database to protect Oracle data from failures, disasters, human error, and data corruptions while providing high availability for mission critical applications. Data Guard is included with Oracle Database Enterprise Edition.
Data Guard提供管理，監視和自動化軟件，用於建立和維護生產數據庫的一個或多個同步副本，以保護Oracle數據免受故障，災難，人爲錯誤和數據損壞，同時爲關鍵任務應用程序提供高可用性。 Data Guard包含在Oracle數據庫企業版中。
Active Data Guard Functionality Overview (Active Data Guard功能概述）
Active Data Guard is an option license for Oracle Database Enterprise Edition. Active Data Guard enables advanced capabilities that that extend basic Data Guard functionality. These include:

Real-Time Query - offload read-only workloads to an up-to-date standby database

Automatic Block Repair - automatic repair of physical corruption transparent to the user

Far Sync - zero data loss protection across any distance

Standby Block Change Tracking - enable incremental backups on an active standby

Active Data Guard Rolling Upgrade - make it simple to reduce planned downtime

Global Database Services - load balancing and service management across replicated databases. See Global Data Services

Application Continuity - make outages transparent to users. See Application Continuity
Active Data Guard是Oracle數據庫企業版的選件許可證。 Active Data Guard支持擴展基本Data Guard功能的高級功能。 這些包括：

實時查詢 - 負責將主庫最新的數據刷新到物理備庫

自動塊修復 - 自動修復對壞的數據塊進行修復

遠程同步 - 任何狀況下的主備同步，實現零數據丟失保護。

備庫開啓塊跟蹤 - 在備庫開啓塊跟蹤，實現備用數據庫上啓用增量備份。

Active Data Guard滾動升級 - 簡化計劃停機時間

全局數據庫服務 - 跨複製數據庫的負載平衡和服務管理。 請參閱 全球數據服務

應用程序連續性 - 使中斷對用戶透明。 請參閱 應用程序連續性 （應用程序連續性（AC）是Oracle Real Application Clusters（RAC），Oracle RAC One Node和Oracle Active Data Guard選項的一項功能，可經過在可恢復的中斷後恢復正在進行的數據庫會話來屏蔽最終用戶和應用程序的中斷。 應用程序連續性經過在中斷後恢復受影響的數據庫會話的正在進行的工做來屏蔽最終用戶和應用程序的中斷。 應用程序連續性在應用程序下執行此恢復，以便中斷在應用程序中顯示爲略微延遲的執行。
應用程序連續性用於在處理意外中斷和計劃維護時改善用戶體驗。 應用程序連續性加強了使用Oracle數據庫的系統和應用程序的容錯能力。）

Oracle GoldenGate（OGG）：
是一個實現異構IT環境間數據實時數據集成和複製的綜合軟件包。該產品集支持高可用性解決方案，實時數據集成，事務更改數據捕獲，運營和分析企業系統之間的數據複製，轉換和驗證.Oracle GoldenGate 12 c經過簡化配置和管理，增強與Oracle數據庫的集成，支持雲環境，擴展異構性以及加強安全性，實現了高性能。

除了用於實時數據移動的Oracle GoldenGate核心平臺，Oracle還提供了適用於Oracle GoldenGate的管理包（用於Oracle GoldenGate部署的可視化的管理和監視解決方案）和Oracle GoldenGate Veridata（容許在兩個正在使用的數據庫之間進行高速，海量的比較）。

表格對比總結

ADG最大的特色仍是能作到同步複製，而OGG的數據複製在亞秒級，仍是隻能算做異步複製。

2、應用場景分析
DG能夠用在容災測試上，在金融、電力、能源行業，生產上常見的容災架構爲ADG，尤爲是異地災備。也有部分較高要求的採用 RAC + ADG，這裏的RAC有的是基於存儲集羣虛擬出來的分佈式卷之上作的RAC，有的是經過ASM冗餘設計自己實現的。OGG在重大變動須要異構數據庫同步數據的場合下或者是數據集中平臺上採用。

ADG，最經常使用的同城，異地災備解決方案，物理級備份，備機不可寫，傳輸數據爲全部redo日誌的更改，數據量稍大，不過從以往的使用經驗來看，也不太會影響網絡，除非應用對網絡有很苛刻的要求，即便有，也能夠經過vlan或者路由或者多網卡的方法特別創建網絡通道，主備庫徹底一致，缺點是必須全庫備份。OGG，DSG這兩個是一個類型的，邏輯備份，主要採用特有的技術從聯機日誌中抽取更改項應用到備庫，主備庫爲兩個庫，能夠全庫同步也能夠同步單張表或數張表，同步速度較快，傳輸數據量不多，DML操做和DDL操做均支持。

ADG 同構平臺數據同步，OGG能夠異構平臺數據同步。
ADG 能夠經過快照方式保留當前時刻點數據，OGG不能作到。
ADG 直接經過日誌重作實現數據複製，OGG是經過對日誌加工以後的模式進行數據分析實現複製。

3、 RAC + ADG雙活解決方案的難點和關鍵點是什麼？如何解決？
1）針對分佈式存儲卷架構的仲裁一致性問題

在這個問題上，風險發生的引起點有兩個：數據庫和集羣的仲裁觸發以及仲裁過程的時間順序發生紊亂；資源被1:1割裂以後的默認仲裁策略不一致。也就是說，只要控制這兩個引起點，那麼這個問題從理論上也就避免了。對於第一個引起點來說，實際上存儲集羣的默認仲裁觸發時間會是15秒左右，而數據庫仲裁觸發的控制參數由misscount（默認30秒）這個參數來決定，因此只要咱們將misscount這個參數調整到45秒以後，也就是說理論上絕對保障存儲集羣仲裁在前，而數據庫仲裁在後，那麼第一個引起點就沒有了。對於第二個引起點來說，假設兩站點節點資源對等，仲裁選票一樣對等的狀況下，存儲集羣會有一個默認的Winner策略，一樣在這種狀況下數據庫集羣也有一個默認仲裁策略：選擇實例號小的集羣存活。只要咱們保證這兩個策略結果的一致性，那麼第二個引起點也就不存在了。

2）鏈路穩定情況不可控

這個問題是兩種架構都面臨的問題。主要表現爲兩個方面：鏈路穩定情況不可控；延時指標不可控。由於雙中心之間的鏈路是經過租用運營商的裸光纖鏈路實現的，那麼這其中會經歷不少的中繼設備及節點。不管從管理上仍是從技術把控上都是金融企業自身不可控制的因素。假設雙中心間鏈路延時指標不穩定，也就是說數據庫節點之間私網傳輸的延時會常常出現長延時狀況，這勢必致使這種延時會加倍放大到數據庫節點之間的讀寫熱點競爭上。因爲數據庫集羣之間的數據傳輸量很是大（緩存、鎖、心跳等），在讀寫熱點相對突出的業務上，輕則致使數據庫讀寫性能災難，重則致使數據庫節點直接處於僵死狀態。另外，鏈路的不穩定會致使存儲鏈路頻繁切換，甚至會致使集羣仲裁頻繁發生，這對於業務連續性更是一個災難。

對於這個問題來說，就目前金融、電力、能源行業的傳統數據架構來說，並無一個十足的解決方案。咱們只能經過如下措施來減小這種問題帶給咱們的風險。

i、業務層面須要進行拆分重組：按照IO特色進行合理拆分，將讀寫業務儘可能分佈於不一樣節點上，減小節點間的鎖競爭。按照業務將數據庫表進行分區，避免在數據庫寫上的數據熱點塊兒。例如，對於銀行核心系統來說，尤爲是要將批量業務和聯機業務區分對待，批量業務的熱點以及數據量很是之巨大，因此必定要將批量業務的數據庫讀寫放在單邊實現。對於聯機業務來說能夠根據熱點情況以及鏈路質量評測結果能夠嘗試實現雙中心同時讀寫，可是本文建議對於這種重量級的業務仍是要從業務層儘可能實現應用上的讀寫分離，或者在應用層雙中心部署而在數據庫層將數據引到單邊來作。

ii、雙中心間通信的總體控制，具體包括對通信帶寬的優先級管理、對通信的實時監控和控制、對跨中心數據傳輸的嚴格策略把控。例如：優先保障存儲和數據庫通信的優先級和帶寬，嚴格的規則算法和優先級限定VMOTION、DRS等行爲的跨中心隨意性，從LTM負載分發上儘量保障正常狀況下縱向IO的單中心效率策略，故障狀況下保障跨中心訪問的科學性。DWDM上設置雙中心間通信帶寬的邏輯隔離以及實時可控。

3）存儲網絡故障氾濫

這是兩種架構都會面臨的問題，只是ASM冗餘設計架構可能性相對高一些。

若是咱們把兩個中心的SAN環境整合爲一張大網，物理上沒有任何隔離的大網，那麼可能會由於局部的存儲網絡故障而波及到整個存儲網絡。儘管咱們經過SAN交換機上的邏輯隔離可以解決大部分的安全問題，可是這樣的風險畢竟仍是存在的。

因此咱們能夠經過對數據中心內部SAN環境先後物理隔離，雙中心之間靠專注SAN交換機實現存儲後端網絡的聯通來解決該問題。這樣的話，單中心內前段SAN環境故障不會波及存儲後端，更不會波及整個基礎架構的存儲網絡。

4）串聯深度帶來的性能問題

這個問題是針對分佈式存儲卷架構的問題。

架構深度越深，那麼IO的性能就會越差，由於IO每通過一層設備就會有必定的延時消耗，縱向深度越深經歷的設備越多，那麼IO的延時也就越高。若是咱們的架構在縱向上越複雜，那麼這個問題應該說從本質上是沒法消除的，只能經過必定的方法來減小和優化。

從存儲層來看，通常存儲側在對物理捲進行虛擬化的時候都會有幾種策略。爲了增長管理的靈活性及擴展性，虛擬化的時候可能會通過多層映射。另一種策略是爲了提升性能，在虛擬化的時候儘可能較少映射。咱們在規劃存儲卷的時候，儘可能採用後一種策略。例如VPLEX就會有（1:1map、Raid等策略），咱們能夠選擇1:1map這種策略，僅僅利用它的鏡像聚合，而捨棄它的靈活伸縮特性。

4、從RPO和RTO角度來看RAC和ADG

1)從RPO角度來看，RAC方案能夠作到理論上的絕對同步。ADG能夠作到近似同步，可是通常用在異步場合。

2)從RTO角度來看，RAC方案能夠作到理論上的秒級自動故障轉移。ADG通常須要人工去實現備庫切換，並且須要應用改變鏈接IP地址，從新啓動。

3)從風險角度來看，RAC方案一旦實現距離拉伸，最大的風險在於遠距離光纖條件下的節點之間的數據交互。而ADG方案就沒有該風險存在。

4)從方案的複雜度來看，RAC方案理論上須要第三點的仲裁，須要雙中心二層打通等複雜環境條件。而ADG和OGG方案只須要網絡三層可達便可。

5)從投資成原本看，RAC方案實現距離的拉伸以後，須要的環境成本（網絡條件、仲裁條件）等都須要較高的成本。ADG和OGG方案沒有這些成本。

由此能夠看出，實際上從容災角度考慮（RTO/RPO）,那麼RAC方案必定是比ADG方案能實現RTO和RPO的更高目標，可是從成本和風險角度考慮，ADG又是最佳的選擇。

補充：
Oracle 網絡&磁盤心跳機制
網絡心跳
網絡心跳（Network Hearbeat）是RAC的內部通訊機制，每隔一秒鐘，CSSD的一個線程（sending進程）發送一個TCP網絡心跳包給本身和集羣中的其餘節點，同時CSSD的另一個進程（receiving進程）接收到心跳。若是網絡傳輸包被drop或者出現錯誤，那麼TCP的錯誤糾正機制會重傳這個數據包，Oracle在這種場景下不參與網絡包的重傳。若是一個節點在15秒（50% of misscount）內都接收不到來自其它節點的心跳信息，那麼在CSSD日誌中會發現關於心跳丟失的「WARNING」信息。一樣當該節點在22秒（75% of misscount）以及在27秒（90% of misscount）都沒有接收到其餘節點的心跳信息時，在CSSD日誌中會依次發生警告。一直到30秒（Oracle 默認是30秒，可調節）爲心跳丟失的完整週期，該節點會被驅逐。
磁盤心跳
磁盤心跳（Disk Heartbeat)是發生在集羣間以及仲裁盤間的心跳。每一個RAC節點中的CSSD進程會在仲裁盤（voting disk）上面經過讀寫方式進行磁盤心跳維護，經過調用操做系統層pread/pwrite進程對1個操做系統block塊進行必定偏移量的讀寫操做。除了維護本身的磁盤心跳（讀寫磁盤的偏移塊），CSSD進程還會監控集羣中其餘節點CSSD進程維護的磁盤心跳。/這個不斷被刷新的數據庫頭部記錄節點名稱和計數位，該計數位會在發生心跳探測時被集羣中其餘節點刷新（經過pwrite）。磁盤心跳是經過CSSD進程維護在心跳盤（vote disk）上面，若是存在某一節點因爲IO超時沒有刷新磁盤心跳，那麼該節點會被宣佈死掉。若是一個節點處於未知狀態，沒有真正的死掉，可是沒有在存活的羣組裏，那麼該節點會被驅逐，該節點會被在vote磁盤磁盤上更新爲kill，被驅逐掉。
總而言之，網絡心跳每秒鐘會相互ping一次，集羣節點必須在css_miscount（默認值是30s）設置的時間內響應，若是規定時間內未響應，則會致使被驅逐。同時，對於磁盤心跳，每秒鐘集羣節點會經過vote盤讀寫進行集羣通訊，節點必須在disk timeout時間內響應。

補充：基於ASM冗餘設計架構實現的數據庫雙活方案，如何規劃ASM？
ASM使用獨特的鏡像算法：不鏡像磁盤，而是鏡像盤區。做爲結果，爲了在產生故障時提供連續的保護，只須要磁盤組中的空間容量，而不須要預備一個熱備(hot spare)磁盤。不建議用戶建立不一樣尺寸的故障組，由於這將會致使在分配輔助盤區時產生問題。ASM將文件的主盤區分配給磁盤組中的一個磁盤時，它會將該盤區的鏡像副本分配給磁盤組中的另外一個磁盤。給定磁盤上的主盤區將在磁盤組中的某個夥伴磁盤上具備各自的鏡像盤區。ASM確保主盤區和其鏡像副本不會駐留在相同的故障組中。

磁盤組的冗餘能夠有以下的形式：雙向鏡像文件(至少須要兩個故障組)的普通冗餘(默認冗餘)和使用三向鏡像(至少須要3個故障組)提供較高保護程度的高冗餘。 一旦建立磁盤組，就不能夠改變它的冗餘級別。爲了改變磁盤組的冗餘，必須建立具備適當冗餘的另外一個磁盤組，而後必須使用RMAN還原或DBMS_FILE_TRANSFER將數據文件移動到這個新建立的磁盤組。三種不一樣的冗餘方式以下：

一、 外部冗餘（external redundancy）：表示Oracle不幫你管理鏡像，功能由外部存儲系統實現，好比經過RAID技術；有效磁盤空間是全部磁盤設備空間的大小之和。

二、 默認冗餘（normal redundancy）：表示Oracle提供2份鏡像來保護數據，有效磁盤空間是全部磁盤設備大小之和的1/2 （使用最多）

三、 高度冗餘（high redundancy）：表示Oracle提供3份鏡像來保護數據，以提升性能和數據的安全，最少須要三塊磁盤（三個failure group）；有效磁盤空間是全部磁盤設備大小之和的1/3，雖然冗餘級別高了，可是硬件的代價也最高。