7. Switchover and Failover

Data Guard 的角色切換可以分為 Switchover 與 Failover 兩種， Switchover 指的是 Primary 與 Standby 的角色互換，例如原本的 Primary 為 orcl 、 Standby 為 orcls ，在進行完 Switchover 之後 Primary 變為 orcls 、 Standby 變為 orcl ，並且繼續同步，不會破壞原本 Data Guard 的機制， Switchover 使用上都是有計畫性的，例如 Primary 需要停機做維護，此時不想讓服務停止太久就可以使用 Switchover 將 Standby 轉換為 Primary 並且將服務導向這邊，等到原本的 Primary 維護完成後再切換回來； Failover 指的是直接將 Standby Activate 起來，使用的時機是在 Primary 無法使用時，將 Standby 緊急轉換為新的 Primary 所用，這種情況大多都是未預期事件所造成， Failover 會切斷原本 Primary 與 Standby 的同步機制，當 Standby 轉換為新的 Primary 之後就無法再接續同步，進行完 Failover 之後， Data Guard 的架構要重新建立。 Switchover 與 Failover 同樣是把 Standby 轉換為 Primary ，其中最大的差別就是 Switchover 不會破壞 Data Guard 的同步，而 Failover 則是會破壞 Data Guard 的架構。

• Switchover

進行 Switchover 需要到 Primary 與 Standby 分別進行操作，如果是 RAC Database 的話，須先將其它的 Instance 停下，只留下一個 Instance 進行操作，首先將原本的 Primary 轉換為 Standby 並且重啟至 mount 狀態 :

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

然後再到原本的 Standby 進行轉換為 Primary ，並且將資料庫 open :

SQL> alter database commit to switchover to primary; SQL> alter database open;

完成 Switchover 切換後可以從 v$database 確認資料庫是屬於哪一個角色 :

SQL> select database_role from v$database;

確認完成後於新的 Standby 開啟 MRP 繼續進行同步。

如果有使用 Data Guard Broker 的話， Switchover 只需要一個簡單的命令就可以完成，例如原本的 Primary 為 orcl 、 Standby 為 orcls ，透過 Broker 將 orcls 轉為 Primary 、 orcl 轉為 Standby :

$ dgmgrl sys/welcome1@orcl DGMGRL> switchover to 'orcls';

完成後以 show configuration 確認即可，這邊要注意的是，登入 dgmgrl 必須要提供完整的 sys 使用者名稱與密碼，如果沒有提供密碼，那麼 Broker 就無法登入到資料庫完成重啟的動作，此時就必須再回到上述 SQL*Plus 的操作來完成。

在 Oracle 12c 之後， SQL*PLUS 對於 Switchover 的命令進行簡化，只需要在 Primary 執行一個命令即可 :

SQL> alter database switchover to orcls verify;    (使用 verify 先進行切換前檢查) SQL> alter database switchover to orcls;    (實際進行切換)

這個命令在執行了 switchover 之後， Primary 與 Standby 的角色就會進行互換，最後需要做的是將新的 Standby (原本的 Primary) 重啟到 mount 、新的 Primary (原本的 Standby) 將其 open 。

• Failover

進行 Failover 等於是把 Primary 與 Standby 的關係切斷，直接將 Standby 變成 Primary 開起來用，一般都是在 Primary 不可用時且非得以的情況下才會進行 Failover ，由於 Primary 已不可用，所以 Failover 操作上只需在 Standby 端進行，首先將 MRP 停止並且執行 Finish 的動作 :

SQL> alter database recover managed standby database cancel; SQL> alter database recover managed standby database finish force;

執行了 Finish 動作表示告訴 Data Guard 即將要執行 Failover ，它會 Apply 當下 Standby Redo Log 所有的資料並且切斷 RFS ，一旦執行了 Finish 就無法再重新啟動 MRP 了， Finish 之後就可以將 Standby Activate 起來並且 open ，完成 Failover 的操作 :

SQL> alter database activate standby database; SQL> alter database open;

如果是使用 Data Guard Broker ，那麼只需連線到 Standby 執行簡單的 Failover 指令即可 :

$ dgmgrl sys/welcome1@orcls DGMGRL> failover to 'orcls';

執行了 Failover 之後， Primary 與 Standby 的關係就會被切斷，若要還原成原本的 Data Guard 架構就必須要重建 Standby 。

