An Oracle Data Guard far sync instance is a remote Oracle Data Guard destination that accepts redo from the primary database and then ships that redo to other members of the Oracle Data Guard configuration. A far sync instance manages a control file, receives redo into standby redo logs (SRLs), and archives those SRLs to local archived redo logs, but that is where the similarity with standbys ends. A far sync instance does not have user data files, cannot be opened for access, cannot run redo apply, and can never function in the primary role or be converted to any type of standby database.
Far sync instances are part of the Oracle Active Data Guard Far Sync feature, which requires an Oracle Active Data Guard license.
A far sync instance consumes very little disk and processing resources, yet provides the ability to failover to a terminal destination with zero data loss, as well as offload the primary database of other types of overhead (for example, redo transport).
All redo transport options available to a primary when servicing a typical standby destination are also available to it when servicing a far sync instance. And all redo transport options are available to a far sync instance when servicing terminal destinations (for example, performing redo transport compression, if you have a license for the Oracle Advanced Compression option).
Many configurations have a primary database shipping redo to a standby database using asynchronous transport at the risk of some data loss at failover time. Using synchronous redo transport to achieve zero data loss may not be a viable option because of the impact on the commit response times at the primary due to network latency between the two databases.
Creating a far sync instance close to the primary has the benefit of minimizing impact on commit response times to an acceptable threshold (due to the smaller network latency between primary and far sync instance) while allowing for higher data protection guarantees -- if the primary were to fail, and assuming the far sync instance was synchronized at the time of the failure, the far sync instance and the terminal standby would coordinate a final redo shipment from the far sync instance to the standby to ship any redo not yet available to the Standby and then perform a zero-data-loss failover.
This chapter contains the following sections:
Creating a far sync instance is similar to creating a physical standby except that data files do not exist at the far sync instance. Therefore, on a far sync instance there is no need to copy data files or restore data files from a backup. Once the far sync instance has been created, the configuration is modified to send redo synchronously from the primary database to the far sync instance in Maximum Availability mode and the far sync instance then forwards the redo asynchronously in real time. Lastly, the original asynchronous standby (referred to as the terminal standby) is configured to act as the alternate to the far sync instance in the event that communication with the far sync instance is interrupted.
Note:
In a configuration that contains a far sync instance, there must still be a direct network connection between the primary database and the remote standby database. The direct connection between the primary and the remote standby is used to perform health checks and switchover processing tasks. It is not used for redo transport unless the standby has been configured as an alternate destination in case the far sync instance fails and there is no alternate far sync configured to maintain the protection level.This section describes the following:
Take the following steps to create a far sync instance:
Create the control file for the far sync instance, as shown in the following example (the primary database does not have to be open, but it must at least be mounted):
SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS - > '/arch2/chicagoFS/control01.ctl';
The resulting control file enables chicagoFS to operate as a far sync instance that receives redo from primary database chicago. Note that the path and file name shown are just an example; you could use any path or file name that you want.
Create a parameter file (PFILE) from the server parameter file (SPFILE) used by the primary database. Although most of the initialization settings in the parameter file are also appropriate for the far sync instance, some modifications must be made. For example, on a far sync instance, the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters must be set, and the DB_UNIQUE_NAME of the far sync instance and the location of the far sync instance control file must be modified. Example 5-1 shows sample parameter file content for a far sync instance with a DB_UNIQUE_NAME of chicagoFS.
Example 5-1 Some of the Initialization Parameters Used For Far Sync Instances
Primary Database chicago
DB_UNIQUE_NAME=chicago CONTROL_FILES='/arch1/chicago/control01.ctl' DB_FILE_NAME_CONVERT='/boston/','/chicago/' LOG_FILE_NAME_CONVERT='/boston/','/chicago/' FAL_SERVER=boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston)' LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicago' LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS'
Far Sync Instance chicagoFS
DB_UNIQUE_NAME=chicagoFS CONTROL_FILES='/arch2/chicagoFS/control01.ctl' DB_FILE_NAME_CONVERT='/chicago/','/chicagoFS/','/boston/','/chicagoFS/' LOG_FILE_NAME_CONVERT='/chicago/','/chicagoFS/','/boston/','/chicagoFS/' FAL_SERVER=chicago LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston)' LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=chicagoFS' LOG_ARCHIVE_DEST_2='SERVICE=boston ASYNC VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=boston'
Physical Standby boston
DB_UNIQUE_NAME=boston CONTROL_FILES='/arch3/boston/control01.ctl' DB_FILE_NAME_CONVERT='/chicago/','/boston/' LOG_FILE_NAME_CONVERT='/chicago/','/boston/' FAL_SERVER='chicagoFS','chicago' LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston)' LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2='SERVICE=chicago ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
Create a server parameter file (spfile) from the edited parameter file (pfile) to facilitate any subsequent changes to parameter values. If you do not use an spfile, then a warning is returned in the SHOW CONFIGURATION output when the far sync instance is added to a Data Guard broker configuration.
Use an operating system copy utility to copy the far sync instance control file created in Step 1 and the server parameter file (spfile) created in Step 3 from the primary system to the appropriate locations on the far sync instance system.
Create standby redo logs in the same way they are created for a regular standby. See Section 7.2.3.1, "Managing Standby Redo Logs."
Because the LOG_FILE_NAME_CONVERT parameter was specified on the far sync instance (see Example 5-1), the standby redo logs will be created automatically when redo transport begins from the primary, if they were created on the primary as described in Section 3.1.3.
Note:
Standby redo log files used at the far sync instance cannot be shared with other databases. Therefore, all relevant considerations discussed in Section 2.4 for standby redo log files also apply at the far sync instance.If the far sync instance will be hosted on a Windows system, use the ORADIM utility to create a Windows service. For example:
WINNT> oradim –NEW –SID boston –STARTMODE manual
The ORADIM utility automatically determines the username for which this service should be created and prompts for a password for that username (if that username needs a password). See Oracle Database Platform Guide for Microsoft Windows for more information about using the ORADIM utility.
This step is optional if operating system authentication is used for administrative users and if SSL is used for redo transport authentication. If not, then copy the primary database's remote login password file to the appropriate directory on the far sync instance. The password file must be recopied whenever an administrative privilege (SYSDG, SYSOPER, SYSDBA, and so on) is granted or revoked, and after the password of any user with administrative privileges is changed.
If you have stored the password file in an Oracle ASM disk group at the standby database, then you must copy the updated password file from the primary database to the Oracle ASM location at the standby database. See Oracle Automatic Storage Management Administrator's Guide for information about the ASMCMD pwcopy command used to copy an Oracle ASM or database instance password file to a specified location. See Oracle Real Application Clusters Administration and Deployment Guide for information about using the srvctl utility to modify a database configuration.
On the far sync instance site, use Oracle Net Manager to configure a listener for the far sync instance.
See Oracle Database Net Services Administrator's Guide for more information about the listener.
On the primary system, use Oracle Net Manager to create a network service name for the far sync instance (chicagoFS) that will be used by redo transport services.
On the far sync instance system, use Oracle Net Manager to create a network service name for the primary (chicago) and the terminal standby (boston) that will be used by redo transport services.
The Oracle Net service name must resolve to a connect descriptor that uses the same protocol, host address, port, and service that you specified when you configured the listeners for the primary database, the far sync instance, and the terminal standby database. The connect descriptor must also specify that a dedicated server be used.
See the Oracle Database Net Services Administrator's Guide for more information about service names.
Start the far sync instance in mount mode.
Verify that the far sync instance is operating properly.
For information about validating a configuration after you create a far sync instance, see Section 7.5, "Validating a Configuration."
Increase the protection mode of the configuration to Maximum Availability. On the primary database, execute the following command:
SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;
See Also:
Section 5.3 for more information about far sync and protection modes
Chapter 6 for more information about configuring different data protection modes
After you perform the steps in Section 5.1.1, the far sync instance is now providing zero data loss capability for the configuration to the terminal standby at a remote site over the WAN. For the configuration to remain protected at a Maximum Performance level, in the event that communication with the far sync instance is lost, you can optionally configure the terminal standby to automatically become the alternate destination. This will reduce the amount of data loss by allowing Oracle Data Guard to ship redo asynchronously directly from the primary to the terminal standby, temporarily bypassing the far sync instance.
To configure an alternate destination, set the parameters on the primary database as follows:
Primary Database chicago
LOG_ARCHIVE_DEST_STATE_2='ENABLE' LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS' LOG_ARCHIVE_DEST_STATE_3='ALTERNATE' LOG_ARCHIVE_DEST_3='SERVICE=boston ASYNC ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
This enables Oracle Data Guard to continue sending redo, asynchronously, to the terminal standby boston when it can no longer send the redo directly to the far sync instance chicagoFS. When the far sync instance becomes available again, Oracle Data Guard automatically resynchronizes the far sync instance chicagoFS and returns to the original configuration in which the primary sends redo to the far sync instance and the far sync instance forwards that redo to the terminal standby. When the synchronization is complete, the alternate destination (LOG_ARCHIVE_DEST_3 in the preceding example) will again become dormant as the alternate.
For more information about the ALTERNATE attribute, see "ALTERNATE".
This section provides examples of two additional far sync instance configurations. These examples describe variations that provide better data protection when you use far sync instances.
For continued protection after a role change, two far sync instances can be configured, one close to each database in the configuration, where only one is active at any time and the other one becomes active when a role change occurs between the primary database and the terminal standby database. This allows the configuration to remain in the desired protection mode regardless of which database is the primary database.
For more protection from system or network failures, two additional far sync instances can be configured that provide high availability for the active far sync instance. In this configuration one is the preferred active far sync instance and the other is the alternate far sync instance. Configuring an alternate far sync instance provides continued protection for the configuration if the preferred far sync instance fails for some reason. The primary automatically starts shipping to the alternate far sync instance if it detects a failure at the preferred far sync instance. If the preferred far sync instance re-establishes itself, then the primary switches back to the preferred far sync instance and puts the alternate far sync instance back into the alternate state.
In these types of configurations, the primary uses only one of these far sync instances to redistribute redo at any given time.
The configuration described in Section 5.1.1 and Section 5.1.2 would be inappropriate after a role transition where boston becomes the primary database and chicago becomes the terminal standby. The far sync instance chicagoFS would be too remote for boston to use it as a synchronous destination because the network latency between two sites is sufficiently large and would impact commit response times. To maintain the protection level of Maximum Availability for zero data loss, a second far sync instance close to boston must be established, in readiness for a future role transition event.
Using the same procedure as described in Section 5.1.1 and Section 5.1.2, create a far sync instance named bostonFS close to the standby database boston. Example 5-2 shows the parameters that the new far sync instance bostonFS would then have.
Example 5-2 Parameters Used to Set Up Protection After a Role Change
Far Sync Instance bostonFS
DB_UNIQUE_NAME=bostonFS CONTROL_FILES='/arch2/bostonFS/control01.ctl' FAL_SERVER=boston LOG_FILE_NAME_CONVERT='boston','bostonFS' LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston,bostonFS)' LOG_ARCHIVE_DEST_1='LOCATION= USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=bostonFS' LOG_ARCHIVE_DEST_2='SERVICE=chicago ASYNC VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=chicago'
The standby database boston would have been modified to have the following parameters set:
Physical Standby Database boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston,bostonFS)' LOG_ARCHIVE_DEST_STATE_2=ENABLE LOG_ARCHIVE_DEST_2='SERVICE=bostonFS SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bostonFS' LOG_ARCHIVE_DEST_STATE_3='ALTERNATE' LOG_ARCHIVE_DEST_3='SERVICE=chicago ASYNC ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago'
Lastly, modify the parameters on chicago as follows:
Primary Database chicago
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,boston,bostonFS)' FAL_SERVER='bostonFS','boston'
Note:
The far sync instance,bostonFS, will receive redo from boston and ship it to chicago only when boston is the primary database. However, even if boston is not the primary database, Oracle recommends keeping far sync instance bostonFS mounted in readiness for a future role transition.In the configurations described so far in this chapter, the ALTERNATE remote destination was setup directly between the two databases using asynchronous redo transport. This means that in the event of a failure of the active far sync instance, the protection level of the configuration falls back down to Maximum Performance, with potential data loss at failover time.
To maintain the protection level of Maximum Availability, a second far sync instance can be set up as the ALTERNATE to the far sync instance used by each database when it is the primary. Then, if the active far sync instance becomes unavailable, the primary database can automatically begin sending redo in synchronous mode to the alternate far sync instance, thereby maintaining the elevated protection level of Maximum Availability. As before, when the original far sync instance reestablishes itself, the primary will automatically resume using it as the active far sync destination, and the second local far sync instance will once again become the alternate.
These high availability far sync instances would be created using the same steps as given in Section 5.1.1 and then become the alternates to their local far sync instances instead of the terminal standby. When complete, chicago and boston would have their parameters configured as follows (assuming the names chicagoFS1 and bostonFS1 as the new far sync instance names).
Example 5-3 Parameters Used to Set Up High Availability Far Sync Instances
Primary Database chicago
FAL_SERVER=bostonFS, bostonFS1, boston LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,chicagoFS1,boston,bostonFS,bostonFS1)' LOG_ARCHIVE_DEST_STATE_2='ENABLE' LOG_ARCHIVE_DEST_2='SERVICE=chicagoFS SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS' LOG_ARCHIVE_DEST_STATE_3='ALTERNATE' LOG_ARCHIVE_DEST_3='SERVICE=chicagoFS1 SYNC AFFIRM ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicagoFS1'
Physical Standby boston
LOG_ARCHIVE_CONFIG='DG_CONFIG=(chicago,chicagoFS,chicagoFS1,boston,bostonFS,bostonFS1)' LOG_ARCHIVE_DEST_STATE_2='ENABLE' LOG_ARCHIVE_DEST_2='SERVICE=bostonFS SYNC AFFIRM MAX_FAILURE=1 ALTERNATE=LOG_ARCHIVE_DEST_3 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bostonFS' LOG_ARCHIVE_DEST_STATE_3='ALTERNATE' LOG_ARCHIVE_DEST_3='SERVICE=bostonFS1 SYNC AFFIRM ALTERNATE=LOG_ARCHIVE_DEST_2 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=bostonFS1'
Oracle Data Guard will now be able to continue synchronously sending redo to a far sync instance, maintaining the required zero data loss protection mode of Maximum Availability regardless of whether chicago or boston is the primary database. As before, when the failed far sync instance becomes available again, Oracle Data Guard will automatically resynchronize it and return to the original configuration in which the primary sends redo to the first far sync instance, who then forwards that redo to the terminal standby. When the synchronization is complete, the alternate destination (LOG_ARCHIVE_DEST_3 in the preceding example) will again become dormant as the alternate.
A far sync instance is supported in either maximum performance or maximum availability mode.
In maximum availability mode, the far sync instance is relatively close to the primary database to minimize network latency, and the primary services the far sync instance using SYNC transport.
Note:
There is no architectural limit to the distance that can separate the primary and far sync instance in maximum availability mode. The practical distance limit varies depending upon a given application's tolerance to the impact of network latency in a synchronous configuration. Also note that it is possible to reduce the performance impact for any given distance by using the new Oracle Data Guard FastSync feature (SYNC/NOAFFIRM). See "Performance Versus Protection in Maximum Availability Mode".Both SYNC/AFFIRM and SYNC/NOAFFIRM semantics are supported on the LOG_ARCHIVE_DEST_n established at the primary for the far sync instance. See Section 6.1 for information about the trade-offs of using each one.
When a primary services a far sync instance using SYNC transport, all committed redo resides on disk at the far sync instance. This allows the far sync instance to use one of the terminal standby destinations for a no data loss failover if the primary database is lost.
The far sync instance uses ASYNC transport to ship the incoming redo to terminal standbys that can be much farther away. This extends no data loss protection to destinations that are too far away for a primary database to feasibly service directly with SYNC transport because of the degradation in transaction throughput that would result. This is a case where a far sync instance is beneficial even if there is only one standby destination in the configuration.
In maximum performance mode, the primary database services the far sync instance destination using ASYNC redo transport regardless of the physical distance between the primary and the far sync instance because high network latencies do not affect transaction throughput when a destination is serviced with ASYNC transport.
In maximum performance mode, a far sync instance can benefit Oracle Data Guard configurations that manage more than one remote destination. Although each ASYNC destination has a near-zero effect on primary database performance, if there are many remote destinations (for example, multiple Oracle Active Data Guard standbys that form a reader farm), then the effect can become measurable. When a far sync instance is used, there is zero incremental effect for each remote destination added to the configuration. Additionally, redo transport compression can also be offloaded to the far sync instance. When a far sync instance is used, the primary only has to service the far sync instance, which then services the rest of the configuration; the greater the number of destinations, the greater the performance benefit.