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

us_yunleiwang發表於2013-12-04

June 26, 2012

緣起

最近做了10g和11g的物理備庫配置實驗,發現 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/,如需轉載,請註明出處,否則將追究法律責任。

相關文章