A customer has these requirements for their potential Data Guard implementation:
1. Zero data loss must still be guaranteed through the loss of any one configuration component.
2. The primary database must be protected against a regional disaster.
3. Performance overheads on the primary should be minimized as much as possible given these requirements.
4. Downtime on the primary database for any reason must be kept to a minimum.
Components referred to in the broker commands are:
Which Data Guard broker commands are needed to implement these requirements?
A.
EDIT DATABASE prima SET PROPERY REDOROUTES=’ (LOCAL: physt1, FASTSYNC)’;
EDIT DATABASE prima SET PROPERY REDOROUTES=’ (LOCAL: fs1 SYNC)’;
EDIT FAR_SYNC fs1 SET PROPERTY REDORUOTES=’ (prima: physt2 SYNC)’;
EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
B.
EDIT DATABASE prima SET PROPERY REDOROUTES=’ (LOCAL: fs1 ASYNC)’;
EDIT FAR_SYNC fs1 SET PROPERTY REDORUOTES=’ (prima: physt FASTSYNC)’;
EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION
C.
EDIT DATABASE prima SET PROPERY REDOROUTES=’ (LOCAL: fs1 SYNC)’;
EDIT FAR_SYNC fs1 SET PROPERTY REDORUOTES=’ (prima: physt ASYNC)’;
EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
D.
EDIT DATABASE prima SET PROPERY REDOROUTES=’ (LOCAL: physt1, FASTSYNC)’;
EDIT DATABASE prima SET PROPERY REDOROUTES=’ (LOCAL: fs1, FASTSYNC)’;
EDIT FAR_SYNC fs1 SET PROPERTY REDORUOTES=’ (prima: physt2 ASYNC)’;
EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Explanation:
The route between fs1 and physical standbase in the remote region, like physt2, should be SYNC or SYNC NOAFFIRM.
Note:
Fast Sync is a new Data Guard capability available with Oracle Database 12c. Fast Sync enables use of the destination parameter NOAFFIRM which specifies that
the standby acknowledge receipt of redo without waiting for the write to the standby redo log file to complete. Fast Sync can improve application response time in aSYNC configuration by removing remote I/O from the total round trip time.
Active Data Guard Far Sync Architecture
Incorrect Answers:
B: There is no keyword FASTSYNC. To configure fast sync you use SYNC NOAFFIRM.
C: The route between fs1 and physical standbase in the remote region, like physt, should be SYNC, not ASYNC.
D: The route between fs1 and physical standbase in the remote region, like physt2, should be SYNC, not ASYNC.http://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf
Incorrect Answers:
B: There is no keyword FASTSYNC. To configure fast sync you use SYNC NOAFFIRM.
=> not true, of course there is a keyword ‘FASTSYNC’. B is incorrect since redo transport between primary and FarSync instance for zero data loss must be ‘SYNC and AFFIRM’.
C: The route between fs1 and physical standbase in the remote region, like physt, should be SYNC, not ASYNC.
=> not true. C is incorrect since the route between primary and FarSync is ‘async’ which doesn’t conform with requested zero data loss.
D: The route between fs1 and physical standbase in the remote region, like physt2, should be SYNC, not ASYNC.
=> not true. D is incorrect since the route between primary and FarSync is ‘SYNC and NOAFFIRM’ which doesn’t conform with requested zero data loss.
FastSync is a new keyword in Oracle 12
https://docs.oracle.com/database/121/DGBKR/dbpropref.htm#DGBKR905
FASTSYNC
Configures redo transport services for this configuration member using the SYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. This mode is only available in maximum availability protection mode. Because FASTSYNC transport mode uses the NOAFFIRM attribute of the LOG_ARCHIVE_DEST_n parameter, data loss is possible.
C
A database cannot be specified as a redo source in more than one redo routing rule defined at a given database, either explicitly or implicitly through use of the LOCAL keyword.
Only 2 command will have effect:
EDIT DATABASE prima SET PROPERY REDOROUTES=’ (LOCAL: physt1, FASTSYNC)’;
EDIT DATABASE prima SET PROPERY REDOROUTES=’ (LOCAL: fs1 SYNC)’; <<<<<
Correct Ans: D
Here requirements are protect against regional disaster and as well as provide best performance.
Ans A can only provide regional disaster but not address performance issues since Far Sync is transferring logs to remote location in SYNC mode instead of ASYNC. If the standby is several hundred miles away or in another country/continent then there will be huge performance impact on the Primary.
FASTSYNC is new in 12c – SYNC NOAFFIRM to avoid performance impact at the same time provide zero or near zero data loss.
In Ans D, Primary send redo to FAR SYNC and Local standby database in FASTSYNC mode.
FAR SYNC send redo to remote standby in ASYNC mode. This configuration can protect primary against regional disaster and as well as provide best performance.
Dear Sirs,
I think C is the correct answer based on the rule stated on the official oracle documentation:
A database cannot be specified as a redo source in more than one redo routing rule defined at a given database, either explicitly or implicitly through use of the LOCAL keyword.
https://docs.oracle.com/database/121/DGBKR/dbresource.htm#DGBKR3852
So what do you think?
I think is D
physt1 is needed to implement the 4th point.
The Syncronization to a remote database should be ASYNC now that you are using FAR_SYNC