Oracle Data Guard Far Sync如何实现远程零数据丢失同步？

Oracle Data Guard Far Sync在Oracle Database 12c中正式出现，它并不是一个完整的备库，而是一个只包含控制文件、参数文件和Standby Redo Log的特殊实例。它的职责是接收主库传来的同步Redo流，并立即异步转发给地理位置更远的物理备库。由于Far Sync通常部署在与主库相近的数据中心，主库的COMMIT只需等待本地网络的确认，不再受到远端长距离链路的影响。

可以把Far Sync理解为一个智能中继节点，它把原来主库到远端备库的直接同步链路拆成两段：第一段是主库到Far Sync的SYNC同步，第二段是Far Sync到远端备库的ASYNC异步。这种拆分方式在最大可用性模式下尤其有价值，因为主库可以在保持零数据丢失目标的同时，避免长距离传输带来的事务延迟。

一、Far Sync的架构定位与日志流

Far Sync实例的特殊之处在于它没有数据文件，不承载任何用户表空间，也不执行恢复操作。它只维护控制文件、参数文件、密码文件以及若干组Standby Redo Log。控制文件用于记录远端备库的SCN、redo目的信息以及日志切换状态，Standby Redo Log则负责临时存放从主库接收到的Redo数据。正是因为省去了数据文件和恢复进程，Far Sync对CPU、内存和磁盘容量的要求很低，可以部署在虚拟化环境或者小型服务器上。

日志流转过程可以拆成两个阶段。主库在事务提交时，LGWR进程将Redo写入本地Online Redo Log，同时通过SYNC方式发送到Far Sync实例的Standby Redo Log。主库必须等待Far Sync确认写入成功后才返回COMMIT成功，这就是同步阶段。Far Sync随后通过ARCH进程将Standby Redo Log中的内容异步传输到远端备库，远端备库收到后执行Redo Apply或者先归档再应用。由于第二阶段是ASYNC，主库提交完全不受远端备库网络延迟和写入速度的影响。

和传统Data Guard对比，普通的最大可用性模式如果直接把远端备库配置为SYNC传输，主库的每次提交都要等待完整的长距离网络往返。一旦跨地域链路的延迟达到几十甚至上百毫秒，事务吞吐量会明显下降。Far Sync通过在中继节点完成同步确认，将主库等待窗口压缩到本地网络级别，同时远端备库仍能通过异步日志流追平到同步点，最终实现零数据丢失。

二、创建与配置Far Sync实例

创建Far Sync实例的第一步是准备Standby Redo Log。Far Sync上的Standby Redo Log组数与大小应当和主库的Online Redo Log保持一致，至少不能小于主库Redo日志大小，否则在日志切换时可能出现等待或报错。通常建议按照主库Online Redo Log的组数加一组来规划，例如主库有4组Online Redo Log，那么Far Sync至少配置5组Standby Redo Log。下面的SQL演示了如何添加一组500MB的Standby Redo Log。

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4
  ('/u01/oradata/fs_sync/srl04a.log','/u01/oradata/fs_sync/srl04b.log') SIZE 500M;

Far Sync实例本身可以通过RMAN的DUPLICATE命令从主库活动数据库复制生成，也可以从已有物理备库复制后转换角色。如果使用RMAN，可以在目标数据库和主库之间配置好网络连接后执行FOR FAR SYNC子句，RMAN会创建控制文件、参数文件并复制Standby Redo Log结构，但不会复制数据文件。创建完成后，需要确认实例只挂载不打开，并检查V$DATABASE中的数据库角色。

参数配置方面，主库需要把LOG_ARCHIVE_DEST_2指向Far Sync，并显式声明SYNC和AFFIRM属性。AFFIRM表示主库必须等待Far Sync确认Redo写入磁盘，而不是仅仅确认写入操作系统缓存。Far Sync实例上则需要将LOG_ARCHIVE_DEST_2指向远端备库，使用ASYNC属性，并使用FAR_SYNC_ROLE作为角色条件。下面是主库和Far Sync实例的关键参数示例。

-- 主库参数
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db,fs_sync,remote_standby)';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=fs_sync SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=fs_sync';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
ALTER SYSTEM SET FAL_SERVER=fs_sync;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

-- Far Sync实例参数
ALTER SYSTEM SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary_db,fs_sync,remote_standby)';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=remote_standby ASYNC VALID_FOR=(STANDBY_LOGFILES,FAR_SYNC_ROLE) DB_UNIQUE_NAME=remote_standby';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
ALTER SYSTEM SET FAL_SERVER=remote_standby;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

