【DG】Oracle_Data_Guard官方直譯

【DG】Oracle Data Guard官方直譯

---

---

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 備數據庫位置和目錄選項 

備系統	目錄結構	結果
與主系統相同	不一樣與主系統 （須要）	z z	你必須設置 DB_UNIQUE_NAME 初始化參數。  你能手工重命名文件或在備數據庫上設置 DB_FILE_NAME_CONVERT 和 LOG_FILE_NAME_CONVERT 初始化參數，以自動化更新備數據庫控制文件中的主數據庫數據文件與歸檔重作日誌文件和備重作日誌文件的路徑名稱。（見 3.1.4 節）
		z	備數據庫不保護摧毀主和備數據庫所在系統的災難，可是它提供了計劃維護的切換能力。
分離系統	與主系統相同	z	你不須要重命名在備數據庫控制文件中的主數據庫文件、歸檔重作日誌文件、和備重作日誌文件，若是你須要新的命名方式（例如，要將文件分佈到不一樣磁盤上），你仍是能夠這麼作。
		z	經過將備數據庫放在分離的物理媒質上，你能保護主數據庫上的數據不受摧毀主系統的災難影響。
分離系統	不一樣與主系統	z	你能夠手工重命名文件或在備數據庫上設置 DB_FILE_NAME_CONVERT 和 LOG_FILE_NAME_CONVERT 初始化參數來自動化重命名數據文件。（見 3.1.4 節）
		z	經過將備數據庫放在分離的物理媒質上，你能保護主數據庫上的數據不受摧毀主系統的災難的影響。

 

 

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 節	容許強制記日誌
3.1.2 節	建立口令文件
3.1.3 節	配置備重作日誌
3.1.4 節	設置主數據庫初始化參數
3.1.5 節	容許歸檔

 

 

注： 

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

 

 

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 數據庫當它運行在主或備數據庫角色時都是有效的。配置舉例使用下面表中所示的名字： 

數據庫	DB_UNIQUE_NAME	Oracle 網絡服務名
主	chicago	chicago
物理備	boston	boston

 

例子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 中所示的每一個參數設置相關的簡短解釋。 

 

參數 推薦設置 

 

DB_NAME	指定一個 8 字符名字。對於全部備數據庫使用相同名字。
DB_UNIQUE_NAME	爲每一個數據庫指定一個惟一的名字。這個名字與數據庫綁定不會更改，即便主和備數據庫交換角色。
LOG_ARCHIVE_CONFIG	在這個參數上指定 DG_CONFIG 屬性，以在 Data Guard 配置中列出主和備數據庫的 DB_UNIQUE_NAME；這容許動態

添加備數據庫到Data Guard 配置，該配置有運行在最大保護或最大可用性模式的 Real Application Clusters 主數據庫。默認地，LOG_ARCHIVE_CONFIG 參數運行數據庫發送和接收重作；在角色轉換以後，你可能須要使用 SEND、NOSEND、

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