6. Snapshot Standby

Snapshot Standby 是 Oracle 11g 開始有的新功能，主要是可以將 Standby Database 開啟為 read / write 模式又不會破壞原本 Data Guard 的機制，傳統的 Standby Database 都是處於 mount 狀態下進行 Log Apply ，即便是 open 也只能在唯讀 (read only) 模式，對於有讀寫需求的 Application 就無法在 Standby Database 上進行測試或者是驗證 Standby 的資料與功能，而 Snapshot Standby 就可以解決這個問題。

以往建立的 Standby Database 總會讓人有個疑問，懷疑這個 Standby 的功能是否正常，資料是否正確，萬一有天 Primary 發生問題時， Standby Database 是否可以馬上承接所有的業務 ? 而 Snapshot Standby 正好可以將 Standby 開啟為 read / write 模式進行這些驗證，等到驗證完畢後再還原回原本的 Physical Standby 繼續進行 Data Guard 的同步，不僅可以消除對 Standby Database 的顧慮，同時也不會破壞原本 Data Guard 的機制，可以說是一舉兩得的功能。

Snapshot Standby 開啟為 read / write 模式又不會破壞原本的 Data Guard 機制，主要是使用資料庫 Flashback 的特性來達到這個目的，在 Standby Database 轉換為 Snapshot Standby 的同時，會自動 Enable Flashback Database 的功能，並且同時建立 Restore Point ，在 Snapshot Standby 轉換回 Physical Standby 時，就會使用 Flashback Database 這個功能將 Standby Flashback 回到 Restore Point ，然後再從 Restore Point 這個時間點繼續進行 Data Guard 的同步，由於使用了 Flashback ，所以在 Snapshot Standby 開啟為 read / write 時的所有異動都會被還原，也因此不會影響到原本 Data Guard 的同步。

將 Physical Standby 轉換為 Snapshot Standby 只需要幾個簡單的命令就可以完成，由於會啟用 Flashback Database 功能，所以先要確認 Recovery Area 的相關參數是否已經設置 :

準備完成後就可以停止 MRP :

SQL> alter database recover managed standby database cancel;

然後執行轉換至 Snapshot Standby ，並且將 Database Open :

SQL> alter database convert to snapshot standby; SQL> alter database open;

轉換完成後可以由 v$database 查得 Database Role 為 Snapshot Standby 並且為 Read Write 模式:

轉換回 Physical Standby 必須將 Standby 重啟至 mount 狀態進行轉換，完成後再啟動 MRP :

SQL> shutdown immediate SQL> startup mount SQL> alter database convert to physical standby; SQL> alter database recover managed standby database disconnect;

如果是使用 Data Guard Broker ，只需簡單執行 convert 動作就好 :

DGMGRL> convert database 'orcls' to snapshot standby;   (轉換 orcls 為 snapshot standby) DGMGRL> convert database 'orcls' to physical standby;   (轉換 orcls 回 physical standby)

使用 Data Guard Broker 執行轉換之後，由 show configuration 可以看到 orcls 的角色變為 Snapshot Standby :

最後要注意的是，由於 Snapshot Standby 使用的是 Flashback Database 功能，因此開啟後的異動要注意 Recovery Area 的空間是否足夠容納 Flashback Log ，當開啟時間越久以及異動量越大，那麼 Recovery Area 需要的空間就越大，由於 Snapshot Standby 使用的是 Guarantee Restore Point ，所以當 Recovery Area 空間不足時就無法再進行任何操作了。

5. Data Guard Broker

Data Guard Broker 為 Oracle 10g 開始有的一個工具，主要的用途是透過一個統一的介面來管理 Data Guard 架構，在沒有使用 Data Guard Broker 時，檢查 Data Guard 必須登入 Primary Database 查詢 Archive Log 的序號，然後再登入到 Standby Database 檢查 Archive Log Apply 的序號是否已經跟上 Primary ，或是檢查 Primary 與 Standby 的 Alert Log 來確認 Data Guard 同步的機制是否正常；在有了 Data Guard Broker 之後，管理 Data Guard 就只需要透過一個統一的介面與簡單的命令就可以完成這些檢查，在 Data Guard 的維護與管理上省去很多麻煩。除此之外， Data Guard Broker 也可以幫助我們設定 Data Guard ，透過 Data Guard Broker 將不再需要自行手動設定 Data Guard 的相關參數，我們要做的只需要完成 Standby Database 的初始化，那些參數的設定就交給 Data Guard Broker 處理吧。

