Log application service is responsible for applying the redo from the primary database to the standby databases after it has been moved by the log transport services. In Oracle9i, Oracle standby database log application services support two modes for the standby database that were available in Oracle8i: managed recovery and read-only (although logs cannot be applied in this mode).
Read-only mode allows read-only access to the standby database. This read-only access is at the cost of data divergence between the primary and standby database because a standby database is not updated when it is in read-only mode.
Managed recovery mode causes the Oracle9i standby database to be updated with the redo generated from the primary database site. In some configurations, the primary database LGWR process writes redo to standby redo log files, which are then archived on the standby database to the standby database archived redo logs. In other configurations, the primary database ARCH process simply sends archived redo logs to the standby database for processing. In all configurations, the archived redo logs are then applied to the standby database using sustained recovery.
When running the database in managed-recovery mode, you can run in either foreground or background mode. The ALTER DATABASE RECOVER MANAGED STANDBY DATABASE command will start the standby database in foreground managed-recovery mode. The ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION command causes managed standby recovery to occur in the background. You can use the view V$MANAGED_STANDBY to monitor the operations of managed standby database recovery. This view can be used when either foreground or background managed recovery is in use.
When the database is in ARCHIVELOG mode, if the ARCH process could not archive the online redo logs, Oracle would simply continue to run until it could no longer find a free online redo log. When this occurred, the database and user sessions froze, and no new users were able to log into the database. This is still the default behavior in Oracle9i.
With Oracle9i, Oracle now offers a protected failure resolution policy. When the database is configured for this operational mode, if the LGWR process cannot move the redo information to at least one standby site, the primary database will shut down automatically. You can enable this mode by issuing the ALTER DATABASE SET STANDBY DATABASE PROTECTED command. When using this mode, you will need to make sure that the standby database is using two or more standby redo log groups. In addition, you must use LGWR to move the archived redo logs, and you must use the synchronous network transmission mode.
The standby redo logs are a separate set of redo logs and are associated with a physical standby database. Like online redo logs, the standby redo log file is preallocated, and can have multiple members for maximal protection. Standby redo logs must be created on standby databases if you wish to implement a no-data-loss standby database architecture.
You can create standby redo logs on the standby database with the ALTER DATABASE ADD STANDBY LOGFILE statement. Just as with normal redo logs, you can add additional members as required for protection of those logs. The ALTER DATABASE DROP STANDBY LOGFILE command allows you to drop standby redo log files.
Note: The standby redo log files count as part of the maxlogfiles defined in the control file as part of the CREATE DATABASE command.
Standby redo logs will be used when you make LGWR responsible for moving online redo to the standby database. There are other requirements that must be met for standby redo logs to be used. For example, the ARCH process must be active on the standby database, but the standby database need not be in ARCHIVELOG mode. Also, the size of the standby redo logs must match the size of one of the primary database online redo logs, though Oracle suggests you have the same number and size of standby logs as on the primary, or even more.