CONTROL_FILES	指定在主數據庫上的控制文件的路徑名。例子 3－3 顯示瞭如何爲兩個控制文件指定。推薦使用控制文件的第二個拷貝，使得實例能在拷貝好的控制文件到壞的控制文件位置以後很容易地重啓。
LOG_ARCHIVE_DEST_n	指定重作數據在主和備系統上歸檔的位置。在例子 3－3 中： z LOG_ARCHIVE_DEST_1 歸檔由主數據庫生成的重作數據，從本地聯機重作日誌文件到在 /arch1/chicago/目錄的本地歸檔重作日誌文件。  z LOG_ARCHIVE_DEST_2 只對於主角色有效。這個目的地傳送重作數據到遠程物理備目的地 boston。 注：若是配置了閃回恢復區域（使用 DB_RECOVERY_FILE_DEST 初始化參數）而且你沒有使用 LOCATION 屬性顯式配置本地歸檔目的地，Data Guard 自動使用 LOG_ARCHIVE_DEST_10 初始化參數做爲本地歸檔的默認目的地。查看 5.2.3 節以得到更多信息。也查看第 14 章以得到完整的 LOG_ARCHIVE_DEST_n 信息。
LOG_ARCHIVE_DEST_STATE_n	指定 ENABLE 以運行重作傳輸服務傳送重作數據到指定的目的地。
REMOTE_LOGIN_PASSWORDFILE 在主和備數據庫上爲 SYS 都設置一樣的口令。推薦的設置爲 EXCLUSIVE 或 SHARED。  LOG_ARCHIVE_FORMAT 使用線程（%t），序列號（%s），和重置日誌 ID（%r）指定歸檔重作日誌文件的格式。查看 5.7.1 節以得到其它例子。 LOG_ARCHIVE_MAX_PROCESSES 指定你須要 Oracle 軟件初始化調用歸檔（ARCn）進程的最 =integer 大數目（從 1 到 30）。默認值是 4。查看 5.3.1.2 節以得到 ARCn 處理的更多信息。  FAL_SERVER 指定 FAL 服務器（典型地這是運行在主角色的數據庫）的 Oracle 網絡服務名。當 chicago 數據庫運行在備角色，它使用 boston 數據庫做爲 FAL 服務器，若是 boston 沒法自動發送丟失的日誌文件，能夠從那裏取得（請求）丟失的歸檔重作日誌文件。查看 5.8 節。  FAL_CLIENT 指定 chicago 數據庫的 Oracle 網絡服務名。FAL 服務器 （boston）拷貝丟失的歸檔重作日誌文件到 chicago 備數據庫。查看 5.8 節。  DB_FILE_NAME_CONVERT 在備位置後面指定主數據庫文件的路徑名和文件名位置。這

個參數將主數據庫的數據文件路徑名轉換成備數據文件路徑名。若是備數據庫與主數據庫處於同一系統上或若是數據文件在備站點上的目錄結構與主站點不一樣，則須要這個參數。注意這個參數只是用於轉換物理備數據庫的路徑名。這個參數能夠指定多對路徑。 

LOG_FILE_NAME_CONVERT	在備位置後面指定主數據庫聯機重作日誌文件的位置。這個參數將主數據庫日誌文件的路徑名轉換成備數據庫上的路徑名。若是備數據庫與主數據庫處於同一系統上或若是數據文件在備站點上的目錄結構與主站點不一樣，則須要這個參數。這個參數能夠指定多對路徑。
STANDBY_FILE_MANAGEMENT	設置爲 AUTO 使得當在主數據庫上添加或刪除數據文件時，相應的更改會自動應用到備數據庫。

警告：     爲可能須要更改的額外參數檢查初始化參數文件。例如，若是在備數據庫上的目錄位置與在主數據庫上指定的不一樣，你可能須要更改轉儲目的地參數

（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 節	建立主數據庫數據文件的備份拷貝	主
3.2.2 節	爲備數據庫建立控制文件	主
3.2.3 節	爲備數據庫準備初始化參數文件	主
3.2.4 節	從主系統拷貝文件到備系統	主
3.2.5 節	設置環境以支持備數據庫	備
3.2.6 節	啓動物理備數據庫	備
3.2.7 節	檢驗物理備數據庫正確執行	備

 

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 信息。 

FAL_SERVER	指定 FAL 服務器（典型地這是運行在主角色的數據庫）的 Oracle 網絡服務名。當 boston 數據庫運行在備角色，它使用 chicago 數據庫做爲 FAL 服務器，若是 chicago 沒法自動發送丟失的日誌文件，能夠從那裏取得（請求）丟失的歸檔重作日誌文件。查看 5.8 節。
FAL_CLIENT	指定 boston 數據庫的 Oracle 網絡服務名。FAL 服務器（chicago）拷貝丟失的歸檔重作日誌文件到 boston 備數據庫。查看 5.8 節。

警告：     爲可能須要更改的額外參數檢查初始化參數文件。例如，若是在備數據庫上的目錄位置與在主數據庫上指定的不一樣，你可能須要更改轉儲目的地參數

（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;

 

該語句包含DISCONNECT FROM SESSION 選項，使得重作應用運行在後臺會話中。