在使用 Data Guard Broker 前必須先做一些設定，首先必須於資料庫中設定 Data Guard Broker 的參數:

NAME                            TYPE       VALUE -------------------------- --------- -------------------- dg_broker_config_file1      string     /u01/dg/dr1orcl.dat dg_broker_config_file2      string     /u01/dg/dr2orcl.dat dg_broker_start              boolean    TRUE

dg_broker_config_file 為 Data Guard Broker 的設定檔位置，在啟動 Broker 之後會自動產生檔案，預設會放在 $ORACLE_HOME/dbs 目錄底下，如果是 RAC 環境，必須更改位置到節點可以 Shared 的目錄； dg_broker_start 參數設定為 TRUE 表示啟用 Data Guard Broker ，啟用之後資料庫會產生一個 DMON Process (Data Guard Monitor Process) 。

設定完參數之後，接下來要替資料庫新增一組靜態註冊到 listener 給 Broker 所用，這組 listener 註冊的名稱必須為 <db_unique_name>_DGMGRL ， Data Guard Broker 在執行角色切換的時候，預設會使用這組 Service Name 來連線到 Primary 與 Standby Database 進行資料庫的重啟，在 Oracle 12c 以後，如果有安裝 GI ，那麼 Data Guard Broker 會透過 GI 來重啟 Primary 與 Standby ，此時不需要設定 <db_unique_name>_DGMGRL ；如果沒有使用 GI ，那就還是要設定 <db_unique_name>_DGMGRL 這組 Service Name :

Primary 端的 listener.ora 設定: SID_LIST_LISTENER =   (SID_LIST =     (SID_DESC =       (GLOBAL_DBNAME = orcl_DGMGRL)       (ORACLE_HOME = /u01/app/oracle/product/19.3.0/dbhome_1)       (SID_NAME = orcl)     )   ) Standby 端的 listener.ora 設定: SID_LIST_LISTENER =   (SID_LIST =     (SID_DESC =       (GLOBAL_DBNAME = orcldg_DGMGRL)       (ORACLE_HOME = /u01/app/oracle/product/19.3.0/dbhome_1)       (SID_NAME = orcl)     )   )

進行 listener reload 讓設定生效 :

$ lsnrctl reload

在 Standby 完成初始化之後，便可以利用 Data Guard Broker 將 Primary 與 Standby 的關係建立起來，其中除了 log_archive_dest_1 參數需自行設定外，其餘的參數就交由 Data Guard Broker 來設定，以 dgmgrl 登入 Primary 資料庫建立 Data Guard 設定:

$ dgmgrl sys/welcome1@orcl_p DGMGRL> create configuration 'ORCL_DG' as primary database is 'orcl' connect identifier is orcl_p;

參數說明如下:

create configuration 'ORCL_DG' 建立 Data Guard 的設定，自行命名，在此設定為 orcl_dg 。

primary database is 'orcl' 設定 Primary Database ，這邊使用的是 Primary Database 的 db_unique_name ，為 orcl 。

connect identifier is orcl_p 設定 Primary Database 的連線，使用的是 tnsnames.ora 的連線設定。

建立好 Configuration 之後，再把 Standby Database 加入進來:

DGMGRL> add database 'orcldg' as connect identifier is orcl_s maintained as physical;

參數說明如下:

add database 'orcldg' 新增 Standby Database orcldg ，這邊使用的是 Standby Database 的 db_unique_name 。

connect identifier is orcl_s 設定 Standby Database 的連線，使用的是 tnsnames.ora 的連線設定。

maintained as physical 表示這是 Physical Standby 。

最後將 Data Guard Broker 的設定啟用，這樣就完成了 Data Guard 的設定 :

DGMGRL> enable configuration;

觀察 Data Guard 的狀態只需要透過 Broker 執行 show configuration ，就可以檢查 Data Guard 的機制是否正常:

$ dgmgrl / DGMGRL> show configuration;

基本上看到 SUCCESS 且沒有其它的告警訊息就是正常。

透過 show database 指令可以查詢 Data Guard 成員的詳細資訊:

DGMGRL> show database verbose 'orcl';  (查詢 Primary 資料庫 orcl 資訊) DGMGRL> show database verbose 'orcldg';  (查詢 Standby 資料庫 orcldg 資訊)

