第二部分
作者介紹
作者 Jed Walker 是科羅拉多 Centennial Comcast 媒體中心的資料操作經理(Manager of Databse Operation)。他從1997年開始做 Oracle 資料庫相關工作，是9i, 10g和11g的OCP。

簡介
本文的第一部分講解了如何配置一個基本的 Data Guard 環境。在第二部分裡，我將介紹主備切換、故障轉移(資料庫和客戶端）等其他主題。

回顧
在本文第一部分中，我們配置了一個物理備庫。在這第二部分中，我將介紹主備切換(Switchover)，故障轉移(Failover)，客戶端故障轉移(Client Failover)，使用閃回資料庫重建庫，活動資料衛士(Active Data Guard)，還討論了一點備份。

故障轉移配置
現在你已經配好了一個物理備庫，你可能想試試主備切換(switchover)，甚至故障轉移(failover)，但你先得確定客戶端會跟著切換和轉移。我們需要配置資料庫和客戶端來支援這些功能。要確定你的客戶端能連線到正確的資料庫，你要在資料庫裡配置一個支援故障轉移的服務，並配置客戶端的 TNS，讓它知道如何在一個 Data Guard 叢集裡找到主庫。

首先，建立一個支援故障轉移的服務。我們要建立此服務，確定它在主庫上啟動，並確定它只在主庫上啟動。建立服務使用如下 SQL：

begin
    DBMS_SERVICE.CREATE_SERVICE (
        service_name => 'JED_RW',
        network_name => 'JED_RW',
        aq_ha_notifications => TRUE,
        failover_method => 'BASIC',
        failover_type => 'SELECT',
        failover_retries => 30,
        failover_delay => 5);
end; /

此服務在資料庫出現故障時會發送通知給客戶端，允許查詢語句在故障轉移發生後繼續執行。我使用命名 SID_RW 顯示這時一個可讀寫的資料庫（主庫）。

下一步是確定新建立的服務永遠只在主庫執行。我們建立一個儲存過程來實現此目的，如果當前資料庫是主庫它就啟動此服務，如果是備庫就停止。

create or replace procedure cmc_taf_service_proc
is
    v_role VARCHAR(30);
begin
    select DATABASE_ROLE into v_role from V$DATABASE;
    if v_role = 'PRIMARY' then
        DBMS_SERVICE.START_SERVICE('JED_RW');
    else
        DBMS_SERVICE.STOP_SERVICE('JED_RW');
    end if;
end;
/

然後建立兩個觸發器，讓資料庫在啟動和角色轉換時執行此儲存過程。我參考的文件，只提到建立一個觸發器（角色轉換時）。如果只建立一個，當你重啟你的資料庫時，它不會重啟故障轉移服務。所以我建立兩個：

create or replace TRIGGER cmc_taf_service_trg_startup
after startup on database
begin
    cmc_taf_service_proc;
end;
/

create or replace TRIGGER cmc_taf_manage_trg_rolechange
after db_role_change on database
begin
    cmc_taf_service_proc;
end;
/

現在我們執行一次儲存過程，確定服務正在執行，並歸檔當前日誌，讓以上更改同步到備庫。

SQL> exec cmc_taf_service_proc;
SQL> alter system archive log current;

我們現在有了一個叫 JED_RW 的服務，可以讓客戶端連線。

SQL> show parameter service_names

NAME             TYPE        VALUE
---------------- ----------- ------------
service_names    string      JED_RW

有這個服務名存在還不夠，你必須配置客戶端的 TNS 名去連線它。客戶端的 TNS 名應該類似如下：

JED_RW =
  (DESCRIPTION =
    (ADDRESS_LIST=
        (ADDRESS = (PROTOCOL = TCP)(HOST = dev-db1)(PORT = 1521))
        (ADDRESS = (PROTOCOL = TCP)(HOST = dev-db2)(PORT = 1521))
    )
    (CONNECT_DATA = (SERVICE_NAME = JED_RW)
        (FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=30)(DELAY=5))
    )
  )

這個 TNS 名裡包含 Data Guard 配置裡的兩個主機，使用 JED_RW 服務名確定連線到主庫。

如果你想連線特定的資料庫，不管它是主是備，可以使用標準的 TNS 名，如下：

JED =
  (DESCRIPTION_LIST=
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = dev-db1)(PORT = 1521))
      (CONNECT_DATA = (SERVICE_NAME = JED))
    )
  )

