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

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

[日期：2015-04-17]

來源：Linux社區  做者：cloudsnowe

[字體：大 中 小]

緣起
最近作了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 重要配置參數 http://www.linuxidc.com/Linux/2013-08/88784.htm

基於同一主機配置 Oracle 11g Data Guard http://www.linuxidc.com/Linux/2013-08/88848.htm

探索Oracle之11g DataGuard http://www.linuxidc.com/Linux/2013-08/88692.htm

Oracle Data Guard （RAC+DG) 歸檔刪除策略及腳本 http://www.linuxidc.com/Linux/2013-07/87782.htm

Oracle Data Guard 的角色轉換 http://www.linuxidc.com/Linux/2013-06/86190.htm

Oracle Data Guard的日誌FAL gap問題 http://www.linuxidc.com/Linux/2013-04/82561.htm

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 處理方法 http://www.linuxidc.com/Linux/2013-03/82009.htm

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

更多詳情見請繼續閱讀下一頁的精彩內容： http://www.linuxidc.com/Linux/2015-04/116345p2.htm