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 configurationConfiguration - dgb_testdb  Protection Mode: MaxPerformance  Members:  testdb  - Primary database    testdb2 - Physical standby database Fast-Start Failover: DISABLEDConfiguration 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 1683116831, 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$databaseDATABASE_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: DISABLEDConfiguration Status:SUCCESS   (status updated 5 seconds ago)

Far Sync的节点就这样搞定了。其实就是中间走了一层转接，而对于Far Sync而言，使用DG Broker搭建就是两条简单的命令即可。其实在后台日志中是设置归档路径参数：

Sat Oct 29 23:21:23 2016ALTER 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 2016ALTER SYSTEM SET log_archive_dest_state_3='ENABLE' SCOPE=BOTH;

所以核心的部分就在于这儿，还有一个地方是Far Sync节点，Fal_server的设置

FAR SYNC节点：SQL> show parameter falNAME                                 TYPE            VALUE                    ------------------------------------ ----------  ----------- fal_client                           stringfal_server                           string      testdb, testdb2         

我们可以简单测试一下Far Sync的影响范围：

直接shutdown abort Far Sync节点，主库会马上收到一条错误信息:

Sat Oct 29 23:29:18 2016Errors 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 2016ALTER 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: DISABLEDConfiguration Status:SUCCESS   (status updated 41 seconds ago)

这个测试的过程还是比较流畅的，还有更多的细节，后续继续分享。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2127324/，如需转载，请注明出处，否则将追究法律责任。