一步一步學DataGuard(2)基礎之術語再瞭解大概

　　 同一個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模式。

l  Redo應用

物理standby通過應用歸檔檔案或直接從standby系統中通過oracle恢復機制應用redo檔案。恢復操作屬於塊對塊的應用(不理解？那就理解成塊複製，將redo中發生了變化的塊複製到standby)。如果正在應用redo，資料庫不能被open。

Redo應用是物理standby的核心，務必要搞清楚其概念和原理，後續將有專門章節介紹。

l  Read-only模式

以read-only模式開啟後，你可以在standby資料庫執行查詢，或者備份等操作(變相減輕primary資料庫壓力)。此時standby資料庫仍然可以繼續接收redo資料，不過並不會觸發操作，直到資料庫恢復redo應用。也就是說read-only模式時不能執行redo應用，redo應用時資料庫肯定處於未開啟狀態。如果需要的話，你可以在兩種狀態間轉換，比如先應用redo,然後read-only，然後切換資料庫狀態再應用redo，呵呵，人生就是迴圈，資料庫也是一樣。

l  Read-write模式

如果以read-write模式開啟，則standby資料庫將暫停從primary資料庫接收redo資料，並且暫時失去災難保護的功能。當然，以read-write模式開啟也並非一無是處，比如你可能需要臨時除錯一些資料，但是又不方便在正式庫操作，那就可以臨時將standby資料庫置為read-write模式，操作完之後將資料庫閃回到操作前的狀態(閃回之後，Data Guard會自動同步，不需要重建standby)。

l  物理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會有操作上的限制。

l  邏輯standby的特點：

除了上述物理standby中提到的類似災難恢復，高可用性及資料保護等之外，還有下列一些特點：

Ø  有效的利用standby的硬體資源

除災難恢復外，邏輯standby資料庫還可用於其它業務需求。比如通過在standby資料庫建立額外的索引、物化檢視等提高查詢效能並滿足特定業務需要。又比如建立新的schema(primary資料庫並不存在)然後在這些schema中執行ddl或者dml操作等。

Ø  分擔primary資料庫壓力

邏輯standby資料庫可以在更新表的時候仍然保持開啟狀態，此時這些表可同時用於只讀訪問。這使得邏輯standby資料庫能夠同時用於資料保護和報表操作，從而將主資料庫從那些報表和查詢任務中解脫出來，節約寶貴的 CPU和I/O資源。

Ø  平滑升級

比如跨版本升級啦，打小補丁啦等等，應該說應用的空間很大，而帶來的風險卻很小(前提是如果你擁有足夠的技術實力。另外雖然物理standby也能夠實現一些升級操作，但如果跨平臺的話恐怕就力不從心，所以此項就不做為物理standby的特點列出了)，我個人認為這是一種值的推薦的線上的滾動的平滑的升級方式。

二、 Data Guard操作介面(方式)

做為oracle環境中一項非常重要的特性，oracle提供了多種方式搭建、操作、管理、維護Data Guard配置，比如：

l  OEM(Oracle Enterprise Manager)

Orcale EM提供了一個視窗化的管理方式，基本上你只需要點點滑鼠就能完全dg的配置管理維護等操作(當然三思仍然堅持一步一步學rman中的觀點，在可能的情況下，儘可能不依賴視窗化的功能，所以這種操作方式不做詳細介紹)，其實質是呼叫oracle為dg專門提供的一個管理器：Data Guard Broker來實施管理操作。

l  Sqlplus命令列方式

命令列方式的管理，本系列文章中主要採用的方式。不要一聽到命令列就被嚇倒，data guard的管理命令並不多，你只需要在腦袋瓜裡稍微挪出那麼一小點地方用來記憶就可以了。

l  DGMGRL(Data Guard broker命令列方式)

就是Data Guard Broker，不過是命令列方式的操作。

l  初始化引數檔案

我感覺不能把引數化引數視為一種操作方式，應該說，在這裡，通過初始化引數，更多是提供更靈活的Data Guard配置。

三、 Data Guard 的軟硬體需求

1、 硬體及作業系統需求

l  同一個Data Gurid配置中的所有oracle資料庫必須執行於相同的平臺。比如inter架構下的32位linux系統可以與inter架構下的32位linux系統組成一組Data Guard。另外，如果伺服器都執行於32位的話，64位HP-UX也可以與32位HP-UX組成一組Data Guard。

l  不同伺服器的硬體配置可以不同，比如cpu啦，記憶體啦，儲存裝置啦，但是必須確保standby資料庫伺服器有足夠的磁碟空間用來接收及應用redo資料。

l  primary資料庫和standby資料庫的作業系統必須一致，不過作業系統版本可以略有差異，比如(linux as4&linux as5)，primary資料庫和standby資料庫的目錄路徑也可以不同。

2、 軟體需求

l  Data Guard是Oracle企業版的一個特性，明白了吧，標準版是不支援地。

l  通過Data Guard的SQL應用，可以實現滾動升級伺服器資料庫版本(要求升級前資料庫版本不低於10.1.0.3)。

l  同一個Data Guard配置中所有資料庫初始化引數：COMPATIBLE的值必須相同。

l  P rimary資料庫必須執行於歸檔模式 ，並且務必確保在primary資料庫上開啟FORCE LOGGING，以避免使用者通過nologging等方式避免寫redo造成對應的操作無法傳輸到standby資料庫。

l  P rimary和standby資料庫均可應用於單例項或RAC架構下 ，並且同一個data guard配置可以混合使用邏輯standby和物理standby 。

l  Primary和standby資料庫可以在同一臺伺服器，但需要注意各自的資料檔案存放目錄，避免重寫或覆蓋。

l  使用具有sysdba系統許可權的使用者管理primary和standby資料庫。

l  建議資料庫必須採用相同的儲存架構。比如儲存採用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嘍)，等時機合適的時候，再由相應的程式操作提交到資料檔案(詳細可見： 資料寫過程中各項觸發條件及邏輯)。你是不是想說如果把所有的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。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7607759/viewspace-204058/，如需轉載，請註明出處，否則將追究法律責任。