Which three statements are true about Far Sync instances?
A.
The Data Guard Broker must be used to deploy and manage Far Sync instances.
B.
They enable standby database to be configured at remote distances from the primary without impacting performance on the primary.
C.
A primary database can ship redo directly to multiple Far Sync instances.
D.
They use as spfile, a standby controlfile, and standby redo logs.
E.
They work with any protection level.
Explanation:
A: The the far sync instance is added to a Data Guard broker configuration.
B: 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.
D: Creating and Configuring a Far Sync Instance
Take the following steps to create a far sync instance:
1. Create the control file for the far sync instance.
2. Create a parameter file (PFILE) from the server parameter file (SPFILE) used by the primary database.
3. Create a server parameter file (spfile) from the edited parameter file (pfile) to facilitate any subsequent changes to parameter values.
4. 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.
5. Create standby redo logs in the same way they are created for a regular standby.
Etc.
Incorrect Answers:
C: A far sync instance manages a control file, receives redo into standby redo logs (SRLs), and archives those SRLs to local archived redo logs.
E: A far sync instance is supported in either maximum performance or maximum availability mode only.https://docs.oracle.com/database/121/SBYDB/create_fs.htm
only B & D correct!!
E: incorrect: https://docs.oracle.com/database/121/SBYDB/create_fs.htm#SBYDB5443
A far sync instance is supported in either maximum performance or maximum availability mode.
D: correct: https://docs.oracle.com/database/121/SBYDB/create_fs.htm#SBYDB5416
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.
C: incorrect: only one farsync can be active.
B: correct
A: INCORRECT: broker is *not* a must: http://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf
The above parameters are relevant for this configuration when set by SQL*Plus and are provided to make all the details of the configuration clear to the reader, however Oracle recommends the simpler approach of configuring Far Sync using the Data Guard Broker. Steps for configuring Far Sync with Data Guard Broker are listed in Appendix C
BCD
Take a look at this sample:
https://docs.oracle.com/database/121/DGBKR/dbresource.htm#DGBKR3854
– it uses multiple FS instances.
Only one active Far Sync, and receiving from the Primary.
The inactive one is used to failover / switchover FS.
i think it’s only B & C since you don’t need a STANDBY controlfile but a FAR SYNC controlfile… see https://docs.oracle.com/database/121/SBYDB/create_fs.htm#SBYDB5417
At Least B & C
Multiple FS: yes you can use it, But you will have to configure the ALTERNATE redo destination. For example, LOG_ARCHIVE_DEST_2=Far sync_1, but also configure LOG_ARCHIVE_DEST_3=Far Sync 2 as an alternate destination in case of the first Far Sync failure
D: Not a standby controlfile, but a far sync controlfile
“ALTER DATABASE CREATE FAR SYNC INSTANCE CONTROLFILE AS ‘/arch2/chicagoFS/control01.ctl’;”
BCD
D as I think – ‘far sync controlfile’ is special type of standby controlfile
C is correct, but redo can be shipped directly to multiple Far Sync instances, but not parallel
A,B,D