Oracle9i Data Guard 通過使用稱為standby database的數據庫來防止出現數據的災難。它通過將primary database數據庫的重做日志傳到並應用到standby database數據庫來使standby database數據庫與primary database數據庫同步：
可以將重做日志直接從primary database數據庫同步寫到standby database數據庫來完成完全沒有數據損失的災難保護。這會給primary database數據庫的性能帶來一定的性能損失。
可以將歸檔的重做日志從primary database數據庫異步寫到standby database數據庫來使primary database數據庫在極少損失性能的前提下，最小化地減少數據的丟失。
如果重做日志數據到達standby database數據庫後快速τ玫絪tandby database數據庫，則在primary database數據庫出現問題時可以快速地 failover 到standby database數據庫。然而，如果延緩一定時間後再應用重做日志數據，可以避免primary database數據庫的錯誤快速地傳播到standby database數據庫。
如下圖所示，當聯機重做日志在本地歸檔時，它們同時通過 Oracle Net 傳送到了standby database：
數據庫數據保護級別
可以用如下的方式設置standby database數據庫來達到不同的數據庫數據保護級別：
Guaranteed protection：規定在修改主數據庫時，至少有一個備用數據庫有效。假如主（Primary Database）備（Standby Database）之間的連接中斷，Oracle會通過中斷主實例的工作來防止主備數據庫之間的數據的不一致，保證無數據丟失。這種模式對數據庫性能的影響較大。
Instant protection：規定在修改主數據庫時，至少有一個備用數據庫有效。與Guaranteed protection模式不同的是當主備數據庫之間的連接中斷時，允許主備數據庫之間的數據的不一致，並當恢復連接後，解決數據不一致的現象。這種模式對主數據庫的性能有較小的影響。
Rapid protection：主數據庫的修改快速應用在備用數據庫上。會出現數據丟失，但對數據庫性能的影響小。
Delayed protection：主數據庫的修改在延遲一定的時間後應用在備用數據庫上。Rapid protection和Delayed protection模式即使在網絡連接有效時，也允許主數據庫與所有的備用數據庫有數據分歧，數據的丟失量等同於主數據庫聯機重做日志的未歸檔數。這種方式對數據庫性能的影響小。
如何限制數據的丟失量
在primary/standby配置下，所有的歸檔日志被發送到了standby 節點，這使standby 節點的數據保持著更新。但是，如果primary 數據庫意外關閉，聯機的日志將會丟失，因為它們尚未歸檔並發送到standby節點。這使得 primary 和standby 數據庫之間會有一個差異。
Oracle9i 可以用以下的方法來限制這個差異：
DBA可以選擇讓LGWR在將重做日志數據寫到本地磁盤的同時將數據發送到 standby 數據庫。該功能稱為standby零數據丟失（standby zero data loss）。這種方法從本質的角度講提供了遠程重做日志鏡像，但帶來的問題是會極大地損失性能。
設置系統初始化參數ARCHIVE_LAG_TARGET.該參數是一個日志文件開始使用到被發送到standby數據庫的時間間隔。該參數的推薦值是 1800秒（需要注意的是，沒有傳送到 standby 數據庫的已經提交的事務會丟失，因此長的事務會使standby數據庫損失更多的數據）。
Oracle9i Data Guard數據防護與Oracle8 Standby Database的關系Oracle Standby Database 是最經常使用的最有效的災難解決方案。在過去版本的基礎上，Oracle9i 又進行了許多改進，使其功能遠遠超過了基本的災難恢復要求。通過將復雜的工作自動化，並對監控、警告、以及控制機制的大規模改進，Standby Database 和一些新的模塊可以幫助DBA 從錯誤操作、癱瘓、以及其它的災難中恢復（這些災難都可能毀掉數據庫）。另外，通過使用Oracle9i Standby Database，由於硬件和軟件升級造成的宕機時間也可以極度縮短。
Oracle9i 將改進過的8版本的Standby Database功能，與幾個新增加的防止用戶錯誤和癱瘓的模塊合起來稱為Oracle9i Data Guard。
Oracle8 Automated Standby Database 提供了創建和自動維護生產數據庫拷貝的手段來防止災難的發生。Oracle8 Automated Standby Database 具有以下的功能：
當primary database 產生日志後，系統自動用歸檔日志更新standby databases.一個primary database可以最多有4個standby databases.這4個standby databases是與primary database完全一樣的拷貝，它們都可以接管primary database的處理。
Oracle使用標准的恢復方法來將歸檔日志應用到每個standby databases.這些日志的應用是自動的，DBA也可以人工應用這些日志。
primary database 處於打開和活動狀態，而standby database處於恢復或者打開只讀狀態。
大多數的基於Oracle8的災難保護方案包括一個Automated Standby Database.因為Oracle數據庫可以用備份和日志恢復，所以任何應用都可以使用Automated Standby Database.通過Oracle Net傳輸歸檔日志對primary database的性能影響可以忽略不計。
物理的Standby Database和邏輯的Standby Database
Standby Database可以分為物理的Standby Database和邏輯的Standby Database：
物理 Standby Database。物理 Standby Database是Oracle8 Automated Standby Database的Oracle9i版本。它們之間只有一個差異：日志傳輸服務現在是一個分離的模塊，並支持物理standby database和新的邏輯standby database。
物理Standby Database的含義是Standby Database在物理上與primary database 一樣。因為恢復是使用 ROWID 一塊對一塊進行的，Standby Database的數據塊與primary database的數據快一樣。數據庫模式一定是一樣的，且不能以讀/寫的方式打開。
邏輯 Standby Database.邏輯 Standby Database是將歸檔的日志轉化為SQL事務，並將它們應用到打開的Standby Database.因為數據庫是打開的，它在物理上與primary database是不一樣的。然而，從邏輯角度講，Standby Database與primary database是一樣的，因此可以接管primary database的處理。在這種情況下，Standby Database還可以並發地進行其它的工作，例如建立一些與primary database不一樣的索引和物化視圖，完成決策支持等任務。
邏輯 Standby Database 是最重要的數據保護特性。就像物理 standby database一樣，它使用歸檔的日志在standby database上進行處理，在primary database出現問題的情況下也沒有問題。
當選擇使用物理standby database、邏輯standby database、或兩者都用時，要考慮以下一系列的因素。
邏輯standby database可用於兩個目的。當要對邏輯standby database進行改變時，其數據庫可以打開。
邏輯standby database需要DBA更高的技能。
使數據保護極大化的解決方案通常包括邏輯的和物理的standby databases.數據庫Failover和Switchover當主數據庫發生宕機，且不能及時恢復時，Oracle會丟棄主數據庫，將備用數據庫轉變為主數據庫。當 failover之後，備用數據庫變成為主數據庫，從而丟失了備用數據庫的所有能力，也就是說，不能再返回到備用模式。
Failover 有以下特點：
主數據庫offline，備用數據庫online，這種操作由系統和軟件失敗引起。
即使在備用數據庫上應用重做日志，也可能出現數據丟失的現象，除非備用數據庫運行在guaranteed protection模式下。
原主數據庫重新使用時必須reinstantiated（start instance）。
其它的備用數據庫也需reinstantiated.
在主數據庫正常工作時，Oracle 允許 DBA 將主數據庫切換到備用數據庫，此備用數據庫變為主數據庫，而原主數據庫變為備用數據庫。
數據庫的切換可以從主數據庫角色切換到備用數據庫角色，也可從備用數據庫角色切換到主數據庫角色。
Switchover 有以下特點：
故意將主數據庫offline，而將另一備用數據庫online.可以如使用Switchover 功能完成系統的平滑升級工作。
即使在備用數據庫上不應用重做日志，也不會造成數據的丟失。
數據庫不需reinstantiated.這使主數據庫幾乎能立即在備用數據庫上恢復它的功能，因此可經常進行定期維護而不需中斷操作。
Oracle9i Data Guard的一些部件日志傳輸服務（Log Transport Services）
Log Transport Services會被物理的和邏輯的standby database 都用到。它提供的功能包括控制不同的日志傳輸機制、日志傳輸錯誤處理和報告、以及在系統失敗後獲取丟失的日志。使用任何新的日志傳輸模式，數據的保護都可以得到保證。
Oracle9i Data Guard Broker
Data Guard broker提供了對日志傳輸服務的監測、控制、和自動化以及邏輯和物理standby的部件。例如，通過只用一個命令就可以啟動 failover，Data Guard broker可被用於控制主要角色從primary到任何一種standby database轉移的整個過程。用戶可以從2種不同的界面來選擇進行角色轉換，使standby database 從primary database接管生產數據庫的處理。一種選擇是使用新的Oracle Enterprise Manager Data Guard Manager。該圖形用戶界面工具可進行大多的配置工作和操作功能。另一種選擇是一個命令行工具，它提供了基本的監測、改變角色需要的所有命令、以及配置和設置Oracle9i Data Guard環境的能力。
Data Guard Manager 是Oracle Enterprise Manager的一部分。
Oracle9i LogMiner
在 Oracle9i中，LogMiner被做了極大的改進。LogMiner是一個關系工具，DBA可以利用這個工具使用SQL進行讀、分析、和解釋日志文件。LogMiner可以查看聯機的和歸檔的重做日志文件。
LogMiner技術提供了邏輯standby database用到的基礎結構。新的Oracle Enterprise Manager應用Oracle9i LogMiner VIEwer 對已經存在的命令行界面增加了一個圖形操作界面。
災難恢復服務器（Disaster Recovery Server）和DRMON
在當今的電子商務世界中，在互連網上做生意的公司必須有一套一旦出現問題恢復應用和數據庫的策略。每個DBA都應考慮災難恢復以及計劃好的或意外的failover。Disaster Recovery (DR) Server 是幫助DBA達到更高系統可用性的產品的一部分。
Disaster Recovery (DR) Server 從根本上說是一系列松散連接的節點組成。這些節點將物理的和邏輯的standby 方案組合成了一個單獨的易管理的災難恢復解決方案。Disaster Recovery (DR) Server節點在物理分布上是松散的，是通過網絡連接到一起的。每個 DR Server 節點可能是一個簡單的實例，或是一個復雜的系統（例如一個 fail safe cluster）。DR Server 將這些節點作為一個單獨的分布計算系統來管理，從而其可用性會高於單獨的節點。
DR Server 是通過將數據在節點間復制來實現其 failover 系統的。數據庫管理員是這樣來配置服務器的：數據庫和應用在每個節點都激活。其中，一個節點設計成primary節點，其數據庫對應用來說是完全可用的，且其數據以日志的形式復制到其它的節點。其它的節點對primary節點來說是standby節點，它們接收從primary節點發來的日志並改變（從物理上或邏輯上）其數據庫拷貝。
DR Server的standby節點是隨時准備好在primary節點出現問題時進行接管的，從而在primary 節點出現災難後數據和應用對用戶來說仍然可用。
DR Server結構給DBA主要提供了兩點重要功能：
它提供了DBA從邏輯上配置一個 failover 資源組來達到高可用性的方法。
它指定了組成DR Server 本身的基礎計算框架。
