最近做了10g和11ｇ的物理備庫配置實驗，發現 Data Guard 其實很容易，但是缺少好文檔。我是參考官方文檔做的實驗，覺得它寫的不是很清楚的。
Google 出來兩個pdf文檔，讀了覺得比官方文檔強很多。翻譯下，也許會對某些朋友有用。翻譯的同時我也好更熟悉下這兩個文檔。好久沒翻譯過英文了，可以順便練練手。
原文檔下載地址（牆外）：
Configure Dataguard 11gR2 Physical Standby Part 1
Configure Dataguard 11gR2 Physical Standby Part 2
第一部分
簡介
Data Guard 是 Oracle 數據庫的一個功能，能夠提供數據庫的冗余。冗余是通過創建一個備用（物理復制）數據庫實現，備庫最好是在不同的地理位置或者在不同的磁盤上。備庫通過應用主庫上的變化來保持數據同步。備庫可以使用重做日志應用(物理備庫)或SQL應用同步(邏輯備庫)。
本文旨在說明 Data Guard 的配置並不復雜，不需要特殊的技能或者培訓才能學會搭建。它將快速展示給讀者搭建一個物理備庫的過程。我的目標是，即使你第一次接觸 Data Guard，剛考慮要使用它或擔心它會不會很難配置，本文將幫助你快速搭建起一個正常運行起來的物理備庫。
為什麼使用 Data Guard
每種 Oracle 高可用性工具都有其目的。使用 Data Guard 的理由有：
整個數據庫的冗余
故障時的快速恢復
故障後客戶端能自動重連
在備庫運行備份
較好的故障平均修復時間
並不復雜
系統環境
在寫完本文後，我使用 DBCA 創建了一個新數據庫 JED，然後重新運行了文中的配置步驟，確認其對一個基本的 Oracle 11g 數據庫適用。主庫叫 JED，運行在一台叫 dev-db1的服務器上。備庫叫JED2，運行在一台叫 dev-db2 的服務器上。
不需要提的基本前提
有一些任何生產庫都應該有的基本的設置。其中一個就是歸檔模式。對於生產庫，這應該是一個明顯的必須配置。如果你的生產庫沒有適用歸檔模式，你要麼需要馬上開始讀點書，要麼你得有一個非常非常好的理由。我不大確定誰真能找出一個理由，但任何准則都有例外。
如何修改你的數據庫為歸檔模式：
SQL> shutdown immediate SQL> startup mount SQL> alter database archivelog; SQL> alter database open; SQL> archive log list;
主庫准備
首先，備庫要成為主庫的完全相同的復制，它必須接收來自主庫的重做日志。Oracle 數據庫中，一個用戶可以用指定某操作不產生日志(比如使用 NOLOGGING 語句）。對於備庫來說，這是個問題。你必須確認用戶無法指示數據庫不產生重做日志，這需要啟用數據庫的強制日志功能。啟用方法如下：
SQL> alter database force logging;
SQL> select name, force_logging from v$database;
你應該看到 force_logging 列為 YES。
其次，你要確認當主庫添加或刪除數據文件時，這些文件也會在備庫添加或刪除。啟用此功能的方法如下：
SQL> alter system set standby_file_management = 'AUTO';
再次，我們要確認書庫有備用日志文件(Standby Log Files)。備庫使用備用日志文件來來保存從主庫接收到的重做日志。主庫上也建立備用日志文件有兩個原因，一是主庫可能轉換成備庫，備庫需要備用日志，二是如果主庫建了備用日志，備庫會自動建。備用日志應該跟在線日志一樣大，組數應該至少跟在線日志一樣多，或者更多。我喜歡給備用日志一個跟在線日志不同范圍的編號，比如在線日志組是1到6，備用日志就是11到16。創建備用日志的方法如下：
SQL> alter database add standby logfile group 11 ('/oradata/JED/g11m01.sdo','/oradata/JED/g11m02.sdo') size 50M;
如果你不是使用 SSL 做重做日志傳輸驗證(一般來說不會)，那麼你需要使用密碼文件做驗證。你必須創建密碼文件，並且設置參數 REMOTE_LOGIN_PASSWORDFILE 為 EXCLUSIVE 或 SHARED。一般數據庫默認就有密碼文件，並且此參數默認為 EXECUSIVE。先檢查下這兩項，如果不是默認，設置方法如下：
SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;
OS> orapwd password=
最後，檢查數據庫的 db_unique_name 參數是否設置。如果沒有，使用 alter system 進行設置：
SQL> show paramter db_unique_name;
SQL> alter system set db_unique_name=some_name scope=spfile;
閃回數據庫
我強烈建議開啟數據庫閃回功能。閃回允許你將數據庫還原到以前的某一時間點。當發生故障轉移時，這個功能非常有用，它能讓你將老的主庫閃回到故障前，然後將其轉換為備庫。如果沒有啟用閃回功能，你就必須重建備庫，意味著要再復制一次數據文件。除了這個好處，閃回還能在某些情況下讓你避免從備份恢復數據。
啟用閃回功能，必須先配置快速恢復區(Flash/Fast Recovery Area). 方法如下：
SQL> alter system set db_recovery_file_dest='&快速恢復區目錄或ASM磁盤組名';
SQL> alter system set db_recovery_file_dest_size=400G;
配置好快速恢復區後，就可以啟用閃回日志功能：
SQL> alter database flashback on;
SQL> select flashback_on from v$database;
FLASHBACK_ON 這列的值應該是 YES。如果你碰到 ORA-01153 報錯，那一定是在備庫進行此操作。你需要先取消重做日志應用，啟用閃回日志，然後重新啟用日志應用。
在主庫啟用閃回日志，不會同步備庫也啟用。你必須手動在主庫和備庫上均啟用閃回日志。如果不啟用閃回日志，當出現故障轉移時，你將需要完全重新開始創建一個備庫。
SQL*NET 配置
在創建備庫前，要確認兩台服務器的數據庫之間能通信，如果我們要用 RMAN 的 duplicate from active database 命令創建備庫的話。我們需要配置監聽和 TNS 名。你可以手動配置，也可以使用網絡配置工具(netca)。我更喜歡手動配置，因為我比較老派，並且這些配置文件又不復雜，
首先需要配置主備庫的監聽。雖然數據庫會自動注冊監聽，但如果要使用 RMAN 的 duplicate 命令創建備庫，備庫必須首先處於 NOMOUNT 狀態。在 NOMOUNT 狀態下，數據庫實例不會自動注冊監聽，你必須配置靜態監聽。另外必須要注意的一點是，NOMOUNT 狀態下的數據庫必須使用專用模式(dedicated server)連接。
兩台服務器上的 TNS 名字文件必須配置好，讓主備庫能用 LOG_ARCHIVE_DEST_N 和 FAL_SERVER 參數（稍後會介紹這些參數）中的服務名(Service Names）找到對方。具體配置應類似下例。
主庫(dev-db1)的監聽配置：
SID_LIST_LISTENER= (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = JED) (ORACLE_HOME = /oracle/product/11.2.0) (SID_NAME = JED) ) )
備庫(dev-db2)的的監聽配置：
SID_LIST_LISTENER= (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = JED2) (ORACLE_HOME = /oracle/product/11.2.0) (SID_NAME = JED2) ) )
主庫的 TNS 名字文件配置：
JED2 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = dev-db2)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = JED2) ) )
備庫的 TNS 名字文件配置：
JED = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = dev-db1)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = JED) ) )
重做日志傳輸配置
現在主備庫之間依舊可以互相通信了，下一步是配置歸檔位置和重做日志傳輸。我們將先在主庫上進行配置，然後等備庫創建好後，修改備庫的配置。
配置歸檔位置：
SQL> alter system set log_archive_dest_1 = 'location=use_db_recovery_file_dest valid_for=(all_logfiles, all_roles) db_unique_name=JED';
這個命令指定快速恢復區作為歸檔位置，此歸檔位置用於在所有數據庫角色下歸檔所有的日志文件。官方文檔裡說使用 valid_for=(online_logfiles, all_roles)，這將導致備庫無法歸檔備用日志文件，因為它們不是在線日志。但如果使用 all_logfiles 選項，主備庫將都能歸檔在線以及備用日志。如果你想在備庫進行備份，並同時備份歸檔日志的話，必須使用 all_logfiles。
然後配置重做日志傳輸到備庫：
SQL> alter system set log_archive_dest_2 = 'service=JED2 async valid_for=(online_logfile,primary_role) db_unique_name=JED2';
這條語句說，如果這是主庫，就使用服務名 JED2 傳輸在線日志，目標庫名叫 JED2。
要注意STANDBY_ARCHIVE_DEST 參數不需要，已經被官方棄用。當調試時，不少人好心建議我設置此參數，但設置此參數後啟動數據庫，只會報 ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance 錯。
另一個要設置的參數是 FAL_SERVER。這個參數指定當日志傳輸出現問題時，備庫到哪裡去找缺少的歸檔日志。它用在備庫接收的到的重做日志間有缺口的時候。這種情況會發生在日志傳輸出現中斷時，比如你需要對備庫進行維護操作。在備庫維護期間，沒有日志傳輸過來，這時缺口就出現了。設置了這個參數，備庫就會主動去尋找那些缺少的日志，並要求主庫進行傳輸。
SQL> alter system set fal_server = 'JED2';
注意 FAL_CLIENT 參數在11g裡已經棄用。
然後我們要讓主庫知道 Data Guard 配置裡的另外一個庫的名字：
SQL> alter system set log_archive_config = 'dg_config=(JED,JED2)';
這一步做完後，我們就可以准備好備庫的環境，並開始創建備庫了。
備庫環境准備
現在開始准備備庫環境。有很多種方法來執行這些步驟。我這裡寫的是我覺得最適合我的方法。你應該實驗多種方法，看哪種比較適合你。
首先，我們要為備庫創建密碼文件和參數文件(spfile)。密碼文件可以直接復制過去，只需要改下名字就行。比如，主庫上的密碼文件是 $ORACLE_HOME/dbs/orapwJED。我們把它復制到備庫服務器的相同位置，用備庫的 SID 取代主庫，修改其名字為 orapwJED2。
為了創建備庫 spfile，先創建一個啟動參數文件(pfile)：
SQL> create pfile from spfile;
我想介紹一個看起來挺不錯新功能，使用 RMAN 創建備庫 SPFILE。我不使用這個功能的理由是：
反正我也需要復制密碼文件到備庫服務器，所以它並沒有節省我復制文件的時間。
要使用這個功能，你仍然需要使用 parameter_value_convert 參數做很多替換工作，還有使用 SPFILE 語句和多個 SET 語句以確保一切正確。
我發現復制 pfile 過去更容易(你甚至可以直接粘貼復制)，只要改下名字，然後改幾個裡面的參數就行。這很容易，你也可以在手動修改和調試的過程中學到很多。我發現手動改比用 RMAN 的 SPFILE創建功能更快。
創建好了主庫的 pfile 後，將其復制到備庫服務器的相同位置，使用備庫的 SID 修改其名字。你需要對 pfile 做如下修改：
根據你備庫的配置和文件位置，你可能需要修改 AUDIT_FILE_DEST，CONTROL_FILES 和 DISPATCHERS 參數（也許還有其他需要修改的參數）。
LOG_ARCHIVE_DEST_1 參數中的 db_unique_name 修改為備庫的相應唯一名（這裡是 JED2）。
LOG_ARCHIVE_DEST_2 參數，修改為主庫對應的服務名和數據庫唯一名（這裡是 JED）。
FAL_SERVER 參數修改指向主庫的服務名。
增加如下參數：
db_unique_name=JED2
db_file_name_convert 和 log_file_name_convert。如果主備庫的數據文件、日志文件位置不同，需要設置這兩個參數。
然後在備庫服務器上創建所需目錄結構和修改相關文件。至少需要修改如下創建目錄和文件：
$ORACLE_BASE/admin/$ORACLE_SID
$ORACLE_BASE/admin/$ORACLE_SID/adump（audit_file_dest配置的目錄）
數據文件目錄
控制文件目錄
日志文件目錄
快速恢復區目錄
將備庫信息加到 /etc/oratab 文件
現在可以准備啟動備庫實例來創建數據庫了。在啟動過程中創建一個 spfile。
SQL> startup nomount pfile=initJED2.ora SQL> create spfile from pfile; SQL> shutdown SQL> startup nomount SQL> show parameter spfile SQL> exit
show parameter spfile 顯示 spfile 的位置，這時備庫處於 NOMOUNT 狀態。
備庫創建
就像之前的步驟一樣，創建數據庫這一步也可以有多種方法。在11g中，我將使用 RMAN 的復制功能，因為它很容易。在上一步裡，我們復制了密碼文件和參數文件到備庫服務器，修改好了參數文件，並創建了 spfile。這讓使用 RMAN 復制功能更加容易，當然，你也可以跳過手工復制密碼和參數文件這步，讓 RMAN 使用 SPFILE，PARAMETER_VALUE_CONVERT 和 SET等命令幫你自動完成。
使用 RMAN 創建備庫的命令非常簡單。它指示 RMAN 直接復制當前活動的數據庫（主庫）到輔助數據庫（備庫）。這樣你就不需要現將主庫的備份復制到備庫服務器上，再還原數據庫。在今天的存儲技術下，我們有更快更簡單的方式復制數據庫，但為了展示11g的這個新功能，並且這個功能又很簡單，我喜歡盡可能使用它。
RMAN> connect target sys@JED RMAN> connect catalog @ RMAN> connect auxiliary sys@JED2 RMAN> duplicate target database for standby from active database;
在 11.2.0.2.0 版本後，你可以直接使用 connect target 連接輔助數據庫，但如果不指定用戶名和密碼，在復制到備庫時將報 invalid username/password 錯。
當復制命令在執行時，我喜歡 tail 備庫的告警日志文件，觀察復制進行到了哪一步和查看是否有報錯。注意，針對在線和備用日志文件報 ORA-27037: unable to obtain file status 錯是正常的。
你也可以並行復制以提高性能。需要分派主庫和備庫多個通道後，再執行復制命令：
run
{
allocate channel chan1 type disk;
allocate channel chan2 type disk;
allocate channel chan3 type disk;
allocate channel chan4 type disk;
allocate auxiliary channel aux1 type disk;
allocate auxiliary channel aux2 type disk;
allocate auxiliary channel aux3 type disk;
allocate auxiliary channel aux4 type disk;
duplicate target database for standby from active database;
}
如果一切正常，你將看到 RMAN 報出類似如下信息：
Finished Duplicate Db at 07-MAY-10
當備庫復制完成後，我喜歡在備庫啟用閃回日志：
SQL> alter database flashback on;
啟動重做日志應用
啟動或者停止重做日志應用非常容易。啟動日志應用：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE
DISCONNECT FROM SESSION;
這個命令指示備庫開始使用備用日志文件進行恢復。它也告訴備庫命令完成後回到命令行界面。如果你想停止恢復：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
確認日志應用正常
你要確認重做日志正在應用到備庫。首先我們要確認主備庫裡的歸檔目的地配置都是有效的：
SQL> select DEST_ID, STATUS, DESTINATION, ERROR from V$ARCHIVE_DEST where DEST_ID<=2;
目的地狀態應該顯示為 VALID。
然後確認重做日志是否真的被應用了，在主庫執行：
SQL> select SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED, ARCHIVED from V$ARCHIVED_LOG where name = 'JED2' order by FIRST_TIME;
如果歸檔和日志應用均正常，APPLIED 和 ARCHIVED 列都應該是 YES。很多教程裡都讓這個查詢以 SEQUENCE# 列排序，但我不推薦。如果以 SEQUENCE# 列排序，當你做了一次故障轉移後，序列號會再從1開始，這時使用這個查詢，你將不能在結果最後看到最新的記錄。我曾經很奇怪為什麼查不到新記錄，其實是因為新記錄不是出現在最後，我沒看到。所以，這個查詢都是以 FIRST_TIME 列排序。
如果你發現日志沒有被應用，那可能是重做日志有了缺口，這種情況下備庫無法進行日志應用。但如果你的 FAL_SERVER 參數設置正確，這應該不會有問題。你可以在主庫上檢查是否有重做日志缺口：
SQL> select STATUS, GAP_STATUS from V$ARCHIVE_DEST_STATUS where DEST_ID = 2;
如果一切正常，應該返回 VALID 和 NO GAP。如果你想測試下 FAL_SERVER 這個參數是怎麼工作的。可以先把備庫關掉，然後在主庫切換幾次日志，等一會，啟動備庫，再切換一次日志。這樣缺口很快就會出現。如果 FAL_SERVER 設置正常，缺少的重做日志會被傳輸過來並應用。
V$DATAGUARD_STATUS 視圖對查找錯誤和了解發生了什麼非常有用。可以在主備庫上執行以下查詢查看數據庫狀態：
SQL> select * from V$DATAGUARD_STATUS order by TIMESTAMP;
有時候你手工想確認下數據真的同步了。一個更讓人信服的方法是，直接查詢備庫，看新數據是否存在。你可以將備庫打開為只讀狀態，首先取消日志應用，再執行如下命令：
SQL> ALTER DATABASE OPEN READ ONLY;
這時你可以查詢變化了的數據是否同步過來。11g已經支持活動備庫，可以讓數據庫在只讀狀態下打開，同時啟動日志應用。
總結
現在你有一個配置好的 Data Guard，也就有了一個冗余的數據庫。我不想留下主備轉換、故障轉移、重建庫等不講，這些主題將放到本文的第二部分。
我希望本文能幫助你更容易和更快速地創建你的 Data Guard 環境。