还需要在tnsnames.ora中配置对应的网络服务名。Far Sync实例的网络服务名应当指向它本身的监听地址，而Far Sync实例内部的tnsnames.ora需要能够解析远端备库。如果使用Oracle Restart或Clusterware管理，建议把Far Sync实例注册到集群中，以便在节点重启后自动拉起。

FS_SYNC =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = fs-sync.ipipp.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = fs_sync)
    )
  )

三、Broker管理与最大可用性模式

Data Guard Broker对Far Sync提供了原生支持，使用DGMGRL命令行工具可以很方便地把Far Sync实例加入配置。Broker会自动管理日志传输、角色切换和状态监控，尤其在配置RedoRoutes属性后，可以更清晰地描述Redo从主库到Far Sync再到远端备库的路由规则。下面的命令展示了创建一个包含主库、Far Sync和远端备库的Broker配置。

DGMGRL> CONNECT sys@primary_db
DGMGRL> CREATE CONFIGURATION dg_far AS PRIMARY DATABASE IS primary_db CONNECT IDENTIFIER IS primary_db;
DGMGRL> ADD FAR_SYNC fs_sync AS CONNECT IDENTIFIER IS fs_sync;
DGMGRL> ADD DATABASE remote_standby AS CONNECT IDENTIFIER IS remote_standby;
DGMGRL> ENABLE CONFIGURATION;
DGMGRL> EDIT DATABASE primary_db SET PROPERTY RedoRoutes='(LOCAL : fs_sync SYNC)(fs_sync : remote_standby ASYNC)';

在最大可用性模式下，主库要求至少一个同步目标返回确认。这里同步目标就是Far Sync实例，而不是远端备库。只要Far Sync在线且能够写入Standby Redo Log，主库就可以正常提交。远端备库即使临时不可达，也不会阻塞主库事务，因为Far Sync到远端备库的传输是异步的。这样既满足了零数据丢失的保护级别，又避免远端网络故障影响主库可用性。

当Far Sync实例自身发生故障时，最大可用性模式会按照既定的保护策略处理。如果主库无法连接Far Sync，并且没有其他同步目标，主库会在超时后继续处理事务，但Redo传输保护会暂时降级，直到Far Sync恢复。此时远端备库可能落后，需要监控归档日志间隔。如果业务要求绝对不允许任何事务丢失，可以考虑升级到最大保护模式，但最大保护模式会要求Far Sync必须在线，否则主库会直接停止服务。

四、监控与运维注意事项

Far Sync实例在日常运维中需要重点关注两类信息：一是主库到Far Sync的同步状态，二是Far Sync到远端备库的异步发送状态。主库上可以查询V$ARCHIVE_DEST_STATUS视图，确认LOG_ARCHIVE_DEST_2的状态是否为VALID，以及是否有传输延迟或错误。Far Sync实例上也可以查询该视图，但重点要看ASYNC目标的状态和日志序列号差距。

SELECT DEST_ID, DEST_NAME, STATUS, TYPE, DATABASE_MODE, RECOVERY_MODE, PROTECTION_MODE
FROM V$ARCHIVE_DEST_STATUS;

如果发现Far Sync上的Standby Redo Log长期处于ACTIVE状态，或者日志序列号差距持续增大，需要检查网络带宽、远端备库的磁盘写入速度以及ARCH进程数量。由于Far Sync不保存数据文件，备份策略也和普通备库不同，通常只需要备份控制文件、参数文件和密码文件。升级或打补丁时，先对主库和远端备库完成操作，再处理Far Sync实例，并确保Broker状态一致。

另外要特别注意Standby Redo Log的大小匹配。如果主库Online Redo Log为1GB，而Far Sync配置了500MB的Standby Redo Log，主库进行日志切换时可能无法将完整日志发送到Far Sync，导致归档失败或者同步目标暂时不可用。定期检查主库和Far Sync的日志组信息，确保组数和大小一致，是避免这类问题最直接的方法。

综合来看，Far Sync为跨地域Data Guard环境提供了一种非常实用的架构选择。它通过拆分同步和异步两段链路，在保证零数据丢失的前提下显著降低了主库的提交延迟。对于已经在使用Oracle Data Guard但受限于长距离网络的团队来说，把Far Sync引入现有架构，往往能带来明显的性能和可用性提升。

Oracle Data GuardFar Sync远程同步修改时间：2026-10-06 20:03:55