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.
Caution
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:
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
Note
You can use BRBACKUP to perform split-mirror backups of your standby database. For more information, see Split Mirror Backup.
You can use BRRECOVER to perform database point-in-time recovery and whole database reset.
You can also use the Oracle Recovery Manager (RMAN) to back up your standby database as follows:
Online backup with backup_type = online_standby
You do not need to stop importing offline redo log files during an online backup with RMAN.
Offline backup with backup_type = offline_standby
You must stop importing offline redo log files during an offline backup with RMAN.
To use the Oracle Recovery Manager (RMAN) for a standby database backup, you need to set one of the following three possibilities in the init<DBSID>.sap parameter file:
backup_dev_type = rman_util|rman_disk|rman_stage
backup_dev_type = tape|tape_auto|tape_box|pipe|pipe_auto|pipe_box
tape_copy_cmd = rman|rman_dd
backup_dev_type = disk
disk_copy_cmd = rman|rman_set
You can even use RMAN to perform level-0 full backups and incremental backups of your standby database.
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.