Which three statements are true about standby redo logs in a Data Guard configuration with no Oracle Streams or Goldengate configured?
A.
They are required on a logical standby for real-time apply
B.
They are required only for synchronous redo transport.
C.
Only standby databases can write redo to them.
D.
It is recommended to have them on the primary database.
E.
They are required on a physical standby for real-time apply.
F.
The LGWR process writes to them on a standby database.
D is also correct, so ACED???
D is also correct but not so strong with other 3-options.
C is incorrect. Far Sync use SRL too
Steff, good point!
C is true. ( A Far Sync cannot run redo apply )
Refer – https://docs.oracle.com/database/121/SBYDB/create_fs.htm#SBYDB5416
An Oracle Data Guard far sync instance is a remote Oracle Data Guard destination that accepts redo from the primary database and then ships that redo to other members of the Oracle Data Guard configuration.
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.
A far sync instance does not have user data files, cannot be opened for access, cannot run redo apply, and can never function in the primary role or be converted to any type of standby database
A,C,E are correct
Your comment shows that “C” is incorrect.
As D is correct, it should be ADE
A,D,E
Are Standby Redo Logs mandatory for Real-Time Apply ?
Standby Redo log Files (SRL’s) are required for Real-Time Apply because the Apply Process can only apply from a Standby Redo Log rather than from a partial filled Archive Log. For more Information about Standby Redo Logs and how to setup see the referenced Note below in the ‘Reference’-Section.
Usage, Benefits and Limitations of Standby Redo Logs (SRL) (Doc ID 219344.1)
6.3 Applying Redo Data to Physical Standby Databases
By default, the redo data is applied from archived redo log files. When performing Redo Apply, a physical standby database can use the real-time apply feature to apply redo directly from the standby redo log files as they are being written by the RFS process. Note that log apply services cannot apply redo data to a physical standby database when it is opened in read-only mode.
I think that is:
A – This is wrong, logical standby doesn’t have real-time apply, only physical standby database have this option.
B – Wrong! They are not required only for this, this is important to “maximum protection” that requires synchronous redo transport, but, the are not required only for this.
C – Right! A primary database writes to redo log files
D – Right! May be a switchover or a failover, them, this will be required!
E – Right!
F – Wrong! RFS writes to them
Standby redo logs are recommended for all Data Guard database configurations. Even though SRLs are not required for Maximum Performance mode, we recommend that you create them as they will improve redo transport speed, data recoverability, and apply speed.
2.5.2 Standby Redo Logs
A standby redo log is similar to an online redo log, except that a standby redo log is used to store redo data received from another database.
A standby redo log is required if you want to implement:
■ The maximum protection and maximum availability levels of data protection (described in Section 1.4 and in more detail in Section 5.6)
■ Real-time apply (described in Section 6.2)
■ Cascaded destinations (described in Appendix E)
A standby redo log provides a number of advantages:
■ Standby redo log files can reside on raw devices, which may be important if either or both the primary and standby databases reside in a Real Application Clusters environment.
■ Standby redo log files can be multiplexed using multiple members, improving reliability over archived log files.
■ During a failover, Data Guard can recover and apply more redo data from standby redo log files than from the archived log files alone.
■ The archiver (ARCn) process or the log writer (LGWR) process on the primary database can transmit redo data directly to remote standby redo log files, potentially eliminating the need to register a partial archived log file (for example, to recover after a standby database crashes). See Chapter 5 for more information.
If standby redo logs are available and configured correctly, the RFS process will write the redo received from the primary database to the standby redo logs. Because the files are generally the same size as the online redo logs of the primary database, they should fill up and switch at a similar frequency as the online redo logs. There may be some delay due to the latency of the network transmission of the redo. The additional standby redo log group should allow the log switch of the standby redo logs without causing wait states. At log switch of the standby redo logs, the co process will create an archived redo log using the completed standby redo log.
The RFS process creates and writes directly to an archived redo log file instead of the standby redo log if any of the following conditions are met:
. There are no standby redo logs.
• It cannot find a standby redo log that is the same size as or larger than the incoming online redo log file.
• All standby redo logs of the correct size have not yet been archived.
Note: In previous releases, the parameter STANDBY ARCHIVE DEST was used to identify the location of the archived redo logs created on the standby database host that were created from the standby redo logs. This parameter is now deprecated, because an appropriate location is automatically chosen.
Someone else?
A, D, E
Use the ALTER DATABASE statement to enable the real-time apply feature, as follows:
• For physical standby databases, issue the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE statement. (As of Oracle Database 12c Release 1 (12.1), the USING CURRENT LOGFILE clause is deprecated and no longer necessary to start real-time apply.)
• For logical standby databases, issue the ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE statement. Real-time apply requires a standby database that is configured with a standby redo log and that is in ARCHIVELOG mode.
An Oracle Data Guard configuration with a local destination and a standby destination. As the remote file server (RFS) process writes the redo data to standby redo log files on the standby database, apply services can recover redo from standby redo log files as they are being filled.
B is wrong: They are not only used for Synchronous Redo Transport.
Standby redo logs are required to implement:
• Synchronous transport mode
• Real-time apply
• Cascaded redo log destinations
Chunn, about the item “A”, you are right, but, about the question “An Oracle Data Guard configuration with a local destination and a standby destination. As the remote file server (RFS) process writes the redo data to standby redo log files on the standby database, apply services can recover redo from standby redo log files as they are being filled.” i think that you are wrong! See the answer to the JorgeZG. What do you think? A,C,D and E?
A – incorrect! There is no real-time apply for Logical Database.
B- CORRECT !! If the LGWR writes on Redologs, where is the RFS going to write for synchronous transport in order to finish a commit ??
C- incorrect !! RFS write redo to them
D- CORRECT !! It’s a good practice
E- CORRECT !! they are needed for physical standby for real-time apply.
F- incorrect!! LGWR doesnt writes to them
B, D and E
Jorge, RFS runs under a standby environment, not in the primary database environment. See the image in the link below. This is R(emote), right?
https://taliphakanozturken.wordpress.com/tag/real-time-apply/