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運行要求:
主機必需運行在歸檔模式下。
主備數據庫的版本必須一樣，操作系統必須一樣，版本可不同,主備機可使用不同的目錄結構。
主備機必須都要運行在32位或64位下。
主庫避免nologing的方式，這樣會導致備機無法與主機同步。
Physical standby database
物理備用機在物理上和主據庫的結構完全一樣。也就是說，物理備機除了control 文件和主機不一樣以及在線日志是可選的以外，其他都和主數據庫一樣。物理備機是靠應用主機所產生的歸檔文件來實現主備的一致。歸檔日志從主數據庫通過網絡傳到備庫上，並在備機上應用傳過來的歸檔文件，以實現兩台機的同步。 物理備用機有兩種模式：Managed recovery mode歸檔文件從主數據傳到備用數據庫，log apply services把這些日志應用到備用數據庫中。Read only mode這種模式可供用戶只讀的操作數據庫，歸檔日志仍然會從主數據庫傳到備用數據庫，但Log apply services不可以把這些日志應用到備用數據庫中。