當你的客戶端使用新 TNS 名後，它們能在主備切換和故障轉移操作後找到主庫。如果客戶端在執行一個查詢，並且沒有 DML 是在一個交易中，那在發生切換操作後，只要主備轉換和故障轉移在超過最大重試次數前完成，這個查詢會繼續工作，只是會有延遲。你應該多做幾次切換實驗，以確定 RETRIES 和 DELAY 引數如何設定合適。如果有一個正在進行中的交易，當客戶端連線到新的主庫後，查詢將報錯（`ORA-25403: transaction must roll back），並回滾。

進行主備切換(Switchover)
現在你準備好做一次主備切換了，做之前先做些檢查。首先在主庫確認沒有日誌缺口：

SQL> select STATUS, GAP_STATUS from V$ARCHIVE_DEST_STATUS where DEST_ID = 2;

應該返回 VALID 和 NO GAP。

查詢v$tempfile檢視確認備庫的臨時檔案和主庫一樣。

刪除 LOG_ARCHIVE_DEST_N 引數中的所有延遲應用重做日誌設定，你要確認所有變化都在備庫應用，才能確保無資料丟失。確認所有重做日誌都已在備庫應用，查詢備庫：

SQL> select NAME, VALUE, DATUM_TIME from V$DATAGUARD_STATS;

不應該返回 transport lag 或 apply lag, finish time 應該為0.

檢查完這些先決條件後，確認主庫可以進行角色切換，查詢主庫：

SQL> select SWITCHOVER_STATUS from V$DATABASE;

如果返回 TO STANDBY 或 SESSIONS ACTIVE，那麼主庫就可以進行切換。切換主庫為備庫命令為：

SQL> alter database commit to switchover to physical standby with session shutdown;
SQL> shutdown immediate;
SQL> startup mount;

然後查詢備庫是否可以切換為主庫，查詢備庫：

SQL> select SWITCHOVER_STATUS from V$DATABASE;

如果返回 TO PRIMARY 或 SESSIONS ACTIVE，就可以切換。如果返回 SWITCHOVER LATENT 或 SWITCHOVER PENDING，就要去檢查告警日誌，看有什麼問題，一般是需要應用一些日誌。如果是需要應用日誌的話，在備庫執行如下命令：

SQL> recover standby database using backup controlfile;

在應用日誌前應該是 SWITCHOVER PENDING 狀態，完成應用後，會變成 TO PRIMARY 或 SESSIONS ACTIVE狀態。

現在可以切換備庫為主庫了：

SQL> alter database commit to switchover to primary with session shutdown;
SQL> alter database open;

完成主備切換後，在備庫上啟用日誌應用：

SQL> alter database recover managed standby database using current logfile

disconnect from session;

進行故障轉移(Failover)
故障轉移，一般用在主庫發生故障後需要恢復服務的情況下。故障轉移將備庫轉換為主庫，但不把原主庫（有故障，無法正常工作）切換為備庫。當故障轉移發生後，你必須重建主庫，或者使用閃回資料庫功能將主庫回退到故障發生前，然後轉換其為備庫並啟用日誌應用。

我將故障轉移分為三類：優雅、幾乎優雅和標準。分類標準是主庫故障的嚴重程度。故障轉移不會是優雅的，但是你對故障的應對可以是優雅的。注意這些分類不是 Oracle 的官方分類，我個人創造這些分類用來代表故障轉移的三個不同階段。

優雅的故障轉移
如果當前備庫是處於最大保護（maximum protection）模式，要進行故障轉移，必須先修改為最大效能（maximum performance）模式。修改方法：

SQL> alter database set standby database to maximize performance;

如果你還能將主庫啟動到掛載（mount）狀態，你可以試著將重新整理未傳輸的日誌到備庫。如果你能重新整理，故障轉移可能不會丟失任何資料。在本文中，我們上一節主備切換主庫到了 JED2，我們現在故障轉移回 JED：

SQL> startup mount
SQL> alter system flush redo to 'JED';

如果以上命令正常，日誌已經傳輸到備庫，我們需要在備庫上應用它們。在下一節裡，我們要確認所有重做日誌是否都傳輸到了備庫。

幾乎優雅的故障轉移
為了儘可能少的丟失資料，你應該嘗試將所有歸檔日誌應用。你應該將主庫上的所有歸檔日誌複製到備庫。可能有一些歸檔日誌已經在備庫存在，但這樣你能有儘可能多的歸檔日誌。然後你要解決備庫中的任何日誌缺口。

首先，複製所有主庫的歸檔到備庫，並在資料庫中註冊它們：

SQL> alter database register physical logfile '&logfile_path_name';

檢查是否有日誌缺口：

SQL> select THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# from V$ARCHIVE_GAP;

如果有缺口存在，而主庫上還有此日誌檔案，複製過來並註冊。

標準故障轉移
在備庫停止日誌應用：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

結束應用任何日誌：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;

如果以上命令有任何報錯，檢查相關告警日誌和跟蹤資訊。一旦你執行了這個命令，備庫就必須轉換為主庫，要不就得重建。

檢查備庫是否能轉換為主庫，執行：

SQL> select SWITCHOVER_STATUS from V$DATABASE;

查詢應該要返回 TO PRIMARY 或 SESSIONS ACTIVE，不然你可能還沒有應用完所有日誌。確認你執行了 RECOVER...FINISH命令。

轉換備庫為主庫：

SQL> alter database commit to switchover to primary with session shutdown;
SQL> alter database open;

如果你有不止一個備庫，你需要在其他備庫上重啟日誌應用。下一步是重建原主庫。如果配置了閃回資料庫，重建會比較容易。

使用閃回資料庫重建庫
現在你已經進行了故障轉移，原主庫需要重建為備庫。使用閃回資料庫重建原主庫，首先需要獲得原備庫轉換為主庫時的 SCN。查詢現主庫：

SQL> SELECT to_char(STANDBY_BECAME_PRIMARY_SCN) from V$DATABASE;

有了這個 SCN，你就可以使用閃回資料庫功能將原主庫回退到故障轉移發生的時間點。在原主庫上執行：

SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN &standby_became_primary_scn;

如果沒有開始閃回日誌，最後一條命令會報錯 ORA-38726: Flashback database logging is not on.，無法進行閃回。你就需要重新從新主庫複製資料，重建原主庫為備庫。

如果命令成功執行，原主庫就可以使用新主庫的日誌進行恢復。將原主庫轉換成物理備庫，並啟動日誌應用程序：

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

然後就可以在新主庫切換一次日誌，檢視新備庫的日誌應用是否正常，具體命令在本文第一部分。

客戶端故障轉移
我很喜歡的一個功能是，當主備切換或故障轉移發生後，客戶端能夠自動重連。在你的系統裡，做下述實驗，看結果如何。JED 是主庫，JED2 是備庫。客戶端使用支援故障轉移的 JED_RW 服務名。

首先，用 SYSTEM 使用者和 JED_RW 服務名在 SQL*Plus 裡登入主庫：

SQL> connect [email protected]_rw
SQL> select db_unique_name from v$database;

查詢應該返回主庫名 JED。然後做一次主備切換，在將備庫轉換為主庫 alter database commit to switchover to primary with session shutdown; 這一步時，主備庫均處於 MOUNT 狀態。然後執行查詢：

SQL> select db_unique_name from v$database;

這時查詢應該掛住，這是因為客戶端正在嘗試尋找主庫，但當前又沒有可用的主庫。然後繼續完成主備切換。

當主備切換完成後，客戶端應該會重連並重新執行查詢，查詢完成後成功返回結果 JED2，因為現在主庫已經切換為 JED2，不再是 JED。另一個很酷的測試方法是，執行一個執行時間非常長的查詢，當查詢結果返回，螢幕一直滾動時開始主備切換。你應該會看到螢幕暫停滾動一段時間，當切換完成後，又會繼續滾動。

活動資料衛士(Active Data Guard)
警告！活動資料衛士功能需要單獨的授權。雖然開啟此功能很容易，如果沒有授權，你不應該使用它。

活動資料衛士是 11g 的新功能，它允許你的物理備庫在應用日誌時處於只讀開啟狀態。這明顯是一個很有用的功能。能夠允許主庫有一個物理備庫作為備份，並能在保持備庫資料更新的同時讀取備庫，這是一個很好的功能。Oracle 也知道，所以這個功能需要單獨買授權。

開啟活動資料衛士功能十分容易。你只需要開啟在你的資料庫後再啟動日誌應用：

SQL> STARTUP MOUNT
SQL> ALTER DATABASE OPEN;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

之後你就可以登入備庫，並執行查詢。你可以執行如下查詢確認：

SQL> SELECT name status, database_role, open_mode logins, log_mode FROM v$instance, v$database;

在開啟活動資料衛士功能後，查詢應該返回 PHYSICAL STANDBY，READ ONLY WITH APPLY 和 ARCHIVELOG。

當你開啟活動資料衛士功能後，你需要允許使用者根據需要連線到正確的資料庫。我建立第二個服務叫 SID_RO，並讓它只在備庫啟動。這個名字顯示你連線的是一個只讀（Read Only）資料庫，而不是讀寫資料庫。這個服務名的建立跟 SID_RW 類似：

begin
    DBMS_SERVICE.CREATE_SERVICE (
        service_name => 'JED_RO',
        network_name => 'JED_RO',
        aq_ha_notifications => TRUE,
        failover_method => 'BASIC',
        failover_type => 'SELECT',
        failover_retries => 30,
        failover_delay => 5);
end;
/

修改原啟動服務的儲存過程：

create or replace procedure cmc_taf_service_proc
is
  v_role VARCHAR(30);
begin
  select DATABASE_ROLE into v_role from V$DATABASE;
  if v_role = 'PRIMARY' then
    begin
      DBMS_SERVICE.STOP_SERVICE('JED_RO');
    exception
      when others then null;
    end;
    DBMS_SERVICE.START_SERVICE('JED_RW');
  else
    begin
      DBMS_SERVICE.STOP_SERVICE('JED_RW');
    exception
      when others then null;
    end;
    DBMS_SERVICE.START_SERVICE('JED_RO');
  end if;
end;
/

現在你有了一個活動資料衛士的配置，你的客戶端能連線到合適的資料庫例項，並可以在出現主備切換和故障轉移時自動重連。

備份
最後，如果不討論下備份，那對 Data Guard 的介紹還不算完整。Data Guard 實質上就是也是備份，但這不意味著你就不需要 RMAN 備份了。你已經花時間去啟用了強制記錄日誌，那你也應該做點備份。

有了 Data Guard，你的 RMAN 備份在主庫或者備庫都可以執行。但既然你已經配置了物理備庫，你應該減輕點主庫的負載。基本上，能在主庫執行的標準的備份命令或指令碼，也能在備庫執行，但也有幾個值得注意地方。這些 Oracle 官方文件都有，我只提幾個關鍵的事情：

你應該使用恢復目錄（Recovery Catalog）。這是因為主庫需要知道備庫已經存在了哪些備份檔案。你不需要在恢復目錄中註冊備庫，恢復目錄能認出它是備庫。

你不能備份備庫的控制檔案，所以不要在主庫關掉所有的備份，至少需要在主庫備份控制檔案和引數檔案。

備份和恢復可以寫一整篇文章，我只是講下我是如何配置備份的，讓你能從這裡開始，修改並形成自己的策略。測試下，確認你能從你當前實現的備份設定中恢復。在執行備份前，你需要配置一些基本的東西。

確認開啟控制檔案和 spfile 自動備份：

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;

根據你的需要設定備份檔案保留策略：

RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS;

如果一個檔案已經有備份，並且檢查點 SCN 相同，就不備份：

RMAN> CONFIGURE BACKUP OPTIMIZATION ON;

只在主庫的歸檔日誌已經在備庫應用（或者配置為已經傳輸到備份）後才刪除：

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

允許 RMAN 在主備間重新同步：

RMAN> CONFIGURE DB_UNIQUE_NAME P10AC CONNECT IDENTIFIER ‘JED’;
RMAN> CONFIGURE DB_UNIQUE_NAME P11AC CONNECT IDENTIFIER 'JED2';

在主庫我仍然備份歸檔日誌。首先，在主備庫都備份歸檔提供了冗餘。其次，當發生需要恢復的事件（比如資料檔案下線等）後，我在主庫已經有歸檔了。我需要刪除過期的歸檔，以清理磁碟空間。在Data Guard 環境下，不能使用標準的在單機刪除歸檔的命令，兩者有一點小區別。因為我們必須使用恢復目錄，我建立了一個全域性指令碼（global script）：

create global script dg_primary_arch
{
    backup archivelog all;
    delete noprompt archivelog all completed before 'sysdate-.5';
    delete noprompt backup of archivelog all completed before 'sysdate-2';
}

在備庫我執行標準的全庫和歸檔備份，並刪除過期的備份集。在 Data Guard 環境下，將備份歸檔包含在備份全庫的命令裡，會經常導致報錯 RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process。為避免此報錯，你應該將備份歸檔放在單獨的命令裡。我還是建立一個全域性指令碼：

create global script dg_standby_full
{
    backup database plus archivelog;
    delete noprompt archivelog all completed before 'sysdate-1';
    delete noprompt obsolete;
}

另外一個有用的技巧是，如果可能，使用共享檔案系統進行備份。這樣你在兩臺伺服器上都可以訪問備份檔案。這樣，當你需要恢復時，你不需要從另一臺伺服器上覆制檔案了。但如果使用共享檔案系統的話，你的歸檔備份雖然有兩份，卻都放在一個檔案系統裡，如果硬碟出現故障，兩份備份都會丟失。

總結
Oracle 11g 的 Data Guard 是一個很好的功能，配置起來相對容易，提供了在主庫異常時故障轉移的功能。它也能將主備的備份操作轉移到備庫執行，減輕主備負載。另外，Data Guard Broker 是一個宣稱能簡化管理的工具，但介紹這個工具就得需要另外一篇文章了。