1 Oracle Data Guard 介紹 

Oracle Data Guard概念和管理10g版本2

Oracle Data Guard 確保企業資料的高可用性、資料保護以及災難恢復。Data Guard 提供了一套全面的服務來建立、維護、管理和監控一個或多個備資料庫，使得生產 Oracle 資料庫從災難和資料損壞中得以倖存。Data Guard 維護這些備資料庫作為生產資料庫的事務一致性拷貝。然後，如果生產資料庫因為計劃的或計劃外的中斷而變得不可用。Data Guard 能切換任何備資料為生產角色，從而最小化中斷引起的當機時間。Data Guard 能與傳統的備份、恢復和 cluster 技術一起使用，以提供高階別的資料保護和資料可用性。 

使用Data Guard，管理員能通過將資源密集的備份和報表操作轉移到備系統上，來提高生產資料庫的效能。 

本章包括下面描述Oracle Data Guard 亮點的主題： z Data Guard 配置

 z Data Guard 服務

 z Data Guard Broker

z Data Guard 保護模式

 z Data Guard 和互補技術

 z Data Guard 益處總結 

1.1 Data Guard 配置 

Data Guard 配置包含一個生產資料庫和一個或更多備資料庫。在 Data Guard 配置中的資料庫可以通過 Oracle Net 連線並可以分佈在不同地理位置。資料庫所處位置是沒有限制的，只要它們能互相通訊。例如，你能有一個備資料庫與生產資料庫處於同一系統上，並且有兩個備資料庫在異地的其它系統上。 

你能使用SQL 命令列工具或 Data Guard broker 工具來管理主和備資料庫，包括命令列工具（DGMGRL）和在 Oracle 企業管理器中整合的圖形化使用者工具。 

1.1.1 主資料庫 

Data Guard 配置包含一個生產資料庫，也稱為主資料庫，作為主角。這是大多數你的應用訪問的資料庫。 

主資料庫能是單例項Oracle 資料庫或 Oracle Real Application Clusters 資料庫。 

1.1.2 備資料庫 

備資料庫是主資料庫的一個事務一致性拷貝。使用主資料庫的備份拷貝，你能建立最多九個備資料庫，並將其合併到一個Data Guard 配置中。一旦建立，Data Guard 自動維護每個備資料庫，從主資料庫傳送重做資料然後應用重做到備資料庫。 

類似於主資料庫，備資料庫也可以是單例項Oracle 資料庫或 Oracle Real Application

Clusters 資料庫。 

備資料庫可以是物理備資料庫或邏輯備資料庫： z 物理備資料庫通過基於塊對塊的與主資料庫同樣的磁碟資料庫結構，提供主資料庫的完全一致的物理拷貝。資料庫方案，包括索引，是相同的。物理備資料庫與主資料庫保持同步，通過重做應用，恢復從主資料庫收到的重做資料並將重做應用到物理備資料庫。 

除了災難恢復，物理備資料庫只能在有限的範圍內用於業務目的。 

z 邏輯備資料庫 

包含與生產資料庫同樣的邏輯資訊，儘管資料的物理組織和結構可以是不同的。邏輯備資料庫通過SQL 應用與主資料庫保持同步，其將從主資料庫收到的重做中的資料轉換成 SQL 語句，然後在備資料庫上執行 SQL 語句。 

邏輯備資料庫能用於災難恢復需求以外的業務目的。這允許使用者在任何時間訪問邏輯備資料庫，進行查詢和報表。同時，使用邏輯備資料庫，你能升級Oracle 資料庫軟體和補丁集而幾乎沒有當機時間。這樣，邏輯備資料庫能併發用於資料保護、報表、和資料庫升級。 

1.1.3 配置舉例 

圖1－1 顯示典型的 Data Guard 配置，包含一個主資料庫，傳送重做資料到一個備資料庫。備資料庫異地於主資料庫以用於災難恢復和備份操作。你能配置備資料庫與主資料庫在同一位置。然而，為了災難恢復的目的，Oracle 建議你配置備資料庫在異地位置。 

圖1－1 顯示典型的 Data Guard 配置，在其中重做被應用到備資料庫的備重做日誌檔案中。 

圖1－1 典型的Data Guard 配置 

 

1.2 Data Guard 服務 

下面小節解釋了Data Guard 如何管理重做資料的傳送、重做資料的應用、以及更改資料庫角色： 

z 重做傳輸服務 

控制從生產資料自動傳輸重做資料到一個或更多歸檔的目的地。 

z 日誌應用服務 

在備資料庫上應用重做資料，與主資料庫維持事務同步。重做資料能從歸檔重做日誌檔案，或者，如果允許實時應用，當備重做日誌寫滿時直接從其中應用，而不需要將重做資料首先歸檔到備資料庫。 

z 角色轉換 使用切換或故障轉移操作，從備資料庫更改資料的角色到主資料庫，或者從主資料

庫到備資料庫。 

1.2.1 重做傳輸服務 

重做傳輸服務控制重做資料從生產資料庫自動傳輸到一個或更多歸檔的目的地。重做傳輸服務執行下述任務： z 從主資料庫傳送重做資料到配置中的備系統 z 管理解決歸檔重做日誌檔案由於網路故障中斷的過程 z 強制資料庫保護模式（在 1.4 節中描述） z 自動探測在備系統上丟失或損壞的歸檔重做日誌檔案，並且自動從主資料庫或其它備資料庫檢索替代的歸檔重做日誌檔案 

1.2.2 日誌應用服務 

從主資料庫傳送的重做資料寫到備系統上的備重做日誌檔案中，如果配置了，然後再歸檔到歸檔重做日誌檔案。日誌應用服務自動應用備資料庫上的重做資料，以維持與主資料庫的一致性。其同時也允許對資料的只讀訪問。 

物理與邏輯備資料庫的主要區別是日誌應用服務應用歸檔重做資料的方式： 

z 對於物理備資料庫，Data Guard 使用重做應用技術，使用 Oracle 資料庫的標準恢復技術在備資料庫上應用重做資料，如圖 1－2 所示。 

圖1－2 物理備資料庫的自動更新 

 

z 對於邏輯備資料庫，Data Guard 使用 SQL 應用技術，首先將收到的重做資料轉換為 SQL 語句，然後在邏輯備資料庫執行生成的 SQL 語句，如圖 1－3 所示。 

圖1－3 邏輯備資料庫的自動更新 
 

1.2.3 角色轉換 

Oracle 資料庫操作在兩種角色之一：主或備。使用 Data Guard，你能使用切換或故障轉移操作更改資料庫的角色。 

切換是在主資料庫與其備資料庫之一進行的角色反轉。切換確保不丟失資料。這是對於主系統計劃維護的典型操作。在切換期間，主資料庫轉換到備角色，備資料庫轉換到主角色。轉換髮生不需要重建任何資料庫。 

故障轉移是當主資料庫不可用時。故障轉移只有在主資料庫的災難故障的情況下執行，並且故障轉移導致備資料庫轉換到主角色。資料庫管理員能配置 Data Guard 以確保不丟失資料。 

