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

us_yunleiwang發表於2013-12-04
Oracle

June 26, 2012

緣起

最近做了10g和11ｇ的物理備庫配置實驗，發現 Data Guard 其實很容易，但是缺少好文件。我是參考官方文件做的實驗，覺得它寫的不是很清楚的。

Google 出來兩個pdf文件，讀了覺得比官方文件強很多。翻譯下，也許會對某些朋友有用。翻譯的同時我也好更熟悉下這兩個文件。好久沒翻譯過英文了，可以順便練練手。

原文件下載地址（牆外）：

第一部分

簡介

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。我不使用這個功能的理由是：

  1. 反正我也需要複製密碼檔案到備庫伺服器，所以它並沒有節省我複製檔案的時間。
  2. 要使用這個功能，你仍然需要使用 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 環境。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/23490154/viewspace-1062148/，如需轉載，請註明出處，否則將追究法律責任。

相關文章