Standby Database


The standby database is supported officially by Oracle as of Version 8. The Oracle documentation contains detailed information on this database configuration. For more information, see Standby Database Configuration.

Only use the standby database if you are an experienced user.  If you decide to use the standby database, you are fully responsible for correctly configuring and running the standby database.


The SAP tools BRARCHIVE (for backup of offline redo log files) and BRBACKUP (for database backup) support the standby database. For more information, see:

?      Standby Database: BRARCHIVE Backup of Offline Redo Log Files

?      Standby Database: BRBACKUP Backup of Database Files

BRARCHIVE and BRBACKUP support the standby database by helping you to:

?      Copy the offline redo log files from the production database to the standby database, including a check on the copied files

?      Import the offline redo log files into the standby database (recovery), followed by backup of the offline redo log files to tape

?      Back up the standby database

?      Create and configure a new standby database, and reconstruct the production database after a takeover


Before you use the standby database, weigh up the advantages and disadvantages carefully.


?      Very low failure rate

All system components are duplicated. The primary and standby instances can run on different hosts. They can also have separate locations depending on the safety requirements.

?      Very short downtime

If an error occurs in the primary database system and it is necessary to recover the database, you can perform the recovery very quickly on the standby host. This avoids a time-consuming data-file restore, since these files are already located on the standby host. The only thing you need to do is to import the last entries from the redo log files. Therefore, the standby instance can take over the tasks of the primary instance very quickly.

?      Significant decrease of the load on the production host

The database backup requires considerable resources and time for large databases. Since the backup can run on the standby host, the load on the primary instance is reduced significantly. Therefore, the resources on the production host are fully available for production operation, and database operation does not need to be interrupted or restricted for a backup.


?      High costs

For a standby database scenario, all system components must be available in duplicate. In particular, duplicate hardware resources (CPU, hard disks, and so on) are expensive.

?      High system administration expense

You need to set up the standby host. If structural changes are made on the primary database system, make sure these are incorporated on the standby host. When the standby instance has taken over production operation – a “takeover” – you must set up a replacement standby database.

?      High requirements for switchover software

For the standby instance to take over production operation, the appropriate switchover software is required. You need to work with the hardware and software suppliers, who are responsible for selecting this software and ensuring that it functions correctly.