Standby Database Configuration 
This section describes how to configure the Oracle Standby Database. For more information, including advantages and disadvantages of using the standby database, see Standby Database.
When the primary (that is, production) database is duplicated on a standby database, this is referred to as a standby database configuration. The aim of this configuration is to minimize downtime if the primary database suffers an error, since the standby database can assume the role of the productive database in a very short time.
Features
The following graphic illustrates the standby database:
Standby Database Configuration
Two identically configured databases operate on two identically configured hosts:
The primary (that is, productive) Oracle instance is located on the first host. The database is open and fully available for all SQL statements of the SAP System. The primary database system is also the system that directly executes all database requests.
The standby database is a copy of the primary database and is only intended as a recovery system.
The standby Oracle instance on the second host is in a mounted standby state (not opened) and is recovered constantly. This means that the standby instance incorporates all changes to the data of the primary instance either immediately, or with a chosen delay. To do this, the offline redo log files created in the primary database system are applied (only the redo entries already archived by Oracle can be imported).
If it is necessary to recover the primary database system (for example, after a media error), the standby instance can assume the functions of the primary instance in a very short time. This is a “takeover”, which means that the recovery mode of the standby instance is terminated and the standby database is opened for online operation.
Since all data files are already located on the standby host, costly reloading of the files is avoided. Some redo entries might still need to be applied to the files to enable all transactions to be incorporated in the standby instance. This means that you must first import the missing offline redo log files from the primary instance. You can then try to archive the current online redo log file of the primary instance with the Oracle command ALTER SYSTEM ARCHIVE LOG CURRENT and also to import these redo entries in the standby instance.
Caution
If this command fails, it can be very risky to directly apply the current online redo log file to the standby database. If you try to directly apply the redo entries from the online redo log file, you might crash the standby database.
After the takeover, a standby database needs to be set up again (usually on what was the primary host).
Caution
Changes to the physical structure of the primary database (creating new files, renaming files, changes to online redo log and control files) are in most cases automatically incorporated in the standby database. In some cases you might need to intervene depending on the type of change (for example, to create a soft link).
If it is not possible to incorporate the changes automatically, the recovery process is stopped, and you need to intervene manually to incorporate the structural change in the standby database. After that, you need to restart the recovery process.
The original names of the primary database ought to be retained. However, BRBACKUP supports renaming all database files to another SAPDATA_HOME directory of BRBACKUP using the init<DBSID>.sap parameter orig_db_home. If you use this parameter, it is even possible to run the standby database on the same host as the primary database. However, we do not recommend this for high availability.
Caution
If commands are executed in the primary database with the UNRECOVERABLE option, these changes do not appear in the redo log files. It is therefore not possible for the standby instance to receive any information about such changes. In this case, no error messages appear during the recovery process. However, they are recorded in the standby database ALERT file. Therefore, be sure to check the ALERT file regularly.
Note
For more information, see the Oracle documentation. The new and changed SQL and SQLPLUS commands are also described there as well as the necessary init.ora parameters, which are required for working with a standby database.
Activities
To create a standby configuration, you make a copy of the production database as follows:
backup_dev_type = disk_standby|stage_standby
You can then use this as the standby database, as follows:
For more information, see backup_dev_type.