How to Use Data Guard 12c Far Sync Feature

What is a Far Sync?

A Data Guard Far Sync is a remote Data Guard destination that accepts redo from the primary database and redistributes that redo throughout the Data Guard configuration. It is similar to a physical standby database in that it manages a control file, receives redo into Standby Redo Logs (SRLs), and archives those SRLs to local Archived Redo Logs (ARLs). However, unlike a standby database, a Far Sync does not manage data files, cannot be opened for access, and cannot run Redo Apply. These limitations yield the benefit of using fewer disk and processing resources. More importantly, a Far Sync provides the ability to fail over to a terminal database with no data loss.

Many variables, such as the redo write size, available network bandwidth, round-trip network latency and standby I/O performance while writing to the standby redo logs impose practical latency, and standby I/O performance while writing to the standby redo logs, impose practical limitations on the distance that a standby can reside from a primary database. This includes a Far Sync. A Data Guard 12c new feature called Fast Sync removes the standby I/O performance from the limitations list and helps to extend the distance that a Far Sync can reside from the primary database.

Far Sync: Redo Transport

The diagram above displays a flat projection of a world map showing North America, South America, Europe, and Africa. Somewhere in North America, an icon in the slide represents the primary database system. Somewhere in Europe, an icon in the slide represents a standby database system. A short distance from the primary database system is a new type of instance called a Far Sync that is introduced as a new feature with Data Guard in Oracle Database 12c.

The redo transport uses synchronous (SYNC) transmission between the primary database system and a Far Sync. This imposes a practical limit on the distance between the primary database system and the Far Sync instance because it impacts the performance on the primary database The log writer ( primary database. The log writer (LGWR) process of the primary database system has to wait ) process of the primary database system has to wait for confirmation from the Network Server SYNC (NSS) process that the redo has been transmitted over the network before it can proceed with the next transaction. Redo transport from the Far Sync to the standby database system uses asynchronous communication. This eliminates the requirement of waiting for acknowledgment from the Network Server ASYNC (NSA) process on the Far Sync instance, creating near zero performance impact because of network transmission even if intercontinental distances are involved.

How does redo transport work with a Far Sync configuration?

• The Far Sync instance receives redo synchronously from the primary database.
• The Far Sync instance forwards redo asynchronously in The Far Sync instance forwards redo asynchronously in real time to its final destination.
• Redo transport supports one local and up to 30 additional local or remote destinations.
• Oracle Recovery Manager (Oracle RMAN) deletion polices are used to automate archive log management are used to automate archive log management.
• A Far Sync instance can also compress redo transport.
• An alternate Far Sync can be used for HA.

In maximum availability mode, the Far Sync instance is relatively close to the primary database to minimize network latency and the primary database services the Far Sync by using SYNC transport.

When a primary database services a Far Sync by using SYNC transport, all committed redo resides on disk at the Far Sync. That way, the Far Sync can use one of the terminal standby destinations for a no-data-loss failover if the primary database is lost.

The Far Sync uses ASYNC transport to redistribute 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 resulting degradation in transaction throughput. This is a case where a Far Sync is beneficial even if there is only one standby destination in the configuration.

The redo transport architecture for a Far Sync is configured like any other type of standby database: Use the LOG_ARCHIVE_DEST_n parameter, which supports up to 30 destinations. Other parameters, such as DB_UNIQUE_NAME, LOG_ARCHIVE_CONFIG, FAL_SERVER, FAL_CLIENT, LOG_FILE_NAME_CONVERT, and DB_FILE_NAME_CONVERT, are also configured in the same way as any other type of standby database. With the Oracle Database Advanced Security option, redo transport compression is also available.

Far Sync: Alternate Redo Transport Routes

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=london ASYNC ALTERNATE=LOG_ARCHIVE_DEST_2
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=london'

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.

This enables Oracle Data Guard to continue sending redo, asynchronously, to the terminal standby london when it can no longer send the redo directly to the Far Sync instance bostonFS. When the Far Sync instance becomes available again, Oracle Data Guard automatically resynchronizes the Far Sync instance bostonFS 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 instance forwards that redo to the terminal standby. When the synchronization is complete, the alternate destination (LOG_ARCHIVE_DEST_3 in the example) will again become dormant as the alternate.

Oracle Data Guard 12c:Far Sync Creation

You start creating a Far Sync by issuing a command on the primary database to create a new Far Sync instance control file. The primary database must be mounted or open to issue the command. The syntax for creating a Far Sync instance control file is:

SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/PATH/FILENAME';

Next, copy the resulting control file, along with a copy of the primary database parameter file and the password file, to the machine that will host the Far Sync instance. It is assumed that the database software has already been installed on the machine that will host the Far Sync instance and a database listener has been configured. If the primary database uses a server parameter file (SPFILE) create a parameter file parameter file (SPFILE), create a parameter file (PFILE) (PFILE) before copying the file The following before copying the file. The following list of initialization parameters may need changing for the Far Sync instance:

DB_UNIQUE_NAME; CONTROL_FILES, FAL_SERVER, LOG_ARCHIVE_CONFIG, and LOG_ARCHIVE_DEST_n

On both the primary and Far Sync systems, use Oracle Net Manager to create a network service name for the primary and standby databases that will be used by redo transport services. This name will be supplied in the LOG ARCHIVE DEST n parameter. Use standard syntax to start and mount the Far Sync. After you mount the Far Sync, the DATABASE_ROLE column in the view V$DATABASE shows ‘FAR SYNC’.

Example

1. Create a control file using the mounted primary database:

SQL> ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS '/tmp/boston1.ctl';

2. Copy the parameter file (PFILE) and password file used by the primary database. (Several initialization parameters must also be modified for the Far Sync instance.) 3. Copy the control file to the Far Sync system. 4. Create standby redo log files as you would for any standby. 5. Start the Far Sync instance and mount the control file by using standard syntax. 6. The DATABASE_ROLE column in V$DATABASE will contain the value FAR SYNC.

Benefits: Far Sync

There are many benefits of a Far Sync. A Far Sync transparently integrates in a maximum availability mode configuration for no-compromise data protection. It requires no changes in applications that currently use a primary database and standby database architecture. A Far Sync has the least performance impact, because it does not manage data files, cannot be opened for access, and cannot run Redo Apply. Features such as redo transport compression that would have a performance impact on a primary database can be offloaded to the Far Sync host.

It is ideal for an HA model serving as a nearby archived log repository, yet still allows the benefits of a far-away disaster recovery model by extending no-data-loss protection to destinations that are too far away for a primary database to feasibly service directly by using destinations that are too far away for a primary database to feasibly service directly by using SYNC transport.

Far Sync: Alternate Design

Up to this point in this post, the discussion of a redo transport mechanism from a primary database to a Far Sync has used synchronous transmission. It is possible to also use asynchronous redo transport in a maximum performance Data Guard configuration.

In maximum performance mode, the primary database services the Far Sync destination by using ASYNC redo transport, regardless of the physical distance between the primary and the Far Sync. High network latencies do not affect transaction throughput when a destination is serviced with ASYNC transport.

In maximum performance mode, a Far Sync can benefit Data Guard configurations that manage more than one remote destination. Each destination that a primary directly services takes computing resources away from applications running on the primary. When a Far Sync is used, the primary only has to service the Far Sync, which then services the rest of the configuration. The performance benefit increases as the number of destinations increases.

The figure above shows a world map with a primary database in North America using ASYNC redo transport to a Far Sync located in Europe. The Far Sync is then used to cascade the primary redo to multiple standby sites located throughout Europe and Africa. Upto 30 terminal destinations are supported.

Real-Time Cascade

With traditional cascaded standby database configurations prior to Oracle Database 12c, primary database redo is transported to a standby database and that standby database cascades or forwards the primary redo to additional standby databases. However, traditionally the redo is not immediately cascaded. Primary database redo is written to the standby redo log as it is received at a cascading standby database. This redo was cascaded only after the standby redo log file that it was being written to had been archived locally.

Because standby redo logs are usually configured with the same size as the primary database redo log files, the rate that a standby redo log switches and is archived locally should be about the same time-frequency as the primary database log switch rate. Depending on the size of the redo logs and the rate of redo on the size of the redo logs and the rate of redo generation this log switch could take hours It, this log switch could take hours. It is also common that the time interval between switches varies. Even when the redo logs were not full, forced log switches on the primary database were typically used to standardize the time interval of log switches. However, the time meant that the final cascaded standby database was guaranteed to lag behind the primary database.

As of Oracle Database 12c Release 1 (12.1), the primary database redo is cascaded immediately, as it is being written to the standby redo log file. The terminal destination, therefore, has minimal redo transport lag with respect to the primary database. Only physical standbys and Far Syncs can cascade redo.

Traditional Multi-Standby Database Architecture

Multiple standby database configurations are very common in zero-data-loss architectures, where the primary database services one local standby database and one remote standby database. The local standby database may be located in the same data center with high-speed LAN connections using synchronous redo transport. This provides very fast HA failover in the event of a problem with the primary database system. It is also often used for offloading backups, read-only reporting, data extracts, rolling maintenance, and patching.

When the standby database is local to the primary database system, one disadvantage is site-wide disasters (for example, hurricanes or tornadoes could potentially impact entire data centers). To achieve zero data loss for all disasters, a second remote standby database is often used The remote distance often nec often used. The remote distance often necessitates asynchronous redo transport asynchronous redo transport.

This multiple standby database configuration places additional performance overhead and burden on the primary database system because of the need to ship redo to two different locations. Traditional cascaded standby database configuration could not provide zero data loss for the remote standby database system because of redo transport lag.

Benefits: Real-Time Cascade

With a real-time cascade introduced in Oracle Database 12c, the terminal destination has minimal redo transport lag for the primary database. Therefore, the local standby can be used to cascade the redo to the remote standby. This reduces the volume of redo sent from the primary by half, which results in less performance impact on the primary database.