如果是 RAC 資料庫，則可以更進一步地用 show instance 來查詢每個 Instance 的詳細資訊:

DGMGRL> show instance verbose 'orcl1' on database 'orcl';   (查詢 RAC Primary 資料庫 orcl 第一個 Instance orcl1 的資訊) DGMGRL> show instance verbose 'orcldg2' on database 'orcldg';   (查詢 RAC Standby 資料庫 orcldg 第二個 Instance orcldg2 的資訊)

經由 show database 或 show instance 可以看到 StaticConnectIdentifier 的設定，這個就是 Data Guard Broker 在執行角色切換時會使用的連線字串，預設使用的 Service Name 為 <db_unique_name>_DGMGRL ，這也就是為什麼前面一開始要在 Listener 增加一組靜態註冊的原因，如果沒有這個 Service Name ，那麼透過 Broker 在執行切換時便會無法連線到 Primary 與 Standby 執行 DB 重啟的動作，這時候就要手動介入將 DB 完成重啟，以及切換的後續步驟。

show database verbose 上面所看到的設定都可以用 set property 指令來更改，例如更改 ArchiveLagTarget 這個設定為 300 :

DGMGRL> edit database 'orcl' set property 'ArchiveLagTarget' = 300;

在 Data Guard Broker 啟動之後，會於 Listener 上面自動註冊一組 <db_name>_DGB 的 Service Name ，這是 Broker 預設所使用的 Service Name ，到了 Oracle 12c 之後，這個名稱預設變為 <db_name>_CFG ，這個設定可以從 show configuration verbose 裡面的 ConfigurationWideServiceName 看到 :

Data Guard Broker 除了可以用來檢查狀態之外，也可以用來進行 Data Guard 的相關操作 :

DGMGRL> edit database 'orcl' set state = 'TRANSPORT-OFF'; DGMGRL> edit database 'orcl' set state = 'TRANSPORT-ON';   (Primary Database orcl 停止/開始 傳送 archive log)   DGMGRL> edit database 'orcldg' set state = 'APPLY-OFF'; DGMGRL> edit database 'orcldg' set state = 'APPLY-ON';   (Standby Database orcldg  停止/啟用  MRP)

Data Guard 的維護上如果沒有使用 Broker ，那麼 DBA 就必須要透過 SQL*Plus 登入 Primary 與 Standby 來檢查狀態，或是撰寫一些腳本來檢查，有了 Data Guard Broker 之後，只需要執行一個 show configuration 指令就可以完成檢查，相較之下變的簡單許多，最後要注意的是，使用了 Data Guard Broker 之後，與 Data Guard 相關的參數就不建議再透過 SQL*Plus 使用 alter system 更改，這些參數一律交由 Broker 管理，如果有變更的需要，那也必須經由 Broker 的 DGMGRL 使用 set property 指令來更改，否則有可能因為實際的參數設定與 Broker 所記錄的參數設定不同導致 Broker 產生一些錯誤。

4. 建立 Logical Standby

自 Oracle 10g 開始，建立 Logical Standby 都需要先把它建成 Physical Standby ，然後再 convert 為 Logical Standby 。

Physical Standby 轉成 Logical Standby 之前，有幾個步驟需要先進行設定，首先停止 Physical Standby 的 log apply :

SQL> alter database recover managed standby database cancel;

接下來於 Primary 資料庫 Build Logminer Directory ，由於 Logical Standby 使用的是 SQL Apply ，這邊會透過 Logminer 功能於 Redo Log 擷取 SQL Statement ，因此需要 Build Logminer Directory 讓 Logminer 得以進行，執行 BUILD 之後會同時 enable supplemental log 並且等到當下所有 transaction 完成 :

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

最後添加參數 LOG_ARCHIVE_DEST_3 ， Logical Standby 使用的是 SQL Apply ，資料庫的狀態為 open read write ，在 Apply 的過程中除了接收 Primary 傳過來的 Redo Log ，自己也會同時產生屬於自己的 Redo Log ，因此需要多設定一個 Archive Log 路徑才存放 Logical Standby 自己產生的 Archive Log ，鑒於有可能會做角色切換， LOG_ARCHIVE_DEST_3 需要同時在 Primary 與 Standby 進行設定 :

