Oracle Data Guard is used to create and maintain up to nine standby copies of a production database, to assist with disaster recovery and data corruption. This is called a Data Guard configuration. The standby databases can be on the same machine as the production database, or spread over remote data centres, as long as they can communicate with the production database.
The standby databases are initially created from an RMAN backup and are then kept identical to production by transmitting redo log data from the primary database and then applying the logs to each standby database. This is called a transactionally consistent copy, and is better than disk mirroring because the redo logs are created from database changes while they are still in memory, so if any data gets corrupted when it is copied to disk at the primary, this is not mirrored to the standby databases. Oracle itself ensures that data is logically and physically consistent before it is applied to a standby database.
If you need to take the production database down, or if you get an unplanned outage, Data Guard can switch the production workload to any standby database, so minimising downtime. If you are upgrading software, you can also use standby databases to roll out the upgrades, so proving them in a non-production environment before applying them to production.
Any of these databases, production or standby, can be a single-instance Oracle database or an Oracle RAC database. A standby database can be either a physical standby database or a logical standby database. A physical standby database is identical to the primary database on a block-for-block basis. A logical standby database is logically the same as the production database, but the physical organization and structure of the data can be different and it is more flexible as it can be used for reporting, and database upgrades, as well as providing protection from production failures.
Oracle Data Guard has three different types of protection mode, depending on whether data protection, data availability or application performance is most important to you.
Maximum protection mode ensures that no data loss will occur if the primary database fails. The redo data needed to recover each transaction must be written to both the local online redo log and to the standby redo log on at least one standby database before the transaction commits and if it cannot be written to at least one standby log the production database shuts down.
Maximum availability mode is identical to maximum protection mode, except that the primary database does not shut down if it cannot write to a standby redo log. Instead, the primary database switches to maximum performance mode until the problem is resolved.
Sometimes during a problem the redo log data will not be delivered in the right time sequence. In this case, gaps will appear in the redo data, and the redo logs cannot be applied until all those gaps are resolved. This is sorted out automatically by Data Guard, and once the data arrives and the gaps are resolved, Data Guard will automatically put the primary database back into maximum availability mode. In this mode, there will be no data loss if the primary database fails, provided a complete set of redo data has been sent to at least one standby database.
The default mode is Maximum Performance, and this prioritises performance over data protection. However if your network has enough bandwidth so the redo data can be transmitted without problems, then data protection should not be an issue. A transaction is committed as soon as the redo data needed to recover that transaction is written to the primary database online redo log. The redo data stream is written asynchronously to at least one standby database, so there is no guarantee that the standby databases are exact copies of production.Oracle Data Guard Multi-Instance Redo Apply Works with the In-Memory Column Store
You can find some general RMAN information in the RMAN section.
Data Guard provides consistent copies of a production database, so it is possible to use those copies for backup purposes. However because a logical standby database is not a block-for-block copy of the primary database, you cannot use a logical standby database to back up the primary database (but you can backup from a physical standby database).
An RMAN recovery catalog is required in a Data Guard environment to track all the various database backups. Only the primary database is explicitly registered to the RMAN catalog and RMAN will automatically register any physical standby databases if they are connected as targets.
Every database in a Data Guard configuration has a DB_UNIQUE_NAME and the recovery catalog uses this to record which physical files and backups are associated with each database. Backups are associated with the database that created them.
With Data Guard, it is possible to back up a tablespace on a physical standby database and restore and recover it on the primary database. Similarly, you can back up a tablespace on a primary database and restore and recover it on a physical standby database.
If you backup a database to disk, then Data Guard does not make this backup available to any other database for restores. This is because the databases in a Data Guard configuration can be in different sites, and the disks may not be accessible to another site. If a backup goes to tape, then that backup is accessible by all the databases in the configuration.
However, if you need to restore a production database from a standby disk backup, it is possible to FTP the backup to the production site then catalog the backup to the production database.
The database control files are interchangeable. For example, you can restore a standby control file to a primary database. This means that it is possible to just back up control files and archived logs from the standby system and so minimise any performance impact on production.
However please note that Oracle best practice is to take backups of all control files and databases at both the primary and the standby databases as this gives maximum protection from failure and obviates the need to reconfigure backups if you failover between sites.
The backups use the standard Oracle TDPO/RMAN configuration, but it must be possible to backup and recover the database from either the primary or the standbye. To achieve this, you need two different TSM clients defined, one for the primary and one for the standby database, and assuming the primary and standby databases are on separate servers, you need two tdpo.opt files, one on each server. Then for a Unix/Linux implementation you need two dsm.opt files, one for each client and two corresponding stanzas within your dsm.sys file.