Standby Redo Logs (SRL) is similar to Online Redo Log (ORL) and the only difference between the two is that Standby Redo Log is used to store redo data received from another database (primary database).
Standby Redo Logs are only used if you have the LGWR as transport mode to Remote Standby Database.
Standby redo logs are created by a network server synch process that keeps track of the online redo database logs and writes continuously in a standby log file located in the destination database.
Every record recorded to the Primary Database's Online Redo Logs is simultaneously transferred to the Standby Database and written to the Standby Redo Logs.
If you have Standby Redo Logs, the RFS process will write into the Standby Redo Log, when their record is entered in the online redo log and when a log switch occurs, the Archiver Process of the Standby Database will archive this Standby Redo Log to an Archived Redo Log, while the MRP process applies the information to the Standby Database.
You will have access to the information already written in the Standby Redo Logs in the event of a Failover, ensuring that the information is not lost.
If the backup site isn't getting logs, the first thing you should do is query the V$ARCHIVE DEST view for information on the primary database's archiving status. Look for error messages in particular. Enter the following query, for example:
If the query's output does not assist, look through the list of likely problems below. The primary database will fail to archive to the standby location if any of the following circumstances exist:
1. At the primary site, the service name for the backup instance is incorrectly specified in the tnsnames.ora file.
2. The service name specified in the primary startup parameter file's LOG ARCHIVE DEST n parameter is incorrect.
3. The value DEFER is assigned to the LOG ARCHIVE DEST STATE n parameter, which specifies the status of the standby archiving destination.
4. At the standby site, the listener.ora file is incorrectly set.
Thank you for your explanations.
Standby Redo Logs (SRL) is similar to Online Redo Log (ORL) and the only difference between the two is that Standby Redo Log is used to store redo data received from another database (primary database).
Standby Redo Logs are only used if you have the LGWR as transport mode to Remote Standby Database.
Standby redo logs are created by a network server synch process that keeps track of the online redo database logs and writes continuously in a standby log file located in the destination database.
Every record recorded to the Primary Database's Online Redo Logs is simultaneously transferred to the Standby Database and written to the Standby Redo Logs.
If you have Standby Redo Logs, the RFS process will write into the Standby Redo Log, when their record is entered in the online redo log and when a log switch occurs, the Archiver Process of the Standby Database will archive this Standby Redo Log to an Archived Redo Log, while the MRP process applies the information to the Standby Database.
You will have access to the information already written in the Standby Redo Logs in the event of a Failover, ensuring that the information is not lost.
If the backup site isn't getting logs, the first thing you should do is query the V$ARCHIVE DEST view for information on the primary database's archiving status. Look for error messages in particular. Enter the following query, for example:
SQL> SELECT DEST_ID "ID", 2> STATUS "DB_status", 3> DESTINATION "Archive_dest", 4> ERROR "Error" 5> FROM V$ARCHIVE_DEST;If the query's output does not assist, look through the list of likely problems below. The primary database will fail to archive to the standby location if any of the following circumstances exist:
1. At the primary site, the service name for the backup instance is incorrectly specified in the tnsnames.ora file.
2. The service name specified in the primary startup parameter file's LOG ARCHIVE DEST n parameter is incorrect.
3. The value DEFER is assigned to the LOG ARCHIVE DEST STATE n parameter, which specifies the status of the standby archiving destination.
4. At the standby site, the listener.ora file is incorrectly set.
5. The listener hasn't been started yet.
6. The standby instance isn't running yet.