SQL> alter system set log_archive_dest_3='location=/u01/arch/standby VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLES) DB_UNIQUE_NAME=orcldg'; SQL> alter system set log_archive_dest_state_3='enable';

VALID_FOR 參數 STANDBY_LOGIFLES 表示只有 Standby Redo Log 適用此設定； STANDBY_ROLES 表示只有在角色為 Standby 時才套用此設定。

DB_UNIQUE_NAME 參數，在 Standby 端設定時為 Standby 的 unique name (orcldg) ；在 Primary 設定時為 Primary 的 unique name (orcl) 。

前置設定完成後，就可以轉換為 Logical Standby ， Logical Standby 為 open read write 模式，可以視為是一個獨立的資料庫，資料庫名稱要與 Primary 不同，因此從 Physical Standby convert 過來的同時需要賦予 Logical Standby 資料庫一個新的 DB Name ，這邊給予 orcls ，轉換時 Standby 資料庫要處於 mount 狀態然後執行 :

SQL> alter database recover to logical standby orcls;

由於 Standby 的 DB Name 已經改變，因此原先的 password file 已不可用，需要重建 password file ，假設 Standby 的 SID 維持 orcl ，使用 orapwd 重建 password file :

$ orapwd file=/opt/app/oracle/product/11.2.0.4/dbhome_1/dbs/orapworcl password=welcome1

Convert 完之後將 Logical Standby 開啟至 read write 模式 :

SQL> alter database open resetlogs;

最後啟動 logical apply :

SQL> alter database start logical standby apply immediate;

啟動 logical apply 之後可以從以下命令查詢相關訊息:

SQL> select sequence#, first_time, next_time, dict_begin, dict_end  from dba_logstdby_log order by sequence#; (查詢傳送過來的 archive log 是否有被 Standby register) SQL> select name, value from v$logstdby_stats where name = 'coordinator state';       (查詢 log 是否已 apply) SQL> select type, high_scn, status from v$logstdby; SQL> select applied_scn, latest_scn from v$logstdby_progress;       (查詢 SQL Apply Status)

由於 Logical Standby 是使用 SQL Apply ，有些物件以及 Data Type 是不支援同步的，例如 Materialized View 、 XML Data Type 、 LOB Data Type …等是沒有支援的，可以從 dba_logstdby_unsupported_table 查詢 Logical Standby 裡面有哪些物件是沒有被支援的 :

SQL> select * from dba_logstdby_unsupported_table order by owner;

Logical Standby 早期多是運用在資料庫的 rolling-upgrade 以減少升級過程中服務停止的時間，而同樣是 SQL Apply 的功能， Logical Standby 如今漸漸的被 Oracle 的另一項產品 Golden Gate 取代，實務上 Logical Standby 已經很少使用。

3. 建立 Physical Standby

建立 Physical Standby 的流程大致如下:

前置作業設定 🡪 資料庫參數設定 🡪 初始化 Standby 🡪 開啟 MRP 同步

• 前置作業設定

在進行 Physical Standby 建置之前，有幾個前置作業必須要先進行，首先 Primary 資料庫必須是 Archive Log Mode ，並且啟用 force logging :

SQL> alter database force logging; SQL> select force_logging from v$database; (進行確認)

於 Primary 資料庫添加 Standby Redo Log ， Standby Redo Log 在 Primary 資料庫上是沒有任何用途的，不過考量未來有可能進行 Data Guard 的角色切換， Primary 有可能切換為 Standby ，因此在這邊就先幫 Primary 添加 Standby Redo Log ，除此之外，在 Primary 先添加的好處是，在資料庫初始化階段也會把 Standby Redo Log 的設定帶過去，到時候 Standby Database 就不用再加一次了。 Standby Redo Log 的 Group 數量與大小至少要與 Primary 的 Online Redo Log 數量相同:

SQL> alter database add standby logfile group 4 '/u01/oradata/orcl/stdby_redo01.log' size 200M; SQL> alter database add standby logfile group 5 '/u01/oradata/orcl/stdby_redo02.log' size 200M; SQL> alter database add standby logfile group 6 '/u01/oradata/orcl/stdby_redo03.log' size 200M;

如果是 RAC Database ，則每個節點都必須添加 Standby Redo Log :