查看6.3 節，「應用重作數據到物理備數據庫」以得到更多信息。 

 

第3 步 測試歸檔操做到物理備數據庫。 

在這個例子中，直到日誌切換以後，重作數據到遠程備位置的傳輸纔會發生。默認地，當聯機重作日誌文件滿的時候，日誌切換髮生。要強制日誌切換，使得重作數據當即傳送，在主數據庫上使用下面的ALTER SYSTEM 語句。例如： 

SQL> ALTER SYSTEM SWITCH LOGFILE;

 

3.2.7 檢驗物理備數據庫正確執行 

一旦你建立物理備數據庫並設立重作傳輸服務，你可能須要檢查數據庫更改爲功地被

從主數據庫傳送到備數據庫。要在備數據庫上看到接收到重作數據，你首先應該在備數據庫上確認現有的歸檔重作

日誌文件，在主數據庫上強制日誌切換並歸檔一些聯機重作日誌文件，而後再次檢查備數據庫。下面的步驟顯示如何執行這些任務。 

 

第1 步 確認現有的歸檔重作日誌文件。 

在備數據庫上，查詢V$ARCHIVED_LOG 視圖以確認歸檔重作日誌中現有的文件。例

如： 

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

2 FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

 

SEQUENCE# FIRST_TIME           NEXT_TIME

---------- ------------------ ------------------            8 11-JUL-02 17:50:45 11-JUL-02 17:50:53

9 11-JUL-02 17:50:53 11-JUL-02 17:50:58

10 11-JUL-02 17:50:58 11-JUL-02 17:51:03

 

3 rows selected.

 

第2 步 強制日誌切換以歸檔當前的聯機重作日誌文件。 

打開主數據庫，執行ALTER SYSTEM SWITCH LOGFILE 語句以強制日誌切換並歸檔

當前聯機重作日誌文件組： 

SQL> ALTER SYSTEM SWITCH LOGFILE;

 

第3 步 在備數據庫上檢查新的重作數據已歸檔。 

在備數據庫上，查詢V$ARCHIVED_LOG 視圖來檢查重作數據已收到並歸檔到被數據

庫： 

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME

  2>  FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;

 

SEQUENCE# FIRST_TIME         NEXT_TIME

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

8 11-JUL-02 17:50:45 11-JUL-02 17:50:53

9 11-JUL-02 17:50:53 11-JUL-02 17:50:58

10 11-JUL-02 17:50:58 11-JUL-02 17:51:03

11 11-JUL-02 17:51:03 11-JUL-02 18:34:11 4 rows selected.

 

歸檔的重作日誌文件如今能夠應用到物理被數據庫上了。 

 

第4 步 檢查新歸檔的重作日誌文件已應用。 

在備數據庫上，查詢V$ARCHIVED_LOG 視圖來檢查歸檔重作日誌文件已應用。 

SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG

  2  ORDER BY SEQUENCE#;

 

SEQUENCE# APP

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

8 YES

9 YES

10 YES

11 YES

 

4 rows selected.

 

查看5.9.1 節，「監控日誌文件歸檔信息」和 8.5.4 節，「監控在物理備數據庫上的日誌應用服務」來檢查重作傳輸服務和日誌應用服務正確工做。 

 

 

3.3 建立後的步驟 

在這個時候，物理備數據庫已運行並可以提供最大性能級別的數據保護。下面的列表描述了你能在物理備數據庫上進行的額外準備： z 升級數據包含模式 

Data Guard 配置初始化是設置爲最大性能模式（默認）。查看 5.6 節以得到數據保護模式和如何升級或降級當前保護模式的相關信息。 

z 容許 Flashback 數據庫 

Flashback 數據庫消除了在故障轉移以後重建主數據庫的需求。Flashback 數據庫容許你將數據庫返回到最近的過去時間的狀態，比傳統的基於時間點的恢復要快不少，由於它不須要從備份中恢復數據文件，也不須要大量地應用重作數據。你能在主數據庫上、備數據庫上、或二者都容許 Flashback 數據庫。查看 12.4 節和 12.5 節以得到顯示如何在 Data Guard 環境中使用 Flashback 數據庫的場景。同時，查看 Oracle 數據庫備份和恢復高級用戶指南以得到 Flashback 數據庫的更多相關信息。 

 

