Far Sync Best Practice Recommendations (for Oracle 12.1)

Hi,
This post is a continuation of my post, Using Standby as an Alternate for Far Sync (12c): Limitations and Considerations. It is for database administrators who want to set up Far Sync for the first time.

Creating a Far Sync instance requires a number of manual steps and there are many parameters to consider or set. I recently ran numerous scenarios using Oracle™ Active Data Guard with a Far Sync instance.

Our goals were to:
• Check Far Sync functionality and reliability
• Validate that Far Sync has a low footprint under heavy load

After running a large number of benchmark scenarios, where we changed one parameter at a time, here are my recommendations for using Active Data Guard with Far Sync:

1. The primary database, the standby database, and the Far Sync instance should all be using the same software version and patch level; if not, upgrade the database(s) to the latest version with the latest patch sets.
2. Consider changing the following database initialization parameters to FULL:
DB_BLOCK_CHECKING=FULL This parameter specifies whether Oracle performs block checking for database blocks. Changing to FULL can prevent memory and data corruption, but typically adds 1 – 10% overhead. DB_BLOCK_CHECKSUM=FULL This parameter determines whether the database calculates a checksum. Changing to FULL allows Oracle to detect corruption caused by underlying disks, storage systems, or I/O systems; it adds 4 – 5% overhead. DB_LOST_WRITE_PROTECT=FULL Changing this parameter to FULL enables detection of lost writes.
3. The standby database and the Far Sync instance standby redo logs (SRLs) should have the same number of redo log groups as the primary database plus one for each thread.
4. All online and SRL files should be the same size on any primary and standby databases and the Far Sync instance.
5. Primary and standby databases and the Far Sync instance should have SRL files that have the same number of threads as redo log files.
6. For Oracle RDBMS Version 12.1, set the parameter “_redo_transport_stall_time”=60 in all instances within the configuration; doing so enables the best return to synchronization after a node outage with an ALTERNATE Far Sync configuration (Source: Oracle Active Data Guard Far Sync Zero Data Loss at Any Distane, an Oracle white paper).
7. Consider not to multiplex SRLs.
8. Using the RMAN deletion policy, delete logs after ensuring that they were applied on all standby destinations; use the following configuration:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

9. MAA tests determined that a 300MB SGA with CPU_COUNT=1 on Linux was sufficient for Far Sync.
10. Practice is important for ensuring a positive outcome in the following scenarios:
1. Failover
2. Switchover
3. Resolving Gaps in Data Guard
4. Recreating Standby or Far Sync
11. The setting for LOG_ARCHIVE_MAX_PROCESSES should be equal to the number of remote destinations (likely 1) Plus the number of threads/instances (greater than 1 for RAC only).

Please feel free to comment here or contact me by mail: ynixon@gmail.com or Twitter @YossiNixon