SQL> alter database add standby logfile thread 1 group 4 '/u01/oradata/orcl/stdby_redo01.log' size 200M; SQL> alter database add standby logfile thread 1 group 5 '/u01/oradata/orcl/stdby_redo02.log' size 200M; SQL> alter database add standby logfile thread 1 group 6 '/u01/oradata/orcl/stdby_redo03.log' size 200M; SQL> alter database add standby logfile thread 2 group 7 '/u01/oradata/orcl/stdby_redo04.log' size 200M; SQL> alter database add standby logfile thread 2 group 8 '/u01/oradata/orcl/stdby_redo05.log' size 200M; SQL> alter database add standby logfile thread 2 group 9 '/u01/oradata/orcl/stdby_redo06.log' size 200M;

接下來於 tnsnames.ora 添加 Primary 與 Standby Database 的連線設定:

ORCL_P =   (DESCRIPTION =     (ADDRESS_LIST =       (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.49.250)(PORT = 1521)))     (CONNECT_DATA =       (SERVER = DEDICATED)       (SERVICE_NAME = orcl))) ORCL_S =   (DESCRIPTION =     (ADDRESS_LIST =       (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.49.150)(PORT = 1521)))     (CONNECT_DATA =       (SERVER = DEDICATED)       (SERVICE_NAME = orcldg)))

ORCL_P 代表為 Primary 資料庫， ORCL_S 表示為 Standby ， Primary 端與 Standby 端的 tnsnames.ora 都需要設定。

最後將 Primary 資料庫的 password file 複製到 Standby 端，這邊要注意的是，如果 Standby 端的 SID 與 Primary 不同，則複製過去的 password file 必須修改為 Standby 端的 SID 名稱。

• 資料庫參數設定

建立 Data Guard 有幾個相關的參數設定，首先在 Primary 端設定參數如下:

SQL> alter system set log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles) db_unique_name=orcl'; SQL> alter system set log_archive_dest_state_2='defer'; SQL> alter system set log_arcihve_dest_2='service=orcl_s lgwr async noaffirm optional reopen=180 valid_for=(online_logfiles,primary_role) db_unique_name='orcldg'; SQL> alter system set log_archive_config='dg_config=(orcl,orcldg) '; SQL> alter system set standby_file_management='AUTO'; SQL> alter system set fal_server='orcl_s'; SQL> alter system set fal_client='orcl_p';

log_archive_dest_1 表示本地 Primary 的 archive log 存放位置，除了原本的 location 參數外，須加上 valid_for 參數， all_logfiles 表示所有的 redo log 都適用此設定、 all_roles 表示資料庫在任何角色都適用此設定； db_unique_name 設定 Primary 資料庫的 unique name ，為 orcl 。

log_arcihve_dest_2 表示添加另一個 archive log 路徑， service=orcl_s 表示 archive log 使用 service name 傳送過去，這邊設定 orcl_s 表示傳送到所設定的 standby 資料庫； lgwr async 表示使用 lgwr 這個 process 並且以 async 模式進行傳送； noaffirm 表示在 Standby 接收到交易之後，不等它寫入到 Standby Redo Log 就當作是完成傳送； optional reopen=180 表示傳送失敗後，等待 180 秒之後進行 retry ； valid_for 參數， online_logfiles 表示只有 Online Redo Log 適用此設定、 primary_role 表示資料庫只有在為 Primary 時才套用此設定； db_unique_name 設定 Standby 資料庫的 unique name ，為 orcldg 。

log_archive_dest_state_2 先設為 defer ，由於 Standby 資料庫還沒建立起來，因此在這一階段的 Primary 先不用進行 archive log 傳送。

log_archive_config 設定 Data Guard 裡面的成員名單， dg_config 設定的是資料庫的 unique name ，代表目前 Data Guard 總共有兩個成員， orcl 與 orcldg 。

當 Primary 與 Standby 有 archive log gap 時，就必須透過 FAL 機制來補足缺少的 archive log ， fal_server 設定的是對面的資料庫，這邊是 Primary 所以設定 fal_sever 為 Standby 的連線字串 orcl_s ； fal_client 設定的是自己的連線字串 orcl_p 。

在 Primary 端設定完參數之後，接下來就要建立 Standby 端的參數，由 Primary 建立 pfile 之後，然後進行微調如下，作為 Standby 端的參數 :

