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.

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.

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.

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.

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.

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.