在本文件中描述的角色轉換是使用SQL 語句手工執行。你也能使用 Oracle Data Guard broker 來簡化角色轉換，並使用 Oracle 企業管理器或 DGMGRL 命令列介面來自動化故障轉移，如 1.3 節所述。 

1.3 Data Guard Broker

Data Guard Broker 是一個分散式的管理構架，用於自動化 Data Guard 配置的建立、維護、和監控。你能使用 Oracle Enterprise Manager 圖形化使用者介面（GUI）或 Data Guard 命令列介面（DGMGRL）來： 

z 建立和允許 Data Guard 配置，包括設定重做傳輸服務和日誌應用服務 z 從配置中的任何系統管理整個 Data Guard 配置 

z 管理和監控包含 Real Application Clusters 主或備資料庫的 Data Guard 配置 

z 通過允許你使用 Oracle 企業管理器中的單次點選或在 DGMGRL 命令列介面中的單條命令簡化切換和故障轉移 

z 當主資料庫變得不可用時允許快速啟動故障轉移來自動轉移故障。當允許快速啟動故障轉移時，由 Data Guard broker 決定是否需要故障轉移，並自動啟動故障轉移到指定的目標備資料庫，不需要 DBA 的介入並且不丟失資料。 

另外，Oracle 企業管理器自動化及簡化了： 

z 從主資料庫的備份拷貝中建立物理或邏輯備資料庫 

z 新增新的或現有的備資料庫到現有的 Data Guard 配置 

z 監控日誌應用速度，捕獲診斷資訊，以及使用集中化的監控、測試、和效能工具快速發現問題。 

1.3.1 使用 Oracle 企業管理器 

Oracle 企業管理器，也稱為企業管理器，提供了一個基於 web 的介面，用於檢視、監控、和管理Data Guard配置中的主和備資料庫。企業管理器的易於使用的介面結合了broker 的集中管理和 Data Guard 配置的監控，增強了對於高可用性、站點保護、和企業的資料保護的 Data Guard 解決方案。 

從企業管理器中央控制檯，所有的管理操作能在本地或異地執行。你能檢視Oracle 資料庫的主頁，包括主和備資料庫以及例項，建立或新增現有的備資料庫，氣筒和停止例項，監控例項效能，檢視事件，排程作業，以及執行備份和恢復操作。檢視 Oracle Data Guard

Broker 和 Oracle 企業管理器聯機幫助系統。 

圖1－4 顯示了在企業管理器中的 Data Guard 管理概要頁面。 

1.3.2 使用 Data Guard 命令列介面 

Data Guard 命令列介面（DGMGRL）允許你從 DGMGRL 提示符或指令碼中控制和監控 Data Guard 配置。你能使用 DGMGRL 執行大多數所需的行動來管理和監控配置中的資料庫。檢視 Oracle Data Guard Broker 以獲得完整的 DGMGRL 參考資訊和舉例。 

1.4 Data Guard 保護模式 

在一些情況下，業務不允許丟失資料。在另外一些情況下，資料庫的可用性比丟失資料更為重要。一些應用需要最強的資料庫效能並且能容忍丟失少量的資料。下面的描述概述了三種不同的資料保護模式。 

最大保護  這種保護模式確保如果主資料庫故障不會發生資料丟失。要提供這種級別的保護，恢復每個事務所需的重做資料必須在事務提交之前同時寫到本地聯機重做日誌和至少一個備資料庫上的備重做日誌。要確保不發生資料丟失，如果故障導致主資料庫無法寫重做流到至少一個事務一致性備資料庫的備重做日誌時，主資料庫會關閉。 

最大可用性  這種保護模式提供了可能的最高階別的資料保護，而不用與主資料庫的可用性相折衷。與最大保護模式相同，在恢復事務所需的重做寫到本地聯機重做日誌和至少一個事務一致性備資料庫上的備重做日誌之前，事務將不會提交。與最大保護模式不同的是，如果故障導致主資料庫無法寫重做流到異地備重做日誌時，主資料庫不會關閉。替代地，主資料庫以最大效能模式執行直到故障消除，並且解決所有重做日誌檔案中的中斷。當所有中斷解決之後，主資料庫自動繼續以最大可用性模式執行。 

這種模式確保如果主資料庫故障，但是隻有當第二次故障沒有阻止完整的重做資料集從主資料庫傳送到至少一個備資料庫時，不發生資料丟失。 

最大效能  這種保護模式（預設）提供了可能的最高階別的資料保護，而不影響主資料庫的效能。這是通過允許事務在恢復該事務所需重做資料在寫到本地聯機重做日誌後立即提交而實現的。主資料庫的重做資料流也寫到至少一個備資料庫，但是那個重做流相對於建立重做資料的事務是非同步寫的。 

當所用的網路連線有足夠的頻寬，這種模式提供了近似於最大可用性模式的資料保護級別，並且對主資料庫效能的影響最小。 

最大保護和最大可用性模式需要備重做日誌檔案配置在配置中的至少一個備資料庫上。所有三種保護模式需要在LOG_ARCHIVE_DEST_n 初始化引數上指定特定的日誌傳輸屬性以傳送重做資料到至少一個備資料庫。檢視 5.6 節以獲得資料保護模式的完整資訊。

1.5 Data Guard 和互補技術 

Oracle資料庫提供了幾種獨特的技術互補Data Guard確保業務關鍵系統以比使用其中任何單種技術更高階別的可用性和資料保護執行。下面的列表總結了一些 Oracle 高可用性技術： 

z Oracle Real Application Clusters（RAC） 

RAC 允許多個獨立伺服器通過內部連線共享訪問一個 Oracle 資料庫，提供了高可用性、可擴充套件性、和在故障時的冗餘性。RAC 和 Data Guard 一起提供了系統級別、站點級別、和資料級別的保護，導致了高階別的可用性和災難恢復而不丟失資料： 