*.log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles) db_unique_name=orcldg'; *.log_archive_dest_state_2='defer'; *.log_arcihve_dest_2='service=orcl_p lgwr async noaffirm optional reopen=180 valid_for=(online_logfiles,primary_role) db_unique_name='orcl'; *.db_unique_name='orcldg' *.log_archive_config='dg_config=(orcl,orcldg)'; *.standby_file_management='AUTO'; *.fal_server='orcl_p'; *.fal_client='orcl_s';

log_archive_dest_1 的 unique name 改為 Standby 端的 orcldg ，其餘相同。

log_archive_dest_2 的 service 改為 orcl_p ，當有一天做角色切換時， archive log 要反過來傳送回 orcl_p ； unique name 改為 Primary 端的 orcl ，其餘設定相同。

db_unique_name 須設定與 Primary 不同，這邊 Standby 設定為 orcldg 。

standby_file_management 須設定為 AUTO ，表示當 Primary 有進行 Data File 增減時， Standby 端自動的同步增減。

fal_server 與 fal_client 則與 Primary 反過來設定。

在兩邊的參數都設定好之後，接下來就可以進行 Standby 資料庫的初始化。

• Standby 資料庫初始化

Standby 資料庫的初始化大致上可以使用下列幾個方法來進行:

 1. Cold Backup 

  Standby 資料庫本質上是與 Primary 相同的，因此如果 Primary 在可以 Shutdown 停止的情況下，只要在 Primary 建立一個 Standby Control File ，並且將 Standby Control File 與所有的 Data File 複製到 Standby 端，這樣就完成一個 Standby 的初始化。

SQL> alter database create standby controlfile as '/tmp/stdby_control01.ctl'

2. RMAN Backup Restore

  在多數的情況下， Primary 是無法停止的，因此 1 的理想方式可以使用的機會不多，在 Primary 還在運行的情況下，可以使用 RMAN Backup 先將 Primary 備份起來，然後將備份檔案傳送到 Standby 端進行 Restore ，在 Primary 備份的時候，要把 Control File 備份為 Standby Control File :

run { allocate channel ch1 type disk; backup database format '/opt/app/dump/rman/fulldb_%s_%t'; backup current controlfile for standby format '/opt/app/dump/rman/controlfile_%s_%t'; release channel ch1; }

Primary 備份完之後將備份檔傳送到 Standby 進行 Restore :

RMAN> startup nomount RMAN> restore standby controlfile from '/opt/app/dump/rman/controlfile_13_10850313'; RMAN> sql 'alter database mount'; RMAN> restore database;

Restore 結束後便完成了 Standby 的初始化。

3. 使用 duplicate from active database

  使用 2 來進行初始化的缺點是，如果資料庫比較龐大，而 Standby 端又沒有那麼大的空間來存放備份檔，那麼 RMAN Backup Restore 將難以進行，從 Oracle 11gR2 開始可以使用 duplicate from active database 來建立 Standby ，好處是直接透過 Oracle Net 還原 Standby ，不需要額外的空間來存放落地的備份檔，在進行 duplicate from active database 之前， Standby 要設定可以使用 RMAN auxiliary 連線，為了這個連線，要於 Standby 的 listener.ora 設定一組靜態註冊如下:

SID_LIST_LISTENER =   (SID_LIST =     (SID_DESC =       (GLOBAL_DBNAME = orcl)       (ORACLE_HOME = /opt/app/oracle/product/11.2.0.4/dbhome_1)       (SID_NAME = orcl)))

將 Standby 資料庫開啟至 nomount 之後，使用 RMAN 連線至 target (primary) 與 auxiliary (standby) ，這邊要注意的是，連線的時候必須提供 sys 的帳號密碼，不可使用 "/" 登入，否則會 duplicate 失敗:

$ rman target sys/welcome1@orcl_p auxiliary sys/welcome1@orcl_s

然後就可以進行 duplicate from active database :

run { allocate channel prmy1 type disk; allocate auxiliary channel stby type disk; duplicate target database for standby nofilenamecheck from active database; }

duplicate 結束後就完成了 Standby 的初始化。

4. 使用 Restore from Service

  Oracle 12c 開始添加了新功能 Restore from Service ，比起原先 duplicate from active database 方便的是無須再使用 auxiliary 連線，整體操作起來更為方便。將 Standby 開啟至 nomount 之後便可以進行 Restore from Service ，與 3 不同的是， duplicate from active database 無需自行 Restore Standby Control File ，而 Restore from Service 必須先 Restore Standby Control File :

