oracle的farsync,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)

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