|Oracle Dataguard||Group of services who guarantee HA, data protection and disaster recovery for Oracle databases|
|Oracle Standby Database||The name used for Oracle Dataguard until version 9.0.1. Dataguard == Standby Database|
|Phystdb||Physical standby database|
|Lostdb||Logical standby database|
|Rman||Oracle recovery manager|
The concept of Dataguard is, that a shadow database exists next to a primary database. It protects against dataloss and/or loss of availability.
Two types of standby databases are defined:
Physical Standby database.
The physical standby database is synchronized with the primary database by means of media recovery of the logfiles generated by the primary database.
Because of that, the phystdb is a block-for-block identical copy of the primary database, and therefore suitable for disaster recovery. In case of failure, phystdb is intact and consistent with the primary database.
- Fast failover in case of failure of the primary database
- Possibility to perform controlled switchover for maintenance
- Primary database not being affected when taking backup
- Possibility to open standby database read-only for reporting purposes (also see http://technology.amis.nl/blog/index.php?p=170, section dataguard).
- Protection against logical and user errors
De phystdb is not accessible while changes are being applied.
Logical Standby database
All redo logfiles generated by the primary database, are transformed into logical sql statements and applied onto the logical standby database. This lostdb will contain the same information as the primary db but may have different fysical characteristics. It can be opened read-only and serve as a reporting database (e.g. with different indexes or aggregation-functions).
- Optional reporting on the lostdb
- Possibility to create different objects in the standby database for improved reporting.
- Rolling upgrades of database
Protection modes in Dataguard
Oracle Dataguard is implemented for different reasons. Depending on the level of security wanted, one or more protection modes are available:
- Maximum protection
- Maximum availability
- Maximum performance
This protection mode guarantees that no data loss will occur if the primary database fails. In this mode, the redo data must be written to both the local redo log and to a standby redo log on one ore more standby databases before the transaction commits. The primary database will shut down if it does not succeed in writing its redo stream to at least one remote standby redo log. This way it ensures that data loss will not occur.
Available on physical databases only.
This protection mode provides the highest level of data protection that is possible without affecting the availability of the primary database. Just as in Maximum Protection mode, the transaction does not commit until changes are applied to the local redo log and at least one standby redo log. Difference is, that the primary database will not shut down if it fails to update the standby logs. Instead, the primary database will operate in resync mode until the log gaps have been resolved.
This mode guarantees that no data will be lost if the primary fails, but only if a second fault has not prevented a complete set of redo data from being sent from the primary database to at least one standby database.
For physical and logical standby databases.
This protection mode also provides the highest level of data protection but with a minimum of performance loss. Here, a transaction is committed as soon as the redo data iswritten to the local redo log. The redo data stream to one ore more standby databases is written asynchronously.
Maximum Performance mode is available for Physical and Logical databases.