Management is now happy with the Mean Time To Recovery (MTTR)… but not really. They review the documentation generated from your database failover test and see that the time to switchover is slow and that there is still a possibility of losing some data.

Enter standby redo logs. These are required to enable real time apply of redo data onto the standby. This is not the same level of redundancy or availability of Oracle RAC, but getting close.

Essentially, the standby redo logs are populated with redo information as fast as the primary redo logs, rather than waiting for the redo log to be archived and shipped to the standby. So the loss of data in the event of a failover is minimized.

Rather than regurgitate the documentation, I have attached the links to the specific parts of the documentation. Since I’m focused on providing ways for you to “get the job done”, I have also included some SQL that uses dynamic SQL to generate a series of ALTER DATABASE ADD STANDBY LOGFILE commands to run on both the primary and standby databases.

While it would be nice if the RMAN DUPLICATE command added the standby redo logs, it does not.

Share this article

11 Responses to “Oracle Standby redo Logs”

I like the technique, even adding the an extra SRL over the number of redo logs. However I would dispute what you say about RAC:

“This is not the same level of redundancy or availability of Oracle RAC, but getting close.” But if your building blows up or floods, unless you have a stretched RAC cluster your dataguard solution provides you much more protection way above the availability of RAC.

you are right – RMAN’s duplicate command does not do everything for you regarding standby redo logs (I am about the case when they are already created on primary database). But after duplication of the target database proper entries (taking into consideration log_file_name_convert parameter on standby side) for standby logs will be created, but without files under that. The files can be simply recreated through ALTER DATABASE CLEAR LOGFILE GROUP (n – standby log file group) command. And after that you can continue with Data Guard (or Standby) configuration.

I recently found out when setting up logical standby with real-time apply the logical standby database MUST be in ARCHIVELOG mode (relates to having the standby redo logs). I couldn’t find this requirement in any of the 10.2 documentation – I raised this with Oracle and they confirmed it is a documentation bug and fixed in 11g (not sure if they’re planning on updating the 10g documentation on tahiti.oracle.com).

This is the reference in the 11g documentation:

““Redo received from another Oracle database via redo transport is written to the current standby redo log group by a RFS background process. When a log switch occurs on the redo source database, incoming redo is then written to the next standby redo log group, and the previously used standby redo log group is archived by an ARCn background process.””

Hi
I need to setup a three instance rac database.The datafiles and flash recovery area will be stored in ASM diskgroups called +data and +fra.
Which is the best location options for archivelogs so that they can be accessed during recovery without dba intervention ?

a-)
cluster file system with each instance writing to a shared location
or
b-)
cluster file system with each instance writing to a seperate location as long as all the locations are in directories under the same mount point