Oracle 11g Data Guard 物理備庫快速配置指南

Oracle 11g Data Guard 物理備庫快速配置指南

緣起
最近做了Oracle 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=<sys 使用者密碼>

最後，檢查資料庫的 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 <catalogowner>@<catalogdb>
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 環境。

--------------------------------------分割線 --------------------------------------

Oracle Data Guard 重要配置參數

基於同一主機配置 Oracle 11g Data Guard

探索Oracle之11g DataGuard

Oracle Data Guard （RAC+DG) 歸檔刪除策略及指令碼

Oracle Data Guard 的角色轉換

Oracle Data Guard的日誌FAL gap問題

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 處理方法

--------------------------------------分割線 --------------------------------------

更多詳情見請繼續閱讀下一頁的精彩內容：

1 2 下一頁