DATA GUARD 簡介

DATA GUARD的最主要的功能是冗災。當然根據配置的不同,DATA GUARD還可以具備以下特點：高可用、效能提升、資料保護以及故障恢復等。

    DATA GUARD可以分為物理STANDBY和邏輯STANDBY兩種。二者的最大差別在於，物理STANDBY應用的是主庫的歸檔日誌，而邏輯STANDBY應用的是主庫的歸檔日誌中提取的SQL語句。由於二者這一點的區別，決定了物理STANDBY無論從邏輯結構和物理結構都是和主庫保持一致，而邏輯STANDBY則只需保證邏輯結構一致，且邏輯STANDBY在應用SQL語句的時候，資料庫可以處於開啟的狀態。

    如果從DATA GUARD的保護模式分，可以分為三種不同的保護模式：

    保護最大化：這種模式的配置可以保證主庫和備庫的同步，任何情況下主庫的損毀都不會導致已提交資料的丟失。如果主庫和備庫之間的網路出現問題，或者備庫本身出現問題，都會導致主庫停止資料處理。
 
    可用最大化：這種模式和上面一種類似，也是會保證主庫和備庫的同步，區別在於，當網路或備庫不可用時，主庫仍然可以繼續處理。

    效能最大化：主庫和備庫是非同步的。這種模式可能在主庫出現損毀時，丟失一部分資料。但是這種模式對主庫負荷最小，因此具有最好的效能

=============================================================================================================

Data guard是ORACLE 推出的一種高可用性(HIGH AVAILABLE)的資料庫方案,在8i之前稱之為standby database，從9i開始，正式更名為Data guard，它是在主節點與備用節點間通過日誌同步來保證資料的同步，可以實現快速切換與災難性恢復。Data guard只是在軟體上對資料庫進行設定，並不需要額外購買任何元件能在對主資料庫影響很小的情況下，實現主備資料庫的同步，而主備機的資料差異只在線上日誌部分，所以被不少企業作為了資料容災方案。

ORACLE 從7.3推出standby database，7.3.x-8.0.x 需要手工拷貝所有歸檔日誌並手工同步，從ORACLE815 開始，開始支援多節點複製，並實現了自動同步，但是這種同步是資料非同步模式的，可能引起資料丟失。從ORACLE9i開始，備用伺服器已經換了一種新的稱呼，叫資料保護(DATA GUARD)，在這種模式中，開始支援三種不同的資料保護模式，並開始採用LGWR 對資料的傳送而不是以往的ARCH，而且增加了一個新的後臺程式叫DMON 監控資料的同步，支援多達9個節點的同時複製。從920開始，還開始支援邏輯備用伺服器。

本文通過筆者對公司北京地區製造業客戶Data Guard的使用發展情況來闡述oracle這一新技術在製造業資料庫應用中的推廣普及以及從單純的max performance的physical data guard的資料庫容災保護到邏輯 Data Guard等新特性的增值使用。

說到這邊我們不得不簡單的描述下製造業系統資料庫的使用特性，製造業生產用資料庫前端應用一般以各類ERP,MES及shop floor系統為多，目前我們維護客戶中以MES，shop floor為多，這類生產類的系統一般是24x7不間斷執行，應用以OLTP為主且會定期月結時或實時的run大量的report,在高可用性方面會要求低downtime最好不能超過半小時，資料丟失一般最多容忍也就15分鐘。

縱觀前幾年蘇州地區製造業的Oracle資料庫系統幾乎都是單機執行的資料庫，最多加上Cluster的雙機熱備，但是雙機熱備其實不能真正意思上保障到資料庫系統的安全，該HA只是保障了server故障及維護時的資料庫的高可用性，對oracle database來說沒有任何保障。
                 
這就是利用os cluster或某些第三方的軟體也實現了叢集功能，如ClusterWizard雙機叢集容錯軟體、AFS/2000高可用備援系統等。這些系統一般通過RS232聯機或內部網路聯機做心跳線，檢測主機狀態，一旦發現主機當機，則接管主機的IP，並且重新啟動應用程式，達到減少當機時間的目的。

後來隨著oracle HA技術的發展，standby技術的完善以及oracle database委外服務的盛行，專業顧問服務公司專業技術及理念的注入，讓製造業在database容災方面有了很大的改善，硬體成本的降低各家公司開始在HA 的機制上區域性加入physical data guard的容災功能，此階段的製造業生產系統的資料庫均為cluster + physical Data guard架構這樣既保障了主機維護高可用性又保障了DB損毀對生產造成的影響。另standby db還可以代替主庫備份以分擔備份所消耗的效能。
       
Data Guard執行要求:
1.主機必需執行在歸檔模式下。
2.主備資料庫的版本必須一樣，作業系統必須一樣，版本可不同,主備機可使用不同的目錄結構。
3.主備機必須都要執行在32位或64位下。
4.主庫避免nologing的方式，這樣會導致備機無法與主機同步。
Physical standby database