4 建立邏輯備數據庫 

 

本章逐步指導你建立邏輯備數據庫。它包括下述主要主題： z 建立邏輯備數據庫的先決條件 z 建立邏輯備數據庫的逐步指導 z 建立後的步驟 

 

 

同時查看： z Oracle 數據庫管理員指南以得到建立和使用服務器參數文件相關信息 

z Oracle Data Guard Broker 和 Oracle 企業管理器聯機幫助系統以得到使用圖形用戶界面自動建立邏輯備數據庫相關信息 

 

 

 

4.1 建立邏輯備數據庫的先決條件 

在你建立邏輯備數據庫以前，你必須首先確保正確地配置好主數據庫。表 4－1 提供了你在主數據庫上執行的爲邏輯備數據庫建立準備的任務的檢查列表。每小節還有相關參考更詳細地描述任務。 

表4－1 爲邏輯備數據庫建立準備主數據庫 

參考	任務
4.1.1 節	肯定對於表的數據類型和存儲屬性的支持
4.1.2 節	確保在主數據庫中的錶行能被惟一標識

 

4.1.1 肯定對於表的數據類型和存儲屬性的支持 

在設置邏輯備數據庫以前，確保邏輯備數據庫能維護在你的主數據庫中的數據類型和表。查看附錄 C 以得到數據類型和存儲類型考慮的完整列表。 

 

4.1.2 確保在主數據庫中的錶行能被惟一標識 

在邏輯備數據庫中的物理組織不一樣於主數據庫，即便邏輯備數據庫是從主數據庫的備份拷貝中建立。這樣，由主數據庫生成的重作記錄中包含的ROWID 沒法用於標識在邏輯備數據庫中相應的行。 

Oracle 使用主鍵或惟一約束/索引補充記錄來邏輯地標識在邏輯備數據庫中被更改的行。當容許數據庫範圍的主鍵和惟一約束/索引補充記錄時，每一個 UPDATE 語句也寫必要的列值到重作日誌，以在邏輯備數據庫中惟一地標識被更改的行。 

z 若是表定義了主鍵，則主鍵與被更改的列一塊兒記錄，做爲 UPDATE 語句的一部分來標識更改的行。 

z 若是沒有主鍵，則最短的非空惟一約束/索引與更改的行一塊兒記錄，做爲 UPDATE 語句的一部分來標識更改的行。 

z 若是即沒有主鍵也沒有非空惟一約束/索引，則全部有界限大小的列做爲 UPDATE 語句的一部分記錄，以標識更改的行。換一句話說，記錄全部列除了：LONG、LOB、

LONG RAW、對象類型、和集合。 

Oracle 推薦你在主數據庫中添加一個主鍵或非空惟一索引，只要可能，確保 SQL 應用能有效地應用重作數據庫更新到邏輯備數據庫。 

執行下面的步驟來確保SQL 應用能惟一地標識在邏輯備數據庫中被複制的每一個表的行。 

 

第1 步 在主數據庫中找到沒有惟一邏輯標識符的表。 

查詢DBA_LOGSTDBY_NOT_UNIQUE 視圖來顯示 SQL 應用可能沒法惟一標識的表的列表。例如： 

SQL> SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE

  2> WHERE (OWNER, TABLE_NAME) NOT IN 

  3> (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) 

  4> AND BAD_COLLUMN = 'Y'

 

第2 步 添加一個禁用主鍵 RELY 約束 

若是你的應用確保表中的行是惟一的，則你能在表上建立一個禁止的主鍵RELY 約束。這能避免在主數據庫上維護主鍵的開銷。 

要在主數據庫表上建立一個禁止的RELY 約束，使用帶 RELY DISABLE 子句的 ALTER TABLE 語句。下面的例子在名爲 mytab 的表上建立了一個禁止的 RELY 約束，每一行都能使用 id 和 name 列惟一標識： 

