Oracle 12c DG新特性Far Sync

Oracle的Data Guard技術再11g中有了Active Data Guard，就產生了很多的技術解決方案，比如讀寫分離，多活的技術支撐等。

12c 中又有了一些改進，那就當屬Far Sync。以下是來自官網提供的一張圖，看起來很威武霸氣。
這個Far Sync到底是個什麼東東，主要就是為了解決遠距離的資料傳輸延遲，而在中間節點建立的一個虛例項，這個例項很特別，只有引數檔案，密碼問價和控制檔案，而且需要特別強調的是沒有資料檔案。

當然這個特性是一個補充，你如果使用原本的Active Data Guard也全然沒有問題。而這個特性可以透過中間節點來過渡，達到了官方所宣稱的0資料丟失。

這個特性是不是非常牛叉呢，其實如果大家瞭解Data Guard的一些知識，會發現其實這個Far Sync就是cascade standby的一個改進，所以我沒有說是一個技術上很大的一個創新。

如果已經有了Active Data Guard的環境，啟用Far Sync那就很簡單了。

下面是一個典型的DG配置情況，使用了DG Broker來統一配置管理。主庫是testdb,備庫是testdb2

DGMGRL> show configuration
Configuration - dgb_testdb
  Protection Mode: MaxPerformance
  Members:
  testdb  - Primary database
    testdb2 - Physical standby database 
Fast-Start Failover: DISABLED
Configuration Status:
DISABLED 

需要特別強調的是，Far Sync的新增一個關鍵就是控制檔案，這個和備庫控制檔案有所區別。如果你使用的是備庫控制檔案，那很可能新增的時候得到下面的錯誤。

DGMGRL> add far_sync testdbf as connect identifier is testdbf;
Error: ORA-16831: operation not allowed on this member
檢視錯誤資訊，也是一頭霧水，日誌中也沒有什麼明顯的資訊。
[oracle@teststd ~]$ oerr ora 16831
16831, 00000, "operation not allowed on this member"
// *Cause:  The Oracle Data Guard broker operation was not allowed for the 
//          specified member of the Oracle Data Guard broker configuration.
// *Action: Check the documentation for the Oracle Data Guard broker command 
//          and then reissue the command with the correct member.

我剛開始玩的時候大意了，結果因為這個問題給折騰了不少時間。需引以為戒。

正確的姿勢是在主庫生成Far Sync的控制檔案：

SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/tmp/controlfs01.ctl1';
Database altered.   
然後複製到備庫還原即可。
備庫執行:
RMAN> restore controlfile from '/tmp/controlfs01.ctl1';
RMAN> alter database mount;

很重要的一個檢查項就是檢查v$database,輸出全然不同

SQL> select database_role,name,db_unique_name from v$database
DATABASE_ROLE                  NAME                        DB_UNIQUE_NAME
------------------------------ --------------------------- -----------
FAR SYNC                       TESTDB                      testdbf 

這樣就對了，我們再次在主庫新增：

新增Far Sync節點：
DGMGRL> add far_sync TESTDBF as connect identifier is TESTDBF;
far sync instance "testdbf" added  
啟用配置 
DGMGRL> enable far_sync TESTDBF;
Enabled. 
檢視配置情況:
DGMGRL> DGMGRL> show configuration;
Configuration - dgb_testdb
  Protection Mode: MaxPerformance
  Members:
  testdb  - Primary database
    testdb2 - Physical standby database 
    testdbf - Far sync instance 
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 5 seconds ago) 

Far Sync的節點就這樣搞定了。其實就是中間走了一層轉接，而對於Far Sync而言，使用DG Broker搭建就是兩條簡單的命令即可。其實在後臺日志中是設定歸檔路徑引數：

Sat Oct 29 23:21:23 2016
ALTER SYSTEM SET log_archive_dest_3='service="testdbf"','ASYNC NOAFFIRM delay=0 optional compression=disable max_failure=0 max_connections=1 reopen=300 db_unique_name="testdbf" net_timeout=30','valid_for=(online_logfile,all_roles)' SCOPE=BOTH;
Sat Oct 29 23:21:23 2016
ALTER SYSTEM SET log_archive_dest_state_3='ENABLE' SCOPE=BOTH;

所以核心的部分就在於這兒，還有一個地方是Far Sync節點，Fal_server的設定

FAR SYNC節點：
SQL> show parameter fal
NAME                                 TYPE            VALUE                    
------------------------------------ ----------  ----------- 
fal_client                           string
fal_server                           string      testdb, testdb2          

我們可以簡單測試一下Far Sync的影響範圍：

直接shutdown abort Far Sync節點，主庫會馬上收到一條錯誤資訊:

Sat Oct 29 23:29:18 2016
Errors in file /home/U01/app/oracle/diag/rdbms/testdb/testdb/trace/testdb_tt02_8451.trc:
ORA-03135: connection lost contact

這個時候測試節點的日誌傳輸還是可以的，當然遠距離還是會把影響放大。

而在Far Sync節點恢復之後，主庫日誌會發生變化：

ERROR: Shared memory area is accessible to instance startup process
 prior to instance startup operation.
Sat Oct 29 23:32:17 2016
ALTER SYSTEM SET log_archive_dest_state_3='ENABLE' SCOPE=MEMORY SID='*'; 

再次檢視DG Broker的配置就沒有問題了。

DGMGRL> show configuration;
Configuration - dgb_testdb
  Protection Mode: MaxPerformance
  Members:
  testdb  - Primary database
    testdb2 - Physical standby database 
    testdbf - Far sync instance 
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 41 seconds ago)

這個測試的過程還是比較流暢的，還有更多的細節，後續繼續分享。