物理備用機在物理上和主據庫的結構完全一樣。也就是說，物理備機除了control 檔案和主機不一樣以及線上日誌是可選的以外，其他都和主資料庫一樣。物理備機是靠應用主機所產生的歸檔檔案來實現主備的一致。歸檔日誌從主資料庫通過網路傳到備庫上，並在備機上應用傳過來的歸檔檔案，以實現兩臺機的同步。物理備用機有兩種模式：Managed recovery mode歸檔檔案從主資料傳到備用資料庫，log apply services把這些日誌應用到備用資料庫中。Read only mode這種模式可供使用者只讀的運算元據庫，歸檔日誌仍然會從主資料庫傳到備用資料庫，但Log apply services不可以把這些日誌應用到備用資料庫中。
Logical standby database

 除了physical data guard,9i R2又推出logical data guard, 邏輯備用機在邏輯上和主庫一樣，也就是說，兩臺伺服器的表、檢視等對像需要保持一致，對物理結構上則不需要保持一致。邏輯備用機是靠把主機傳過來的歸檔日誌通過logminer解析成SQL語句，並應用到備用機上來進行更新的，與物理備用機不同的是它可以在更新的同時對資料庫進行查詢，這個可以進行近實時(差異一個current redo)資料庫查詢的功能對製造業生產系統的run report應用與其他應用分開以減輕主庫的負擔有很大幫助。就目前來看各企業資料庫的效能瓶頸均在月結或實時的report查詢未與生產應用分開導致階段性的performance較差，logical standby的這種近實時的run report的功能對效能改善有很大的幫助。
但是很大程度上，而logical的方式則是需要把所有的歸檔轉換成SQL語句再在logical standby database上執行它。這會佔用一定的系統資源，如CPU，memory,I/O等，另外一點就是9i的logical standby相對來說bug限制等較多，還有就是不是很穩定，所以很少有企業在生產系統中使用，但是9i R2後幾個patch針對logical DG修正了不少的bug,加上生產系統相對簡單的,較少特殊運用的特性，故logical的近實時查詢功還是有很好的可以用性，再加上專業的規劃，制度化的管理相對來說這種技術還是值得推廣使用的。

值得高興的是在我們的精心準備及規劃下蘇州地區某大型製造業終於成為第一個吃螃蟹的，在正式的生產系統中運用了logical standby,正是這種近實時查詢功能彌補了應用上的不足，解決了原系統I/O嚴重的問題，所有的report均至logical standby 端實時查詢，在功能未受影響的同時，因為不同應用在2個DB內完成所以I/O大大降低，效能得到很大的改善。加上logical standby設計合理，管理上的規範目前該系統上線以來執行穩定。此專案的成功對蘇州地區製造業對此項新技術的廣泛運用有很大推動作用。
             
10g Data Guard

無論是8i的standby還是9i的Data Guard, Physical Standby Database只可以處於兩種狀態:mount和read-only,在處於mount狀態時,可以手動或自動恢復archived logs,但是處於read-only模式時,不能恢復archived logs. logical standby database 也必須是從已收到的archived logs中解析出SQL語句恢復,也就是說,即使無資料丟失,在standby資料庫上,使用者獲得的資料時落後實紀生產資料庫的舊的資料.是近實時的資料(差一個current redo).10g的data guard, logical standby database也支援了standby redo logs的物理結構,允許一個實時恢復的程式與MPR或者LSP程式一起工作,,直接將standby redo logs中剛剛收到的primary資料庫的redo日誌內容恢復到物理或邏輯standby資料庫上面,使得使用者在standby資料庫執行報告的資訊是primary database的實時資訊. 另外新增的實時恢復功能也可使資料庫的switchover或者failover過程的時間大大縮短,系統的高可用效能大大的提高.Flashback Database standby資料庫就可以恢復到一個指定的時間點,避免因為人為的錯誤帶來的資料丟失,加上10G的Data Guard 圖形管理功能進一步完善,管理起來會更容易,EM管理,可使Switchover/failover功能,單擊滑鼠就可以完成.
最後總結下data guard的優點
1.支援所有的DDL和DML語句
2.不管是什麼資料型別、表的型別，任何DDL和DML語句都可以應用在物理備用資料庫上。
3.可以減輕主資料庫的備份壓力
4.standby的中的資料檔案可以用來快速恢復主資料庫的資料檔案
5.邏輯standby可以減輕主資料庫的工作壓力
6.物理standby也可以用只讀來開啟，可以分擔一部分非實時的查詢的工作
7.邏輯standby資料是近實時更新的，而且也可以讓使用者進行查詢操作
8.邏輯standby可以在standby中建立索引和物化檢視以方便使用者的查詢

人們的觀念中,容災所謂的火災,地震之類的災難是乎是很遙遠的.但911後,人們開始對主要的系統制定緊急的計劃.自動化的data guard開始被廣泛的使用起來.加上data guard功能的不斷改進使得這項實用的技術能個逐漸被接受且廣泛的應用起來，從製造業集中的北京各大企業的data guard的應用演變來說這種經濟實用的技術正越來越得到製造業的青睞。

 

====================================================================-
它有無數個名字，有人叫它dg，有人叫它資料衛士，有人叫它data guard，在oracle的各項特性中它有著舉足輕理的地位，它就是(掌聲)......................Oracle Data Guard。而對於我而言，我一定要親切的叫它：DG(注：主要是因為打著方便)。
　　不少未實際接觸過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資料庫的事務一致。

轉貼於：Oracle認證考試_考試大一、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。

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