不少未實際接觸過dg的初學者可能會下意識以爲dg是一個備份恢復的工具。我要說的是，這種形容不完全錯，dg擁有備份的功能，某些情況下它甚至可以與primary數據庫完全一模一樣，但是它存在的目的並不僅僅是爲了恢復數據，應該說它的存在是爲了確保企業數據的高可用性，數據保護以及災難恢復(注意這個字眼，災難恢復)。dg提供全面的服務包括：創建，維護，管理以及監控standby數據庫，確保數據安全，管理員可以通過將一些操作轉移到standby數據庫執行的方式改善數據庫性能。後面這一長串大家可以把它們理解成形容詞，千萬不要被其花哨的修飾所迷惑，要抓住重點，要擁有透明現象看本質的能力，如果沒有那就要努力學習去擁有，下面我來舉一個例子，比如我們夸人會說它聰明勇敢善良等等，這些就屬於形容詞，不重要，重點在於我們究竟想形容這個人是好人還是壞人。然後再回來看看oracle對dg功能上的形容，數據保護和災難恢復應該都可以歸結爲高可用性，那麼我們可以清晰的定位dg的用途了，就是構建高可用的企業數據庫應用環境。
一、Data Guard配置(Data Guard Configurations)
Data Guard是一個集合，由一個primary數據庫(生產數據庫)及一個或多個standby數據庫(最多9個)組成。組成Data Guard的數據庫通過Oracle Net連接，並且有可能分佈於不同地域。只要各庫之間可以相互通信，它們的物理位置並沒有什麼限制，至於操作系統就更無所謂了(某些情況下)，只要支持oracle就行了。
你即可以通過命令行方式管理primary數據庫或standby數據庫，也可以通過Data Guard broker提供的專用命令行界面(DGMGRL)，或者通過OEM圖形化界面管理。
1.Primary 數據庫
前面提到，Data Guard包含一個primary數據庫即被大部分應用訪問的生產數據庫，該庫即可以是單實例數據庫，也可以是RAC。
2.Standby 數據庫
Standby數據庫是primary數據庫的複製(事務上一致)。在同一個Data Guard中你可以最多創建9個standby數據庫。一旦創建完成，Data Guard通過應用primary數據庫的redo自動維護每一個standby數據庫。Standby數據庫同樣即可以是單實例數據庫，也可以是RAC結構。關於standby數據庫，通常分兩類：邏輯standby和物理standby，如何區分，兩類各有什麼特點，如何搭建，這方面內容就是後面的章節主要介紹的，在這裏呢三思先簡單白話一下：
* 邏輯standby
就像你請人幫你素描畫像，基本器官是都會有的，這點你放心，但是各器官位置啦大小啦膚色啦就不一定跟你本人一致了。
* 物理standby
就像拿相機拍照，你長什麼樣出來的照片就是什麼樣，眼睛絕對在鼻子上頭。或者說就像你去照鏡子，裏外都是你，哇哈哈。具體到數據庫就是不僅文件的物理結構相同，甚至連塊在磁盤上的存儲位置都是一模一樣的(默認情況下)。
爲什麼會這樣呢？這事就得從同步的機制說起了。邏輯standby是通過接收primary數據庫的redo log並轉換成sql語句，然後在standby數據庫上執行SQL語句(SQL Apply)實現同步，物理standby是通過接收並應用primary數據庫的redo log以介質恢復的方式(Redo Apply)實現同步。
另外，不知道大家是否注意到形容詞上的細節：對於相機拍照而言，有種傻瓜相機功能強大而操作簡便，而對於素描，即使是最簡單的畫法，也需要相當多的練習才能掌握。這個細節是不是也說明邏輯standby相比物理standby需要操作者擁有更多的操作技能呢？
二、Data Guard服務(Data Guard Services)
* REDO傳輸服務(Redo Transport Services)
控制redo數據的傳輸到一個或多個歸檔目的地。
* Log應用服務(Log Apply Services)
應用redo數據到standby數據庫，以保持與primary數據庫的事務一致。redo數據即可以從standby數據庫的歸檔文件讀取，也可直接應用standby redo log文件(如果實時應用打開了的話)。
* 角色轉換服務(Role Transitions)
Dg中只有兩種角色：primary和standby。所謂角色轉換就是讓數據庫在這兩個角色中切換，切換也分兩種：switchover和failover
switchover：轉換primary數據庫與standby數據庫。switchover可以確保不會丟失數據。
failover：當primary數據庫出現故障並且不能被及時恢復時，會調用failover將一個standby數據庫轉換爲新的primary數據庫。在最大保護模式或最高可用性模式下，failover可以保證不會丟失數據。
注：上述各概念簡要了解即可，這裏寫的太簡單，不要咬文嚼字，不然你會越看越糊塗，相關服務在後面章節將會有詳細介紹，不僅有直白的描述，還會有示例，再加上淺顯的圖片，就算你一看不懂，再看肯定懂：） 三、Data Guard保護模式(Data Guard Protection Modes)
對於Data Guard而言，其生存邏輯非常簡單，好好活，做有意義的事，做黑多黑多有意義的事：）
由於它提供了三種數據保護的模式，我們又親切的叫它：有三模：
* 最大保護(Maximum protection)：
這種模式能夠確保絕無數據丟失。要實現這一步當然是有代價的，它要求所有的事務在提交前其redo不僅被寫入到本地的online redo log，還要同時提交到standby數據庫的standby redo log，並確認redo數據至少在一個standby數據庫可用(如果有多個的話)，然後纔會在primary數據庫上提交。如果出現了什麼故障導致standby數據庫不可用的話，primary數據庫會被shutdown。
* 最高性能(Maximum performance)：
這種模式提供在不影響primary數據庫性能前提下最高級別的數據保護策略。事務可以隨時提交，當前primary數據庫的redo數據也需要至少寫入一個standby數據庫，不過這種寫入可以是不同步的。
如果網絡條件理想的話，這種模式能夠提供類似最高可用性的數據保護而僅對primary數據庫有輕微的性能影響。
* 最高可用性(Maximum availability)：
這種模式提供在不影響primary數據庫可用前提下最高級別的數據保護策略。其實現方式與最大保護模式類似，也是要求所有事務在提交前必須保障redo數據至少在一個standby數據庫可用，不過與之不同的是，如果出現故障導入無法同時寫入standby數據庫redo log，primary數據庫並不會shutdown，而是自動轉爲最高性能模式，等standby數據庫恢復正常之後，它又會再自動轉換成最高可用性模式。
最大保護及最高可用性需要至少一個standby數據庫redo數據被同步寫入。三種模式都需要指定LOG_ARCHIVE_DEST_n初始化參數。LOG_ARCHIVE_DEST_n很重要，你看着很眼熟是吧，我保證，如果你完完整整學完dataguard，你會對它更熟。
四、Data Guard優點總結
* 災難恢復及高可用性
* 全面的數據保護
* 有效利用系統資源
* 在高可用及高性能之間更加靈活的平衡機制
* 故障自動檢查及解決方案
* 集中的易用的管理模式
* 自動化的角色轉換
經常開篇的灌輸，相信大家已經看的出來，上面這幾條都是形容詞，看看就好，記住更好，跟人窮白活的時候通常能夠用上:)
同一個Data Guard配置包含一個Primary數據庫和最多九個Standby數據庫。Primary的創建就不說了，Standby數據庫初始可以通過primary數據庫的備份創建。一旦創建並配置成standby後，dg負責傳輸primary數據庫redo data到standby數據庫，standby數據庫通過應用接收到的redo data保持與primary數據庫的事務一致。
一、Standby數據庫類型
前章我們簡單介紹了Standby數據庫，並且也知道其通常分爲兩類：物理standby和邏輯standby，同時也簡短的描述了其各自的特點，下面我們就相關方面進行一些稍深入的研究：
1. 物理standby
我們知道物理standby與primary數據庫完全一模一樣(默認情況下，當然也可以不一樣，事無絕對嘛)，Dg通過redo應用維護物理standby數據庫。通常在不應用恢復的時候，可以以read-only模式打開，如果數據庫指定了快速恢復區的話，也可以被臨時性的置爲read-write模式。
* Redo應用
物理standby通過應用歸檔文件或直接從standby系統中通過oracle恢復機制應用redo文件。恢復操作屬於塊對塊的應用(不理解？那就理解成塊複製，將redo中發生了變化的塊複製到standby)。如果正在應用redo，數據庫不能被open。
Redo應用是物理standby的核心，務必要搞清楚其概念和原理，後續將有專門章節介紹。
* Read-only模式
以read-only模式打開後，你可以在standby數據庫執行查詢，或者備份等操作(變相減輕primary數據庫壓力)。此時standby數據庫仍然可以繼續接收redo數據，不過並不會觸發操作，直到數據庫恢復redo應用。也就是說read-only模式時不能執行redo應用，redo應用時數據庫肯定處於未打開狀態。如果需要的話，你可以在兩種狀態間轉換，比如先應用redo,然後read-only，然後切換數據庫狀態再應用redo，呵呵，人生就是循環，數據庫也是一樣。
* Read-write模式
如果以read-write模式打開，則standby數據庫將暫停從primary數據庫接收redo數據，並且暫時失去災難保護的功能。當然，以read-write模式打開也並非一無是處，比如你可能需要臨時調試一些數據，但是又不方便在正式庫操作，那就可以臨時將standby數據庫置爲read-write模式，操作完之後將數據庫閃回到操作前的狀態(閃回之後，Data Guard會自動同步，不需要重建standby)。
* 物理standby特點
* 災難恢復及高可用性
物理standby提供了一個健全而且極高效的災難恢復及高可用性的解決方案。更加易於管理的switchover/failover角色轉換及最更短的計劃內或計劃外停機時間。
* 數據保護
應用物理standby數據庫，Dg能夠確保即使面對無法預料的災害也能夠不丟失數據。前面也提到物理standby是基於塊對塊的複製，因此對象、語句統統無關，primary數據庫上有什麼，物理standby也會有什麼。
* 分擔primary數據庫壓力
通過將一些備份任務、僅查詢的需求轉移到物理standby，可以有效節省primary數據庫的cpu以及i/o資源。
* 提升性能
物理standby所使用的redo應用技術使用最底層的恢復機制，這種機制能夠繞過sql級代碼層，因此效率最高。
2. 邏輯standby
邏輯standby是邏輯上與primary數據庫相同，結構可以不一致。邏輯standby通過sql應用與primary數據庫保持一致，也正因如此，邏輯standby可以以read-write模式打開，你可以在任何時候訪問邏輯standby數據庫。同樣有利也有弊，邏輯standby對於某些數據類型以及一些ddl,dml會有操作上的限制。
* 邏輯standby的特點：
除了上述物理standby中提到的類似災難恢復，高可用性及數據保護等之外，還有下列一些特點：
* 有效的利用standby的硬件資源
除災難恢復外，邏輯standby數據庫還可用於其它業務需求。比如通過在standby數據庫創建額外的索引、物化視圖等提高查詢性能並滿足特定業務需要。又比如創建新的schema(primary數據庫並不存在)然後在這些schema中執行ddl或者dml操作等。
* 分擔primary數據庫壓力
邏輯standby數據庫可以在更新表的時候仍然保持打開狀態，此時這些表可同時用於只讀訪問。這使得邏輯standby數據庫能夠同時用於數據保護和報表操作，從而將主數據庫從那些報表和查詢任務中解脫出來，節約寶貴的 CPU和I/O資源。
* 平滑升級
比如跨版本升級啦，打小補丁啦等等，應該說應用的空間很大，而帶來的風險卻很小(前提是如果你擁有足夠的技術實力。另外雖然物理standby也能夠實現一些升級操作，但如果跨平臺的話恐怕就力不從心，所以此項就不做爲物理standby的特點列出了)，我個人認爲這是一種值的推薦的在線的滾動的平滑的升級方式。
二、Data Guard操作界面(方式)
做爲oracle環境中一項非常重要的特性，oracle提供了多種方式搭建、操作、管理、維護Data Guard配置，比如：
* OEM(Oracle Enterprise Manager)
Orcale EM提供了一個窗口化的管理方式，基本上你只需要點點鼠標就能完全dg的配置管理維護等操作(當然三思仍然堅持一步一步學rman中的觀點，在可能的情況下，儘可能不依賴視窗化的功能，所以這種操作方式不做詳細介紹)，其實質是調用oracle爲dg專門提供的一個管理器：Data Guard Broker來實施管理操作。
* Sqlplus命令行方式
命令行方式的管理，本系列文章中主要採用的方式。不要一聽到命令行就被嚇倒，data guard的管理命令並不多，你只需要在腦袋瓜裏稍微挪出那麼一小點地方用來記憶就可以了。
* DGMGRL(Data Guard broker命令行方式)
就是Data Guard Broker，不過是命令行方式的操作。
* 初始化參數文件
我感覺不能把參數化參數視爲一種操作方式，應該說，在這裏，通過初始化參數，更多是提供更靈活的Data Guard配置。 三、Data Guard的軟硬件需求
1、硬件及操作系統需求
* 同一個Data Gurid配置中的所有oracle數據庫必須運行於相同的平臺。比如inter架構下的32位linux系統可以與inter架構下的32位linux系統組成一組Data Guard。另外，如果服務器都運行於32位的話，64位HP-UX也可以與32位HP-UX組成一組Data Guard。
* 不同服務器的硬件配置可以不同，比如cpu啦，內存啦，存儲設備啦，但是必須確保standby數據庫服務器有足夠的磁盤空間用來接收及應用redo數據。
* primary數據庫和standby數據庫的操作系統必須一致，不過操作系統版本可以略有差異，比如(linux as4&linux as5)，primary數據庫和standby數據庫的目錄路徑也可以不同。
2、軟件需求
* Data Guard是Oracle企業版的一個特性，明白了吧，標準版是不支持地。
* 通過Data Guard的SQL應用，可以實現滾動升級服務器數據庫版本(要求升級前數據庫版本不低於10.1.0.3)。
* 同一個Data Guard配置中所有數據庫初始化參數：COMPATIBLE的值必須相同。
* Primary數據庫必須運行於歸檔模式，並且務必確保在primary數據庫上打開FORCE LOGGING，以避免用戶通過nologging等方式避免寫redo造成對應的操作無法傳輸到standby數據庫。
* Primary和standby數據庫均可應用於單實例或RAC架構下，並且同一個data guard配置可以混合使用邏輯standby和物理standby。
* Primary和standby數據庫可以在同一臺服務器，但需要注意各自的數據文件存放目錄，避免重寫或覆蓋。
* 使用具有sysdba系統權限的用戶管理primary和standby數據庫。
* 建議數據庫必須採用相同的存儲架構。比如存儲採用ASM/OMF的話，那不分primarty或是standby也都需要採用ASM/OMF。
另外還有很重要一點，注意各服務器的時間設置，不要因爲時區/時間設置的不一置造成同步上的。
四、分清某某REDO LOGS(Online Redo Logs, Archived Redo Logs, Standby Redo Logs)
黑多黑多的redo，想必諸位早已暈頭並吐過多次了吧。哎，說實話我描述的時候也很痛苦。這塊涉及到中英文之間的意會。我又不能過度白話，不然看完我這篇文章再看其它相關文檔的相關概念恐怕您都不知道人家在說什麼，這種誤人子弟的事情咱不能幹(也許幹過，但主觀意願上肯定是不想的)，更何況咱也是看各亂雜七雜八文檔被誤過XXXXXXXXXXXXXXXXX次(X=9)，深受其害，堅決不能再讓跟俺一樣受盡苦楚，歷經磨難的DDMM們因爲看俺的文檔被再次一百遍啊一百遍。
但是已到關鍵時刻，此處不把redo混清楚，後頭就得被redo混了，所以這裏我要用盡我全部的口水+目前爲止我所有已成體系的認識再給大家淺顯的白話一回。注：基礎概念僅一筆帶過，水太大了也不好，要響應胡書記號召，書寫節約型筆記。
REDO：中文直譯是重做，與UNDO對應(天哪又扯出個概念，你看不見我看不見我看不見我)。重做什麼？爲什麼要重做呢？首先重做是oracle對操作的處理機制，我們操作數據(增冊改)並非直接反映到數據文件，而是先被記錄(就是online redo log嘍)，等時機合適的時候，再由相應的進程通過讀取redo log將操作提交到數據文件。你是不是想說如果把所有的online redo logs都保存下來，不就相當於擁有了數據庫做過的所有操作了嗎？en，我可以非常負責任的告訴你，你說的對，oracle跟你想到一塊去了並且也將其實現了，這就是archived redo logs，簡稱archive log即歸檔日誌。我們再回來看Data Guard，由於standby數據庫的數據通常都來自於primary數據庫，怎麼來的呢，通過RFS進程接收primary數據庫的redo，保存在本地，就是Standby redo logs嘍，然後standby數據庫的ARCn再將其寫入歸檔，就是standby服務器的archived redo logs。保存之後數據又是怎麼生成的呢，兩種方式，物理standby通過redo應用，邏輯standby通過sql應用，不管是哪種應用，應用的是什麼呢？是redo log中的內容(默認情況下應用archived redo logs，如果打開了實時應用，則直接從standby redo logs中讀取)，至於如何應用，那就是redo應用和sql應用機制的事情了(也許後頭我們會深入聊一聊這個話題，很複雜也很有趣)。
針對上述內容我們試着總結一下，看看能否得出一些結論：
對於primary數據庫和邏輯standby數據庫，online redo log文件肯定是必須的，而對於物理standby是否還需要redo log呢？畢竟物理standby通常不會有寫操作，所以物理standby應該不會生成有redo數據。爲保證數據庫的事務一致性必然需要有歸檔，也就是說不管primary或standby都必須運行於歸檔模式。
standby redo logs是standby數據庫特有的文件(如果配置了的話)，就本身的特點比如文件存儲特性，配置特性等等都與online redo logs非常類似，不過它存儲的是接收自primary數據庫的redo數據，而online redo logs中記錄的是本機中的操作記錄。
上面的描述大家儘可能意會，能夠理解最好，理解不了也沒關係，我始終認爲，只要堅定不移的學習下去，總會水到渠成。下面進入實戰章節，先來個簡單的，創建物理standby。