?
第一部分基礎2之術語再了解大概? 2007.11.29
?
?
??? 同一個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 模式打開，如果數據庫指定了flashback area 的話，也可以被臨時性的置為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 的特點列出了)，我個人認為這是一種值的推薦的在線的滾動的平滑的升級方式。
?
?
二、DataGuard操作界面(方式)
?
??? 做為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 配置。
?
?
三、DataGuard的軟硬件需求
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 數據庫的操作系統必須一致，不過操作系統版本可以略有差異，比如(linuxas4&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。
?
??? 另外還有很重要一點，注意各服務器的時間設置，不要因為時區/時間設置的不一置造成同步上的。
?
四、分清某某REDOLOGS(OnlineRedoLogs,ArchivedRedoLogs,StandbyRedoLogs)
?
??? 黑多黑多的redo，想必諸位早已暈頭并吐過多次了吧。哎，說實話我描述的時候也很痛苦。這塊涉及到中英文之間的意會。我又不能過度白話，不然看完我這篇文章再看其它相關文檔的相關概念恐怕您都不知道人家在說什么，這種誤人子弟的事情咱不能干(也許干過，但主觀意愿上肯定是不想的)，更何況咱也是看各亂雜七雜八文檔被誤過XXXXXXXXXXXXXXXXX 次(X=9)，深受其害，堅決不能再讓跟俺一樣受盡苦楚，歷經磨難的DDMM 們因為看俺的文檔被再次一百遍啊一百遍。
??? 但是已到關鍵時刻，此處不把redo 混清楚，后頭就得被redo 混了，所以這里我要用盡我全部的口水+目前為止我所有已成體系的認識再給大家淺顯的白話一回。注：基礎概念僅一筆帶過，水太大了也不好，要響應胡書記號召，書寫節約型筆記。
?
??? REDO：中文直譯是重做，與UNDO 對應(天哪又扯出個概念，你看不見我看不見我看不見我)。重做什么？為什么要重做呢？首先重做是oracle 對操作的處理機制，我們操作數據(增冊改)并非直接反映到數據文件，而是先被記錄(就是online redo log 嘍)，等時機合適的時候，再由相應的進程操作提交到數據文件(詳細可見：數據寫過程中各項觸發條件及邏輯)。你是不是想說如果把所有的online redo logs 都保存下來，不就相當于擁有了數據庫做過的所有操作了嗎？en，我可以非常負責任的告訴你，你說的對，oracle 跟你想到一塊去了并且也將其實現了，這就是archived redo logs，簡稱archive log 即歸檔日志。我們再回來看Data Guard，由于standby 數據庫的數據通常都來自于primary 數據庫，怎么來的呢，通過RFS 進程接收primary 數據庫的redo，保存在本地，就是Standby redo logs 嘍(arch 模式的話不寫standby redo，直接保存歸檔)，然后standby 數據庫的相關進程讀取接收到的redo 數據，再將其寫入standby 數據庫。保存之后數據又是怎么生成的呢，兩種方式，物理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。
?
?