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:
- 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.
- Consider changing the following database initialization parameters to FULL:
- 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.
- All online and SRL files should be the same size on any primary and standby databases and the Far Sync instance.
- Primary and standby databases and the Far Sync instance should have SRL files that have the same number of threads as redo log files.
- 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 Distance, an Oracle white paper).
- Consider not to multiplex SRLs.
- Using the RMAN deletion policy, delete logs after ensuring that they were applied on all standby destinations; use the following configuration:
- MAA tests determined that a 300MB SGA with CPU_COUNT=1 on Linux was sufficient for Far Sync.
- Practice is important for ensuring a positive outcome in the following scenarios:
- Resolving Gaps in Data Guard
- Recreating Standby or Far Sync
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.
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.
Changing this parameter to FULL enables detection of lost writes.
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;