{ RAC 通過提供從故障的快速和自動恢復來處理系統故障，如節點故障和例項崩潰。其也提供了對應用的增加的可擴充套件性。 

{ Data Guard 通過保持不共享磁碟的主和備資料庫的事務一致性來處理站點故障，允許從站點災難和資料損壞中恢復。 

可能有許多不同的使用RAC 和 Data Guard 的架構，依賴於本地和異地站點的使用以及節點和邏輯與物理備資料庫的結合的使用。檢視附錄 D，“Data Guard 和 Real Application Clusters”和 Oracle 資料庫高可用性概述以獲得 RAC 和 Data Guard 的整合。 

z Flashback 資料庫 

Flashback 資料庫特性提供了從邏輯資料損壞和使用者錯誤中的快速恢復。通過允許你閃回時間點，可能已經被錯誤更改或刪除的前面版本的業務資訊能被再次訪問。這種特性： 

{ 消除了還原備份並前滾更改到錯誤或損壞出現的時間的需求。替代地，

Flashback 資料庫能回滾 Oracle 資料庫到一個前面的時間點，而不用還原資料檔案。 

{ 提供了延遲重做的應用的選項，以保護使用者錯誤或邏輯損壞。因此，備資料庫能近地與主資料庫同步，從而減少了故障轉移和切換的時間。 

{ 避免在故障轉移後完全重建原始主資料庫。故障的主資料庫能閃回到故障轉移前的時間點，並轉換成新的主資料庫的備資料庫。 

檢視Oracle 資料庫備份和恢復高階使用者指南以獲得 Flashback 資料庫的資訊，以及 6.2.2 節以獲得延遲重做資料的應用的資訊。 

z 恢復管理器（RMAN） 

RMAN 是一種 Oracle 工具，簡化了備份、還原、和恢復資料庫檔案。與 Data Guard 相同，RMAN 是一種 Oracle 資料庫的特性，不需要額外的安裝。Data Guard 能很好地與 RMAN 整合，允許你： 

{ 使用恢復管理器 DUPILCATE 命令來從你的主資料庫的備份中建立備資料庫。 { 用物理備資料庫取代生產資料庫來進行備份，減少生產資料庫的負載並允許有效地使用備站點的系統資源。此外，備份能在物理備資料庫在應用重做時進行。 

{ 通過自動刪除用於在執行備份後輸入的歸檔重做日誌檔案，幫助管理歸檔重做日誌檔案。 

檢視附錄 F，“使用恢復管理器建立備資料庫”和 Oracle 資料庫備份和恢復基礎。 

1.6 Data Guard 益處總結 

Data Guard 提供了這些益處： 

z 災難恢復，資料保護，和高可用性 

Data Guard 提供了一個有效的、廣泛的災難恢復及高可用性解決方案。易於管理的切換和故障轉移能力允許角色在主和備資料庫之間轉換，最小化了主資料庫在計劃和非計劃中斷的當機時間。 

z 完全的資料保護 

Data Guard 能確保沒有資料丟失，即使面對無法預料的災難。備資料庫提供了對資料損壞和使用者錯誤的保護。在主資料庫上的儲存級別的物理損壞不會蔓延到備資料庫。類似地，導致主資料庫永久損害的邏輯損壞或使用者錯誤能被解決。最後，重做資料在應用到備資料庫時要驗證。 

z 系統資源的有效使用 

由從主資料庫收到的重做資料更新的備資料庫表，能用於其它任務如備份、報表、總結、和查詢，從而減少了主資料庫用於執行這些任務所需的工作負載，節省了寶貴的CPU 和 I/O 迴圈。在邏輯備資料庫中，使用者能在不是從主資料庫更新的方案的表上執行常規的資料操作。邏輯備資料庫能在表被從主資料庫更新時保持開啟，並且表同時能被只讀訪問。最後，在維護的表上能建立額外的索引和物化檢視，以獲得更好的查詢效能並適合特定的業務需求。 

z 靈活保護資料，平衡可用性與效能需求 

Oracle Data Guard 提供了最大保護、最大可用性、和最大效能模式，以幫助企業平衡資料可用性與系統效能需求。 

z 自動探測和解決中斷 

如果在主和一個或更多備資料庫之間的連線丟失了（例如，由於網路問題），在主資料庫上生成的重做資料無法傳送到那些備資料庫。一旦重新建立連線，Data Guard 能自動探測丟失的歸檔重做日誌檔案（稱之為中斷），然後自動傳輸丟失的歸檔重做日誌到備資料庫。備資料庫與主資料庫同步，不需要 DBA 的手工介入。 

z 集中和簡單的管理 

Data Guard broker 提供了一個圖形化的使用者介面和一個命令列介面來自動化管理和操作在 Data Guard 配置中的跨多個資料庫的任務。Broker 也監控在單個 Data Guard 配置中的所有系統。 

z 與 Oracle 資料庫整合 

Data Guard 是 Oracle 資料庫企業版中的一個特性，不需要單獨地安裝。 

z 自動角色轉換 

當允許快速啟動故障轉移時，在主站點災難的情況下，Data Guard broker 自動故障轉移到一個同步的備站點上，不需要 DBA 的介入。另外，角色轉換自動通知應用。 

2 Data Guard 入門 

Data Guard 配置包含一個主資料庫和最多九個相關的備資料庫。本章描述了 Data Guard 入門的下述考慮： z 備資料庫型別 

z 管理 Data Guard 配置的使用者介面 

z Data Guard 操作的先決條件 z 備資料庫目錄結構考慮 z 聯機重做日誌、歸檔重做日誌、和備重做日誌 

2.1 備資料庫型別 

備資料庫是一個 Oracle 生產資料庫的事務一致性拷貝，初始從主資料庫的備份拷貝建立。一旦建立並配置備資料庫後，Data Guard 通過傳輸主資料庫重做資料到備系統自動維護備資料庫，在那裡重做資料應用到備資料庫。 

備資料庫可用是兩種型別之一：物理備資料庫或邏輯備資料庫。如果需要，任何一種型別的備資料能承擔主資料庫的角色並接管生產過程。Data Guard 配置能包括物理備資料庫，邏輯備資料庫，或兩種型別的組合。 

2.1.1 物理備資料庫 

以基於塊對塊的與主資料庫同樣的磁碟資料庫結構，物理備資料庫物理等同於主資料庫。資料庫方案、包括索引，是同樣的。 

Data Guard 通過執行重做應用，維護物理備資料庫。當沒有執行恢復的時候，物理備資料庫能以只讀模式開啟，或者如果允許 Flashback 資料庫則可以臨時以讀/寫模式開啟。 

z 重做應用 

物理備資料庫通過使用Oracle 恢復機制，從歸檔重做日誌檔案或直接從備系統上的備重做日誌檔案應用重做資料來維護。恢復操作使用資料塊地址應用重做塊中的更改到資料塊中。資料庫在應用重做時不能開啟。 

z 只讀開啟 

物理備資料庫能以只讀模式開啟，使得你能在資料庫上執行查詢。當以只讀模式開啟時，備資料庫能繼續接受重做資料，但是從日誌檔案的重做資料的應用會延遲，直到資料庫繼續重做應用。 

雖然物理備資料庫不能在同一時間重做應用和以只讀模式開啟，但是你能在兩者之間切換。例如，你能執行重做應用，然後以只讀模式開啟以執行報表應用，再將其改回以執行重做應用任何未應用的歸檔重做日誌檔案。你能在必要時重複這個迴圈，在重做應用和只讀之間切換。 

物理備資料庫可用於執行備份。此外，物理備資料庫將繼續接受重做資料，即使歸檔重做日誌檔案或備重做日誌檔案沒有在那個時刻被應用。 

z 讀/寫開啟 

為了諸如建立一個克隆資料庫或讀/寫報表的目的，物理備資料庫也能為讀/寫訪問開啟。當以讀/寫模式開啟時，備資料庫不會從主資料庫接受重做資料並且無法提供災難保護。 

物理備資料庫能臨時地以讀/寫模式開啟，以用於開發、報表、或測試目的，然後閃回到過去的點以回覆到物理備資料庫。當資料庫閃回之後，Data Guard 自動同步備資料庫與主資料庫，而不需要從主資料庫的備份拷貝重建物理備資料庫。 

物理備資料庫的益處 

物理備資料庫提供以下益處： z 災難回覆和高可用性 

物理備資料庫提供了強壯的和有效的災難回覆以及高可用性解決方案。易於管理的切換和故障轉移能力允許在主和物理備資料庫之間容易地進行角色轉換，最小化主資料庫由於計劃的或計劃外的斷電而導致的當機時間。 

z 資料保護 使用物理備資料庫，Data Guard 能確保沒有資料丟失，即使面對不可預見的災難。

物理備資料庫支援主資料庫能支援的所有資料型別和所有DDL 和 DML 操作。其同時提供了對資料損壞和使用者錯誤的保護。在主資料庫上的儲存級別的物理損壞不會蔓延到備資料庫。類似地，造成主資料庫永久損害的邏輯損壞或使用者錯誤也能被解決。最後，重做資料在應用到備資料庫時要驗證。 

z 減少主資料庫的工作負載 

Oracle 回覆管理器（RMAN）能使用物理備資料庫進行非負載備份，從而節省了主資料庫的寶貴 CPU 和 I/O 迴圈。物理備資料庫也能以只讀模式開啟，用於報表和查詢。 

z 效能 物理備資料庫使用的重做應用技術使用低階別的恢復機制應用更改，繞過了所有

SQL 級別程式碼層；因此，這是應用海量重做資料最有效的機制。 

2.1.2 邏輯備資料庫 

邏輯備資料庫最初建立為主資料庫的等同拷貝，但是以後能更改為不同的結構。邏輯備資料庫通過執行SQL 語句來更新。這允許使用者在任何時間訪問備資料庫進行查詢和報表。這樣，邏輯備資料庫能併發用於資料保護和報表操作。 

Data Guard 通過轉換日誌檔案中的資料到 SQL 語句然後在邏輯備資料庫上執行 SQL 語句，自動應用從歸檔重做日誌檔案或備重做日誌檔案中的資訊到邏輯備資料庫。因為邏輯備資料庫是使用 SQL 語句更新的，其必須保持開啟。雖然邏輯備資料庫是以讀/寫模式開啟的，但是用於重新生成 SQL 的目標表只能用於只讀操作。當那些表被更新時，他們能同時用於其它任務如報表、統計、和查詢。此外，這些任務能通過在維護表上建立額外的索引和物化檢視進行優化。 

邏輯備資料庫在資料型別、表的型別、和DDL 與 DML 操作型別上有一些限制。4.1.1 節描述了不支援的資料型別和表的儲存屬性。 

邏輯備資料庫的益處 

邏輯備資料庫提供了與物理備資料類似的災難恢復，高可用性，和資料保護益處。它同時還提供下述專門的益處： 

z 備硬體資源的有效利用邏輯備資料庫能用於災難恢復需求以外的其它業務用途。它能在 Data Guard 配置中保護的資料庫方案之上主動建立額外的方案，並且使用者能在任何時間對這些方案執行正常的 DDL 或 DML 操作。因為由 Data Guard 保護的邏輯備表能儲存在主資料庫以外的不同物理層次，所以能建立額外的索引和物化檢視以提高查詢效能並滿足特定的業務需求。 

z 減少主資料庫的工作負載 

邏輯備資料庫能在表被主資料庫更新的同時保持開啟，並且這些表同時可用於讀訪問。這使得邏輯備資料庫是進行查詢、統計、和報表活動的極好選擇，從而減少了主資料庫執行這些任務的負載並節省了寶貴的CPU 和 I/O 迴圈。 

2.2 管理 Data Guard 配置的使用者介面 

你能使用下述介面來配置、實施、和管理Data Guard 配置： z Oracle 企業管理器 

企業管理器提供了一個Data Guard broker 的 GUI 介面，能自動化許多工，包括建立、配置、和監控 Data Guard 環境。檢視 Oracle Data Guard Broker 和 Oracle 企業管理器聯機幫助以獲得 GUI 及其嚮導相關的資訊。 

z SQL*Plus 命令列介面 

個別SQL*Plus 語句使用 STANDBY 關鍵詞來指定備資料庫上的操作。其它 SQL 語句不包含備－特定語法，但是它們對於在備資料庫上執行操作是有用的。檢視第 15 章以獲得相關語句的列表。 

z 初始化引數 

個別初始化引數用於定義Data Guard 環境。檢視第 13 章以獲得相關初始化引數的列表。 

z Data Guard broker 命令列介面（DGMGRL） 

DGMGRL 命令列介面是使用 Oracle 企業管理器的替代選項。如果你想從批處理程式或指令碼使用 broker 來管理 Data Guard 配置，DGMGRL 命令列介面是很有用的。檢視

Oracle Data Guard Broker 以獲得完整資訊。 

2.3 Data Guard 操作的先決條件 

下面小節描述了使用Data Guard 的操作需求： z 硬體和作業系統需求 z Oracle 軟體需求 

2.3.1 硬體和作業系統需求 

下面列表描述了使用Data Guard 的硬體和作業系統需求： 

z Data Guard 配置中的所有成員必須執行在同一平臺建立的 Oracle 映像上。 

例如，這意味著在Intel 系統上的 32 位 Linux 上的主資料庫的 Data Guard 配置可以有配置在 Intel 系統上的 32 位 Linux 上的備資料庫。然而，在 64 位 HP-UX 系統上的主資料庫也能配置在 32 位 HP-UX 系統上的備資料庫，只要兩個伺服器都執行 32 位的映像。 

z 主和備系統的硬體（例如，CPU 的數量、記憶體大小、儲存配置）可以是不同的。 

如果備系統比主系統要小，你可能必須限制在切換或故障轉移後備系統上的工作量。備系統必須有足夠的可用資源來接收和應用所有從主資料庫來的重做資料。邏輯

備資料庫需要額外的資源以轉換重做資料為SQL 語句並在邏輯備資料庫上執行 SQL。 

z 在主和備位置執行的作業系統必須是相同的，但是作業系統版本不需要一樣。另外，備資料庫能使用與主資料庫不同的目錄結構。 

2.3.2 Oracle 軟體需求 

下面列表描述了使用Data Guard 的 Oracle 軟體需求： 

z Oracle Data Guard 只是作為 Oracle 資料庫企業版的一個特性。在 Oracle 資料庫標準版中沒有這個特性。著意味著在 Data Guard 配置中必須在主資料庫和所有備資料庫上必須安裝同樣版本的 Oracle 資料庫企業版。 

注： 

可以使用執行Oracle 資料庫標準版的資料庫來模擬備資料庫環境。你能通過使用作業系統拷貝工具或自定義指令碼定時從一個資料到另一個傳送歸檔重做日誌檔案，手工傳送歸檔重做日誌檔案。後果是這種配置無法提供 Data Guard 所具有的易於使用、易於管理、高效能、和災難恢復能力。 

z 使用 Data Guard SQL 應用，你將能夠執行 Oracle 資料庫軟體的滾動升級，從補丁集版本 n（最低地，這必須是版本 10.1.0.3）到下面的資料庫 10.1.0.(n+1)補丁集版本。在滾動升級期間，你能在升級的同時在主和邏輯備資料上執行不同版本的

Oracle 資料庫，一次升級一個。要獲得完整的資訊，檢視第 11 章，“使用 SQL 應用來升級 Oracle 資料庫”和應用 Oracle 資料庫 10g 補丁集版本的自述檔案。 

z 在 Data Guard 配置中所有資料庫上的 COMPATIBLE 初始化引數必須設為同樣的值。 

z 如果你當前在 Oracle8i 資料庫軟體上執行 Oracle Data Guard，檢視 Oracle 資料庫升級指南以獲得升級 Oracle Data Guard 的完整資訊。 

z 主資料庫必須執行在 ARCHIVELOG 模式。檢視 Oracle 資料庫管理員指南以獲得更多資訊。 

z 主資料庫可以是單例項資料庫或多例項 Real Application Clusters 資料庫。備資料庫可以是單例項資料庫或多例項 Real Application Clusters（RAC）資料庫，並且這些備資料庫可以是物理和邏輯型別的混合。檢視 Oracle 資料庫高可用性概述以獲得更多配置和使用 Oracle Data Guard 與 RAC 的資訊。 

z 每個主資料庫和備資料庫必須有自己的控制檔案。 

z 如果備資料庫與主資料庫位於同樣的系統上，備資料庫的歸檔目錄必須使用與主資料庫不同的目錄結構。否則，備資料庫可能覆蓋主資料庫的檔案。 

z 要保護在主資料庫上的不記日誌的直接寫，無法傳送到備資料庫，在執行用於建立備資料庫的資料檔案備份之前在主資料庫上開啟 FORCE LOGGING。只要需要備資料庫就保持資料庫在 FORCE LOGGING 模式。 

z 你用於管理主和備資料庫例項的使用者帳戶必須有 SYSDBA 系統許可權。 

Oracle 建議當你在 Data Guard 配置中設定 Oracle 自動儲存管理（ASM）和 Oracle 管理檔案（OMF）時，必須在主和備資料庫上對稱地設定。就是說，如果在 Data Guard 配置中的任何資料庫使用 ASM、OMF、或兩者都，則在配置中的每個資料庫都必須相應地使用 ASM、OMF、或兩者都。檢視在 12.12 節中的場景以獲得更多資訊。 

注： 

    因為一些執行包括基於時間的資料更新的應用無法處理從多個時區輸入的資料，所以考慮設定主與遠端備系統的時區相一致，以確保在角色轉換之後維持記錄的時間順序。 

2.4 備資料庫目錄結構考慮 

不同備資料庫的目錄結構是很重要的，因為它決定備資料檔案、歸檔重做日誌檔案、和備重做日誌檔案的路徑名稱。如果可能，主和備系統上的資料檔案、日誌檔案、和控制檔案應該擁有同樣的名字和路徑名稱，並且使用Optimal Flexible Architecture（OFA）命名協定。在備資料庫上的歸檔目錄在站點之間也應該是同樣的，包括大小和結構。這種策略允許其它操作如備份、切換、和故障轉移執行同樣的步驟集合，減少維護的複雜性。 

否則，你必須設定檔名轉換引數（如表 2－1 中所示）或者重新命名資料檔案。不過，如果你需要使用不同目錄結構的系統或將備和主資料庫放在同一系統上，你能這麼做以最小化額外的管理。 

在圖 2－1 中舉例說明了三種基本的配置選項。這些包括： 

z 備資料庫與主資料庫處於同一系統上，並使用與主系統不同的目錄結構。這在圖 2

－1 中舉例為 Standby1。 

如果你有備資料庫在與主資料庫相同的系統上，你必須使用不同的目錄結構。否則，備資料庫會檢視覆蓋主資料庫的檔案。 

z 在分離系統上的備資料庫使用與主系統相同的目錄結構。這在圖 2－1 中舉例為

Standby2。這是建議的模式。 

z 在分離系統上的備資料庫使用與主系統不同的目錄結構。這在圖 2－1 中舉例為

Standby3。 

注： 

    如果在 Data Guard 配置中的任何資料庫使用 ASM、OMF、或兩者都，則在配置中的每個資料庫應該相應地使用 ASM、OMF、或兩者都。檢視第 12 章以獲得如何在 Data Guard 配置中設定 OMF 的場景描述。 

表2－1 備資料庫位置和目錄選項 

2.5 聯機重做日誌、歸檔重做日誌、和備重做日誌 

Data Guard 恢復操作的最關鍵結構是聯機重做日誌、歸檔重做日誌、和備重做日誌。從主資料庫傳送的重做資料由備系統上的遠端檔案服務（RFS）程式接收，RFS 程式寫重做資料到歸檔日誌檔案或備重做日誌檔案中。重做資料可以在重做寫到歸檔重做日誌檔案或備重做日誌檔案之後應用，或者，如果允許實時應用的話，當備重做日誌檔案寫滿後直接應用。 

本文件假設你已經理解聯機重做日誌和歸檔重做日誌之後的概念。2.5.1 節通過提供了 Data Guard 配置相關的資訊補充了基本概念。2.5.2 節提供了使用備重做日誌檔案的詳細資訊。 

檢視Oracle 資料庫管理員指南以獲得更多重做日誌和歸檔日誌的資訊，並且 6.2.1 節提供了實時應用的資訊。 

2.5.1 聯機重做日誌和歸檔重做日誌 

重做的傳送是維護主和備資料庫的事務一致性所必須的。聯機重做日誌和歸檔重做日誌在Data Guard 環境中是需要的： z 聯機重做日誌 

Oracle 主資料庫和邏輯備資料庫的每個例項都有聯機重做日誌以保護例項故障情況下的資料庫。物理備資料庫不使用聯機重做日誌，因為物理備資料庫不開啟用於讀/ 寫 I/O。不允許對物理備資料庫進行更高並且不會生成新的重做資料。 

z 歸檔重做日誌 

歸檔重做日誌是必須的，因為歸檔是用於使備資料庫與主資料庫保持事務一致性的方法。主資料庫、以及物理和邏輯備資料庫都使用歸檔重做日誌。Oracle 資料庫預設設定以 ARCHIVELOG 模式執行，所以歸檔（ARCn）程式自動拷貝每個寫滿的聯機重做日誌檔案到一個或更多歸檔重做日誌檔案。 不像物理備資料庫，邏輯備資料庫是開啟的資料庫，能生成日誌資料並有多個日

志檔案，包括聯機重做日誌檔案、歸檔重做日誌檔案、和備重做日誌檔案（如果配置）。 

聯機重做日誌檔案的大小和日誌切換的頻率都能影響主站點上歸檔重做日誌檔案的生成。Oracle 資料庫高可用性概述提供了日誌組大小的推薦值。 

Oracle 資料庫在每次日誌切換時會檢視進行檢查點。因此，如果聯機重做日誌檔案的尺寸太小了，頻繁的日誌切換會導致頻繁的檢查點並且負面影響備資料庫的系統效能。 

同時檢視： 

    Oracle 資料庫管理員指南以獲得配置重做日誌、歸檔日誌、和日誌組的更多細節。 

2.5.2 備重做日誌 

備重做日誌類似與聯機重做日誌，除了備重做日誌是用於儲存從其它資料庫接收的重做資料。 

如果你希望實施下述，則需要備重做日誌： z 資料保護的最大保護和最大可用性級別（在 1.4 節中描述，在 5.6 節中詳述） z 實時應用（在 6.2 節中描述） z 級聯目標（在附錄 E 中描述） 

備重做日誌提供了一些優點： 

z 備重做日誌檔案能存放在裸裝置上，這在主與備資料庫都處於 Real Application

Clusters 環境中時很重要。 

z 備重做日誌檔案能使用多個成員進行多重，提高歸檔重做日誌檔案的可靠性。 

z 在故障轉移期間，Data Guard 能從備重做日誌檔案比單獨重歸檔重做日誌檔案恢復和應用更多的重做資料。 

z 在主資料庫上的歸檔（ARCn）程式或日誌寫（LGWR）程式能直接傳送資料到遠端備重做日誌檔案，潛在地消除了註冊部分歸檔重做日誌檔案的需求（例如，在備資料庫崩潰後的恢復）。檢視第 5 章以獲得更多資訊。 

3.1.3 節描述瞭如何配置備重做日誌檔案。 

3 建立物理備資料庫 

本章逐步指導你建立物理備資料庫。它包括下述主要主題： z 為備資料庫建立準備主資料庫 z 建立物理備資料庫的逐步指導 z 建立後的步驟 

在本章中描述的步驟以最高效能模式配置備資料庫，這是預設的資料保護模式。第 5 章提供了配置不同資料保護模式的相關資訊。在本章中的討論假設你在伺服器引數檔案

（SPFILE）中指定了初始化引數，替代了文字初始化引數檔案（PFILE）。 

同時檢視： z Oracle 資料庫管理員指南以獲得建立和使用伺服器引數檔案相關資訊 

z Oracle Data Guard Broker 和企業管理器聯機幫助系統以獲得使用圖形使用者介面自動建立物理備資料庫相關資訊 

3.1 為備資料庫建立準備主資料庫 

在你建立備資料庫之前，你必須首先確保正確地配置好主資料庫。 

表3－1 提供了你在主資料庫上執行的為物理備資料庫建立準備的任務的檢查列表。每小節還有相關參考更詳細地描述任務。 

表3－1 為物理備資料庫建立準備主資料庫 

注： 

    只要執行這些準備任務一次。在你完成這些步驟之後，資料庫就準備好以主資料庫為一個或更多備資料庫服務了。 

3.1.1 允許強制記日誌 

在資料庫建立之後使用下面的SQL 語句將主資料庫置於 FORCE LOGGING 模式： 

SQL> ALTER DATABASE FORCE LOGGING;

這條語句可能需要相當長的時間才能完成，因為它會等待所有未記日誌的直接寫I/O 完成。 

3.1.2 建立口令檔案如果沒有已經存在的口令檔案則建立一個。在Data Guard 配置中的每個資料庫必須使用口令檔案，並且對於 SYS 使用者的口令檔案在每個系統上必須相同，以確保重做資料傳輸成功。檢視 Oracle 資料庫管理員指南。 

3.1.3 配置備重做日誌 

最大保護和最大可用性模式是需要備重做日誌的，並且對於所有資料庫推薦LGWR

ASYNC 傳送模式。Data Guard 從備重做日誌比單獨從歸檔重做日誌檔案能恢復和應用更多重做資料。 

你應該在建立備資料庫的時候，計劃備重做日誌配置並建立所有所需的日誌組和組成

員。為了提高可用性，考慮多重備重做日誌檔案，類似於多重聯機重做日誌檔案的方式。 

執行下述步驟來配置備重做日誌。 

第1 步 確保主和備資料庫上的日誌檔案尺寸是相同的。 

當前備重做日誌檔案的尺寸必須與當前主資料庫聯機重做日誌檔案的尺寸完全符合。例如，如果主資料庫使用兩個聯機重做日誌組，其日誌檔案是200K，則備重做日誌組也應該是 200K 大小的日誌檔案。 

第2 步 確定備重做日誌檔案組的適當數目。 

最少地，配置應該比主資料庫上的聯機重做日誌檔案組的數目多一個備重做日誌檔案組。然而，推薦的備重做日誌檔案組數目依賴於主資料庫上的執行緒數。使用下面的等式來確定備重做日誌檔案組的適當數目。 

（每個執行緒的日誌檔案的最大數目＋1）×執行緒最大數目 

使用這個等式減少了主例項的日誌寫（LGWR）程式因為在備資料庫上無法分配備重做日誌檔案而被鎖住的可能性。例如，如果主資料庫每個執行緒有 2 個日誌檔案，並有 2 個執行緒，則在備資料庫上需要有 6 個備重做日誌檔案組。 

注： 

    邏輯備資料庫根據工作負載可能需要更多的備重做日誌檔案（或額外的 ARCn 程式）。這是因為邏輯備資料庫也寫聯機重做日誌檔案，這優先於備重做日誌檔案。因此，備重做日誌檔案可能沒有聯機重做日誌檔案歸檔速度快。同樣，檢視 5.7.3.1 節。 

第3 步 檢驗相關資料庫引數和設定。 

檢驗在SQL CREATE DATABASE 語句上的 MAXLOGFILES 和 MAXLOGMEMBERS 子句使用的值，不會限制你能新增的重做日誌檔案組和成員。唯一覆蓋由 MAXLOGFILES 和 MAXLOGMEMBERS 子句指定的限制的方法就是重建主資料庫或控制檔案。 

檢視Oracle 資料庫 SQL 參考和你的作業系統相關 Oracle 文件，以獲得預設的

MAXLOGFILES 和 MAXLOGMEMBERS 子句的有效值。 

第4 步 建立備重做日誌檔案組。 

要建立新的備重做日誌檔案組，你必須擁有ALTER DATABASE 系統許可權。備資料庫開始使用新建立的備重做資料，下一時刻在主資料庫上發生日誌切換。例子 3－1 和例子 3 －2 顯示瞭如何使用 ALTER DATABASE 語句和不同的 ADD STANDBY LOGFILE GROUP 子句建立一個新的備重做日誌檔案組。 

例子3－1 新增一個備重做日誌檔案組到一個指定的執行緒下面的語句新增一個新的備重做日誌檔案組到一個備資料庫，並指派到THREAD 5： SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 5

  2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M; 

THREAD 子句只有在你想新增一個或更多備重做日誌檔案組到指定的主資料庫執行緒。

如果你沒有包括THREAD 子句並且配置使用 Real Application Clusters（RAC），Data Guard 會在執行時當不同 RAC 例項需要時自動指派備重做日誌檔案組到執行緒。 

例子3－2 新增一個備重做日誌檔案組到一個指定的組號 

你也能使用GROUP 子句指定標識組的號碼： 

SQL> ALTER DATABASE ADD STANDBY LOGFILE GROUP 10

  2> ('/oracle/dbs/log1c.rdo','/oracle/dbs/log2c.rdo') SIZE 500M;

使用組號能使得管理備重做日誌檔案組更容易。然而，組號必須在1 到 MAXLOGFILES 子句的值之間。不要跳過日誌檔案組號（就是說，不要編號組為 10、20、30、等等），否則你會使用備資料庫控制檔案中的額外空間。 

注： 

    雖然備重做日誌只有在資料庫執行在備角色時才使用，Oracle 建議你在主資料庫上建立一個備重做日誌，使得主資料庫能快速切換到備角色而不需要額外的 DBA 干涉。考慮使用 Oracle 企業管理器來在你的主和備資料庫上自動配置備重做日誌。 

第5 步 檢驗備重做日誌檔案組已建立 

要檢驗備重做日誌檔案組已建立並正確地執行，在主資料庫上呼叫一個日誌切換，然

後查詢備資料庫上的V$STANDBY_LOG 檢視或 V$LOGFILE 檢視。例如： 

SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM

V$STANDBY_LOG;

GROUP#     THREAD#    SEQUENCE# ARC STATUS     

--------- -------- ---------- --- ----------

         3          1           16 NO   ACTIVE              4          0            0 YES UNASSIGNED

         5          0            0 YES UNASSIGNED

3.1.4 設定主資料庫初始化引數 

在主資料庫上，你定義當資料庫處於主角色時控制重做傳輸服務的初始化引數。當主

資料庫轉換到備角色時，你需要新增額外的引數來控制接收重做資料和日誌應用服務。 

例子3－3 顯示了你在主資料庫上維護的主角色初始化引數，這個例子表現了主資料庫位於 Chicago，一個物理備資料庫位於 Boston 的 Data Guard 配置。在例子 3－3 中所示的引數對於 Chicago 資料庫當它執行在主或備資料庫角色時都是有效的。配置舉例使用下面表中所示的名字： 

例子3－3 主資料庫：主角色初始化引數 

DB_NAME=chicago

DB_UNIQUE_NAME=chicago

LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'

CONTROL_FILES='/arch1/chicago/control1.ctl',

'/arch2/chicago/control2.ctl'

LOG_ARCHIVE_DEST_1=

'LOCATION=/arch1/chicago/ 

  VALID_FOR=(ALL_LOGFILES,ALL_ROLES)

  DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_2=

'SERVICE=boston LGWR ASYNC

  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 

  DB_UNIQUE_NAME=boston'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

LOG_ARCHIVE_FORMAT=%t_%s_%r.arc

LOG_ARCHIVE_MAX_PROCESSES=30

這些引數控制重做傳輸服務如何傳送重做資料到備系統和本地檔案系統上的重做資料

的歸檔。注意到舉例指定了LGWR 程式和非同步（ASYNC）網路傳輸來傳送 LOG_ARCHIVE_DEST_2 初始化引數上的重做資料。這些是推薦的設定並且需要備重做日誌檔案（檢視 3.1.3 節，“配置備重做日誌”）。 

例子3－4 顯示了在主資料庫上額外的備角色初始化引數。這些引數在主資料庫轉換到

備角色時起效果。例子3－4 主資料庫：備角色初始化引數 

FAL_SERVER=boston

FAL_CLIENT=chicago

DB_FILE_NAME_CONVERT='boston','chicago'

LOG_FILE_NAME_CONVERT=

'/arch1/boston/','/arch1/chicago/','/arch2/boston/','/arch2/chica go/' 

STANDBY_FILE_MANAGEMENT=AUTO

如例子 3－4 中所示指定初始化引數設定主資料庫來解決中斷，從新的主資料庫轉換新的資料檔案和日誌檔案路徑名，並在這個資料庫處於備角色時歸檔收到的重做資料。使用上述主和備角色集的初始化引數，在角色轉換後不需要更改任何引數。 

下面表提供了在例子 3－3 和例子 3－4 中所示的每個引數設定相關的簡短解釋。 

新增備資料庫到Data Guard 配置，該配置有執行在最大保護或最大可用性模式的 Real Application Clusters 主資料庫。預設地，LOG_ARCHIVE_CONFIG 引數執行資料庫傳送和接收重做；在角色轉換之後，你可能需要使用 SEND、NOSEND、

RECEIVE、或 NORECEIVE 關鍵詞再次指定這些設定 

個引數將主資料庫的資料檔案路徑名轉換成備資料檔案路徑名。如果備資料庫與主資料庫處於同一系統上或如果資料檔案在備站點上的目錄結構與主站點不同，則需要這個引數。注意這個引數只是用於轉換物理備資料庫的路徑名。這個引數可以指定多對路徑。 

警告：     為可能需要更改的額外引數檢查初始化引數檔案。例如，如果在備資料庫上的目錄位置與在主資料庫上指定的不同，你可能需要更改轉儲目的地引數

（BACKGROUND_DUMP_DEST，CORE_DUMP_DEST，USER_DUMP_DEST）。另外，如果沒有已經存在，你可能必須在備系統上建立目錄。 

3.1.5 允許歸檔 

如果沒有允許歸檔，執行下面的語句將主資料庫置於ARCHIVELOG 模式並允許自動歸檔： 

SQL> SHUTDOWN IMMEDIATE;

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE OPEN;

檢視Oracle 資料庫管理員指南以獲得歸檔相關資訊。 

3.2 建立物理備資料庫的逐步指導 

本節描述了你執行建立物理備資料庫的任務。 

表3－2 提供了你執行建立物理備資料庫的任務和你執行每個任務的資料庫的檢查列表。每個小節還有參考以更詳細地描述任務。 

表3－2 建立物理備資料庫 

3.2.1 建立主資料庫資料檔案的備份拷貝你能使用主資料庫的任何備份拷貝來建立物理備資料庫，只要你有必要的歸檔重做日誌檔案來完全恢復資料庫。Oracle 推薦你使用恢復管理工具（RMAN）。 

檢視Oracle 高可用性體系結構以獲得備份推薦和 Oracle 資料庫備份和恢復高階使用者指南來執行 RMAN 備份操作。 

3.2.2 為備資料庫建立控制檔案 

如果備份過程需要你關閉主資料庫，執行下面的SQL*Plus 語句來啟動主資料庫： 

SQL> STARTUP MOUNT;

然後，為備資料庫建立控制檔案，並開啟主資料庫允許使用者訪問，如下面舉例所示： 

SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/boston.ctl';

SQL> ALTER DATABASE OPEN;

注： 

    對於主和備資料庫你不能使用單個控制檔案。 

3.2.3 為備資料庫準備初始化引數檔案 

執行下面的步驟來建立備初始化引數檔案。 

第1 步 拷貝主資料庫引數檔案到備資料庫。 

從主資料庫使用的伺服器引數檔案（SPFILE）建立一個文字初始化引數檔案；文字初始化引數檔案能拷貝到備位置並修改。例如： 

SQL> CREATE PFILE='/tmp/initboston.ora' FROM SPFILE;

後面，在3.2.5 節，在修改這個檔案以包含適用於物理備資料庫的引數值之後，你將這個檔案轉換回伺服器引數檔案。 

第2 步 在物理備資料庫上設定初始化引數 

雖然在你從主系統拷貝來的文字初始化引數檔案中的大多數初始化引數設定也適用於物理備資料庫，但是需要進行一些修改。 

例子3－5 顯示了備初始化引數檔案中部分，對於物理備資料庫進行的修改。與例子 3 －3 和例子 3－4 中不同的引數值以粗體所示。在例子 3－5 中所示的引數在 boston 資料庫執行於主或備資料庫角色時都是有效的。 

例子3－5 為物理備資料庫修改初始化引數 

.

.

.

DB_NAME=chicago

DB_UNIQUE_NAME=boston

LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,boston)'

CONTROL_FILES='/arch1/boston/control1.ctl',

'/arch2/boston/control2.ctl'

DB_FILE_NAME_CONVERT='chicago','boston' LOG_FILE_NAME_CONVERT='/arch1/chicago/','/arch1/boston/','/arch2/ chicago/','/arch2/boston/' LOG_ARCHIVE_FORMAT=log%t_%s_%r.arc

LOG_ARCHIVE_DEST_1=

'LOCATION=/arch1/boston/

  VALID_FOR=(ALL_LOGFILES,ALL_ROLES) 

  DB_UNIQUE_NAME=boston'

LOG_ARCHIVE_DEST_2=

'SERVICE=chicago LGWR ASYNC

  VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) 

  DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_STATE_2=ENABLE

REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

STANDBY_FILE_MANAGEMENT=AUTO

FAL_SERVER=chicago

FAL_CLIENT=boston

.

.

.

注意該例子假設使用LGWR 程式來傳送重做資料到本地和在 LOG_ARCHIVE_DEST_2

初始化引數上的遠端目的地。另外，確保在主和備資料庫上設定COMPATIBLE 初始化引數為相同值。如果該值不同，

重做傳輸服務可能無法從主資料庫傳送重做資料到備資料庫。在Data Guard 配置中，

COMPATIBLE 必須設為最小值 9.2.0.1.0。然而，如果你想利用新的 Oracle 資料庫 10g 的特性，設定 COMPATIBLE 引數為 10.2.0.0 或更高。 

使用SHOW PARAMETERS命令來檢查沒有其它的引數需要更改總是一個很好的習慣。下面的表提供了在例子 3－5 中所示的與主資料庫不同設定的引數設定的簡要解釋。 

DB_UNIQUE_NAME 為這個資料庫指定唯一的名字。這個名字與資料庫繫結不會更改，即使主和備資料庫交換角色。 

CONTROL_FILES 指定在主資料庫上的控制檔案的路徑名。例子 3－3 顯示瞭如何為兩個控制檔案指定。推薦使用控制檔案的第二個拷貝，使得例項能在拷貝好的控制檔案到壞的控制檔案位置之後很容易地重啟。 

DB_FILE_NAME_CONVERT 在備位置後面指定主資料庫檔案的路徑名和檔名位置。這個引數將主資料庫的資料檔案路徑名轉換成備資料檔案路徑名。如果備資料庫與主資料庫處於同一系統上或如果資料檔案在備站點上的目錄結構與主站點不同，則需要這個引數。 

LOG_FILE_NAME_CONVERT 在備位置後面指定主資料庫聯機重做日誌檔案的位置。這個引數將主資料庫日誌檔案的路徑名轉換成備資料庫上的路徑名。如果備資料庫與主資料庫處於同一系統上或如果資料檔案在備站點上的目錄結構與主站點不同，則需要這個引數。 

LOG_ARCHIVE_DEST_n 指定重做資料歸檔的位置。在例子 3－5 中： 

z LOG_ARCHIVE_DEST_1 歸檔從主資料庫收到的重做資料到/arch1/boston/目錄中的歸檔重做日誌檔案。 

z LOG_ARCHIVE_DEST_2 當前被忽略，因為這個目的地只對主角色有效。如果發生了切換並且這個例項成為主資料庫，則會傳送重做資料到遠端 chicago 目的地。 

注：如果配置了閃回恢復區域（使用DB_RECOVERY_FILE_DEST 初始化引數）並且你沒有使用 LOCATION 屬性顯式配置本地歸檔目的地，Data Guard 自動使用 LOG_ARCHIVE_DEST_10 初始化

引數作為本地歸檔的預設目的地。檢視5.2.3 節以獲得更多資訊。

也檢視第 14 章以獲得完整的 LOG_ARCHIVE_DEST_n 資訊。 

警告：     為可能需要更改的額外引數檢查初始化引數檔案。例如，如果在備資料庫上的目錄位置與在主資料庫上指定的不同，你可能需要更改轉儲目的地引數

（BACKGROUND_DUMP_DEST，CORE_DUMP_DEST，USER_DUMP_DEST）。另外，如果沒有已經存在，你可能必須在備系統上建立目錄。 

3.2.4 從主系統拷貝檔案到備系統 

使用作業系統拷貝工具將下面的二進位制檔案從主系統拷貝到備系統： z 在 3.2.1 節中創的備份資料檔案 z 在 3.2.2 節中建立的備控制檔案 z 在 3.2.3 節中建立的初始化引數 

3.2.5 設定環境以支援備資料庫 

執行下面的步驟以建立一個基於Windows 的服務，建立一個口令檔案，設定 Oracle 網路環境，以及建立一個 SPFILE。 

第1 步 建立一個基於 Windows 的服務。 

如果備系統是執行在基於Windows 的系統上，使用 ORADIM 工具來建立 Windows 服務和口令檔案。例如： 

WINNT> oradim -NEW -SID boston -INTPWD password -STARTMODE manual

檢視Oracle 資料庫 Microsoft Windows(32-Bit)平臺指南以獲得使用 ORADIM 工具的相關資訊。 

第2 步 建立一個口令檔案。 

在Windows 以外的平臺上，建立一個口令檔案，然後為 SYS 使用者設定與在主資料庫上的 SYS 使用者相同的口令。為了成功傳輸重做，在 Data Guard 配置中的每個資料庫上的 SYS 使用者的口令都必須相同。檢視 Oracle 資料庫管理員指南。 

第3 步 為主和備資料庫配置監聽。 

在主和備站點上，使用Oracle 網路管理器為相關資料庫配置監聽。 

要啟動監聽（獲得新的定義），在主和備系統上輸入下面的LSNRCTL 工具命令： 

% lsnrctl stop

% lsnrctl start

檢視Oracle 資料庫網路服務管理員指南。 

第4 步 建立 Oracle 網路服務名。 

在主和備系統上，使用Oracle 網路管理器來為主和備資料庫建立網路服務名，為重做傳輸服務所使用。 

Oracle 網路服務名必須解析一個連線描述符，使用當你為主和備資料庫配置監聽器時指定的同樣的協議、主機地址、埠、和服務。連線描述符也必須指定使用專用伺服器。 

檢視Oracle 資料庫網路服務管理員指南和 Oracle 資料庫管理員指南。 

第5 步 為備資料庫建立一個伺服器引數檔案。 

在一個空閒的備資料庫上，使用SQL CREATE 語句來從步驟 2 中編輯的文字初始化引數檔案，為備資料庫建立一個伺服器引數檔案。例如： 

SQL> CREATE SPFILE FROM PFILE='initboston.ora';

3.2.6 啟動物理備資料庫 

執行下面的步驟來啟動物理備資料庫和重做應用。 

第1 步 啟動物理備資料庫。 

在備資料庫上，執行下面的SQL 語句來啟動和安裝資料庫： 

SQL> STARTUP MOUNT;

第2 步 啟動重做應用。 

在備資料庫上，執行下面的命令來啟動重做應用： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM

SESSION;