Hey, did you catch that redirect? The Toad World URL is now community.toadworld.com. Don't worry -- you'll still find all the same great content here (and more on the way). We're just in the process of giving our Toad World site some well-deserved love. Stay tuned for some more updates coming this way.
Meanwhile, enjoy community.toadworld.com.
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.
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.
Oracle provides a new view, V$ARCHIVE_GAP, to help the DBA identify log sequence gap information.
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.
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.
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.