This topic outlines some of the enhancements to standby databases made with Oracle9i. These include the ability to detect gaps in log-sequence numbers and retrieve redo logs that are neede to deal with those gaps. Also, DBA's can now configure a purposeful delay in the time between the generation of redo and its application on the standby site.

Log Sequence Gap Detection and Recovery

Oracle9i data guard provides the ability to determine log sequence gaps. When configured, the Oracle9i standby database can retrieve needed redo logs from the primary database, or another standby database. This functionality is facilitated through two new parameters, both of which need to be configured for the process to work correctly.

  • FAL_CLIENT - This parameter configures Fetch Archive Log Client (FALC), runs on the standby site, and contains the net service name of the standby database.
  • FAL_SERVER - This parameter configures Fetch Archive Log Server (FALS) process on the standby database site and contains the Net service name for the FAL server.

Oracle provides a new view, V$ARCHIVE_GAP, to help the DBA identify log sequence gap information.

Configurable Log Application Delay

There are environments in which the DBA doesn't want a particular standby database to be in synch with the primary database. This might be because the DBA desires some protection from user errors, or perhaps logical corruption that might occur. In Oracle9i, you can configure an individual standby database so that it will have the application of redo from the primary database delayed for a period of time.

This feature can be configured in one of two ways. First, it can be configured using the log_archive_dest_n parameter; or, it can be configured using the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE command, using the delay or nodelay keyword.

Support for Single Redo Log Stream

Supporting multiple standby database sites can have performance impacts on the primary database. To mitigate these impacts, you can configure a single redo log stream between the primary database and a single standby database. When properly configured, other standby databases will receive redo from the standby database, freeing the resources of the primary database that would otherwise be tasked with this chore. This option is facilitated through the use of the new dependency parameter of the log_archive_dest_n parameter.

Support for Establishment of a Maximum Archive Log Lag Target

In certain configurations, the Oracle9i standby database might not have any redo applied to it with any great frequency. Consider a primary database with few, small transactions that switches redo logs only every two days. If we are using delayed protection mode, then the standby database will lag behind the primary database by two days. In many environments, this might well be too much of a time lag.

Oracle9i offers a solution to this problem. By configuring the archive_lag_target parameter (in seconds), the DBA can configure how often the primary database will perform log switches, which will result in the eventual application of the generated redo log on the standby database.