SQL> ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;

 

當你指定RELY 約束時，系統將假設行是惟一的。由於你告訴系統依靠該信息，可是在每次更改表時不會去確認，因此對於將惟一標識表中的每一行的禁止的 RELY 約束，你必須當心查詢列。若是這樣的惟一性不存在，則 SQL 應用將沒法正確地維護該表。 

要提升SQL 應用的性能，在邏輯備數據庫上添加一個惟一約束/索引到列上以標識行。若是添加失敗會致使 SQL 應用在表上進行的 UPDATE 或 DELETE 語句時進行全表掃描。 

 

同時查看： 

z 查看 Oracle 數據庫參考以得到 DBA_LOGSTDBY_NOT_UNIQUE 視圖的相關信息 z Oracle 數據庫 SQL 參考以得到 ALTER TABLE 語句語法和建立 RELY 約束相關信息 

z 9.6.1 節，「建立主鍵 RELY 約束」以得到 RELY 約束和你增長邏輯備數據庫性能所採起措施相關信息 

 

 

 

4.2 建立邏輯備數據庫的逐步指導 

本小節描述了你建立邏輯備數據庫所執行的任務。 

表－2 提供了你建立邏輯備數據庫和指定在哪一個數據庫上執行每一個任務的任務列表。

每小節還有相關參考更詳細地描述任務。 

表－2 建立邏輯備數據庫 

 

參考 任務 數據庫 

4.2.4 節 轉換到邏輯備數據庫 備 

4.2.5 節 打開邏輯備數據庫 備 

4.2.6 節 檢查邏輯備數據庫正確執行 備 

 

 

4.2.1 建立物理備數據庫 

你建立邏輯備數據庫，首先建立物理備數據庫而後將其轉換成邏輯備數據庫。遵循第 3 章，「建立物理備數據庫」中的指導來建立物理備數據庫。 

 

4.2.2 在物理備數據庫上中止重作應用 

你能在將新的物理備數據庫轉換成邏輯備數據庫以前在上面運行任何長度時間的重作應用。然而，在轉換到邏輯備數據庫以前，在物理備數據庫上中止重作應用。中止重作應用是必要的，能夠避免應用在包含LogMiner 字典的重作以後的更改（在 4.2.3.2 節，「在重作數據中創建字典」中描述）。 

要中止重作應用，在物理備數據庫上執行下面的語句。若是數據庫是包含多個實例的

RAC 數據庫，則你在執行這個命令以前必須首先中止除了一個之外的全部 RAC 實例： 

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

 

4.2.3 準備主數據庫以支持邏輯備數據庫 

本小節包含下面主題： z 爲角色轉換準備主數據庫 z 在重作數據中創建字典 

 

4.2.3.1 爲角色轉換準備主數據庫 

在3.1.4 節，「設置主數據庫初始化參數」中，你設置多個備角色初始化參數以在主數據庫轉換到物理備角色時起做用。若是你計劃轉換主數據庫到邏輯備角色，則你還必須在主數據庫上包含LOG_ARCHIVE_DEST_3 目的地，如例子 4－1 中所示，使得在角色轉換以後不須要更改參數。這個參數只有在主數據庫轉換到備角色時才起做用。 

例子4－1 主數據庫：邏輯備角色初始化參數 

LOG_ARCHIVE_DEST_3=

'LOCATION=/arch2/chicago/

  VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) 

  DB_UNIQUE_NAME=chicago'

LOG_ARCHIVE_DEST_STATE_3=ENABLE

 

要動態設置LOG_ARCHIVE_DEST_3 參數，使用 SQL ALTER SYSTEM SET 語句幷包含 SCOPE=BOTH 子句，使得更改當即起做用並在數據庫關閉並再次啓動後還保持。 

下面的表描述了由例子 4－1 中所示初始化參數定義的歸檔進程。 

當 chicago 數據庫運行在主角色	當 chicago 數據庫運行在邏輯備角色
LOG_ARCHIVE_DEST_3