$ rman target sys/welcome1@orcl_s RMAN> restore standby controlfile from service orcl_p; RMAN> alter database mount; RMAN> restore database from service orcl_p; RMAN> switch database to copy;

如果 Primary 的 Data File 使用的是 OMF 格式的話，那麼 Restore from Service 結束後必須再執行 switch database to copy 。

• 開啟 MRP 同步

在 Standby 初始化完成之後，接下來就可以進行同步，首先要先開啟 Primary 的 log shipping ，將參數 log_archive_dest_state_2 改為 enable 開始傳送 archive log :

SQL> alter system set log_archive_dest_state_2='enable';

然後至 Standby 開啟 MRP :

SQL> alter database recover managed standby database using current logfile disconnect;

使用 using current logfile 表示啟用 real-time apply ，不過至 Oracle 12c 開始，預設已經是 real-time apply 了，不用特別再使用 using current logfile 。

如果要啟用 Active Data Guard ，則必須把 Standby 開啟後再進行 apply :

SQL> alter database recover managed standby database cancel; SQL> alter database open; SQL> alter database recover managed standby database using current logfile disconnect;

檢查 Standby 的同步狀態，可以簡單的由 Standby 查詢 v$archive_log 來檢視 archive 序號是否有持續同步:

SQL> select sequence#, applied, first_time, next_time from v$archived_log  where applied='YES' order by sequence#;

如果 Standby 的 archive log 序號沒有與 Primary 同步，那麼就要同時檢視 Primary 與 Standby 的 alert log ，從中找尋發生問題的原因。

Archive Log 在 Data Guard 架構下，只要被使用過後就不會再需要了，可以將其刪除，對於 Primary 來說，只要 Archive Log 傳送到了 Standby 端，那麼對於 Data Guard 來說，這些 Archive Log 就不需要了，可以將這些已經傳送到 Standby 端的 Archive Log 刪除，一般來說 Primary 在使用 RMAN 備份的時候就會順便將 Archive Log 刪除，如果備份刪除到還未傳送到 Standby 的 Archive Log 時，就會出現 RMAN-08137: warning: archived log not deleted, needed for standby or upstream capture process 這個錯誤來防止 Archive Log 被刪除，除非使用 force 指令強制刪除，不然未傳送到 Standby 端的 Archive Log 是無法刪除的，這也算是 RMAN 對於 Data Guard 的一種保護機制吧。

對於 Standby 端來說，只要 Archive Log 被 Apply 之後就沒有作用了，可以將這些已經 Apply 的 Archive Log 刪除，可以透過 RMAN 設定一個排程來定期刪除這溪 Archive Log ，例如建立一個 del_arch.sh 來定期刪除兩天前的 Archive Log :

export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/11.2.0.4/dbhome_1 export PATH=$ORACLE_HOME/bin:$PATH export ORACLE_SID=orcl rman target / <<EOF delete noprompt archivelog until time 'sysdate - 2'; exit; EOF

如果 Archive Log 是設定在 Recovery Area 裡面，那麼就可以透過 RMAN設定 Archive Deletion Policy 來自動的刪除 Archive Log ，對於 Primary 來說，只要 Archive Log 已經傳送到 Standby 就可以刪除，所以設定為 shipped to all standby :

RMAN> configure archivelog deletion policy to shipped to all standby;

對於 Standby 來說，已經 Apply 的 Archive Log 就可以刪除，所以是 applied on standby :

RMAN> configure archivelog deletion policy to applied on standby;

設定完後在 RMAN 裡面可以使用 show all 指令來檢查設定，這邊要注意的是， RMAN 的 Archive Log Deletion Policy 只有在 Recovery Area 的空間即將額滿時才會觸發刪除 Archive Log 的動作，所以設定完沒有看到 Archive Log 被刪除並不是這個設定無效，而是 Recovery Area 的空間還沒有達到需要刪除這些檔案的臨界值。

Data Guard 架構下的 Archive Log 是需要定期維護清理的，如果 Standby 沒有安排清理，那麼這些 Archive Log 就會一直累積直到系統空間不足為止，刪除 Archive Log 的方式建議一律使用 RMAN 來清理，不要使用作業系統的指令例如 rm 來刪除 Archive Log ，避免誤刪了還沒被使用到的 Archive Log 造成 Data Guard 異常。