Considerations for Creating Oracle Data Guard Standy Redo Logs

By Scott Jesse, Bill Burton, Bryan Vongray on October 1, 2013

What happens on a secondary site when Oracle Data Guard log transport services ship redo data to it from the primary, and what considerations should be made when creating the standby redo logs? This article discusses the process flow that occurs on the standby once the primary’s redo data has arrived.

With Oracle 11g, by default, LNS is used on the primary to initiate a connection with the standby; the standby listener responds by spawning a process called the remote file server (RFS). The RFS process will create a network connection with the primary and will sit waiting for data to arrive. Once data begins arriving from the primary, the RFS process will place it either into standby redo logs or into archive redo logs. You can think of standby redo logs as exact twins to online redo logs, except the former are active only when a database is in the standby role. Basically, standby redo logs are just a separate pool of redo logs. The RFS process will pick the first available standby redo log and begin placing changes into that log. When a log switch occurs on the primary, we switch standby redo logs and the RFS process will go to the next available standby redo log. The standby redo log that was being written prior to the log switch will be archived by the standby database. Oracle highly recommends that you use standby redo logs. If you plan on setting one of the higher level protection modes or using Real-Time Apply (we will discuss this later in the section “Starting and Stopping Managed Recovery”), the use of standby redo logs is mandatory.

When creating standby redo logs, it is recommended that you adhere to the following guidelines:

  • Standby redo logs should be created with one more log group per thread than the number of online redo log groups on the primary database.
  • The standby redo logs must be exactly the same size as the online redo logs.
  • You should create standby redo logs on both the primary and standby to facilitate seamless role changes.
  • In an Oracle RAC environment, all standby redo logs should be on a shared disk and should be thread-specific.


Related Posts

Leave a Reply