ORACLE – Introduction to Oracle Data Guard

Share via:

Introduction to Oracle Data Guard


Data Guard gives us the high availability, data protection and disaster recovery for the data. Configuring one or more standby databases for the production database can help in surviving the disasters and data corruptions.

The Oracle Data Guard can switch the standby database to the production less downtime in an unscheduled maintenance of the databases.

Oracle data guard configurations.

An Oracle data guard can contain one primary database and up to 30 standby databases. These standby databases can be in a different location (data centers) as long as they can communicate with each other.

  1. Primary Database.

Consists of one production database which is accessible by the applications which are also called as the primary database.


The primary database can be either single instance or the RAC database.


  1. Standby Database.

A standby database is the transactional consistent copy of the primary database. Using the backup copy of the primary database we can configure up to 30 standby databases.

Once the dataguard is configured, it will automatically manage the standby database by taking the redo data from the primary database and applying them on the standby database.


The standby database can also be either a single instance or a RAC database.


Types of Standby databases.


There are 3 types of standby databases.

  1. Physical Standby database
  2. Logical standby database
  3. Snapshot standby database.


Physical Standby database.


A standby database is an identical copy of the primary database with the database structure.

Example. Schemas including indexes are same as primary.


A physical standby database is kept in sync with the primary database through Redo apply, which recovers data received from the primary database and applies the redo to the physical standby database.


Till Oracle Database 11g Release 1 (11.1), a physical standby database can receive and apply redo while the database is in read-only access.

A physical standby database can, therefore, be used concurrently for data protection and reporting.


From Oracle Database 11g Release 2 (, a physical standby database can be used to install one-off patches, patch set updates (PSUs), and critical patch updates (CPUs), in rolling fashion.


Logical Standby database.

Contains the same logical information as the production database, but the physical organization and structure of the data may be different.

The logical standby database is kept sync with the primary database through SQL Apply, which transforms the data in the redo received from the primary database into SQL statements and then executes the SQL statements on the standby database.

Logical standby database supports Oracle Database software upgrade (patch sets and new Oracle Database releases) and performing other database maintenance in rolling fashion with almost no downtime.

From Oracle Database 11g onward, the transient logical database rolling upgrade process can also be used with existing physical standby databases.


Snapshot Standby database. 

Like a Physical and Logical standby database, snapshot database receives and archives the redo data from the primary database.

But snapshot standby will not apply the redo data. This redo will be applied only after the snapshot database is converted into the physical standby database.

From transport of redo data to a Recovery Appliance is supported in Oracle Dataguard.

This is also called as Zero data loss Recovery Appliance which is an Enterprise-level-backup solution that provides a single repository for backups for all the Oracle databases which is a centralized backup system.


Oracle Data Guard Configuration.


Oracle Dataguard Services:


REDO Transport Service.

Control the automated transfer of redo data from the production database to one or more archival destinations.


Redo transport services perform the following tasks.

  • Transmit redo data from the primary to the standby in the configuration
  • Manage the process of resolving any gaps in the archived redo log files due to a network failure
  • Automatically detect missing or corrupted archived redo log files on a standby and automatically retrieve replacement archived redo log files from the primary database or another standby database

Apply Services.

The redo data from the primary database is written to the standby redo log on the standby database.

Apply services automatically apply the redo data on the standby database to maintain consistency with the primary database. It also allows read-only access to the data.

The main difference between physical and logical standby databases is the manner in which apply services apply the archived redo data.

  • For physical standby databases, Oracle Data Guard uses Redo Apply technology, which applies redo data on the standby database using standard recovery techniques of an Oracle database.


Automatic Updating of a Physical Standby Database



For logical standby databases, Oracle Data Guard uses SQL Apply technology, which first transforms the redo data into SQL statements and then executes the generated SQL statements on the logical standby database.


Automatic Updating of a Logical Standby Database.


  1. Data Guard Observer.

Process monitors both primary and standby databases and performs an automatic failover when necessary.


  1. The Broker:


The management framework for Oracle Data Guard. It comes integrated into the Oracle database enterprise edition.

  1. Fast Start Fail Over (FSFO):

Automatic failover to the standby database occurs in case of failure. FSFO requires the broker.


 Role Transitions.


Using Oracle Data Guard, you can change a database from primary to standby or from standby to primary using either a switchover or a failover operation.

switchover is a role used to change the primary database and one of its standby databases. A switchover ensures no data loss. The switchover is used for a planned maintenance of the primary database for testing.

failover is when the primary database is unavailable. Failover is performed only when there is a failure of the primary database.


Oracle Data Guard Protection Modes.


There are Modes of Oracle DataGuard.

Maximum Availability.

This protection mode provides the highest level of data protection with almost zero data loss. Transactions do not commit until all redo data written to online redo logs and to at least one synchronized standby database.

If the primary database cannot write its redo’s to at least one synchronized standby database, the primary will not shut down and operates as it is where in maximum performance mode to preserve primary database availability until issue is fixed.

This protection mode ensures zero data loss except in the case of certain double faults, such as failure of a primary database after failure of the standby database.


Maximum Performance.


This is the default protection mode. It provides the highest level of data protection that is possible without affecting the performance of a primary database.


This is possible by allowing transactions to commit as soon as all redo data has been written to the online log. Redo data also written to one or more standby databases asynchronously with respect to the committed transaction so that the primary database performance is unaffected by delays in writing redo data to the standby database.


This protection mode offers less data protection compared to maximum availability mode and has minimal impact on primary database performance.


Maximum Protection.

This protection mode ensures that no data loss occurs if the primary database fails. To provide this level of protection, the redo data needed to recover a transaction must be written to both the online redo log and to the standby redo log on at least one standby database before the transaction commits.Here transactions are not allowed to commit until the redo data is written to the online redo logs and to the standby database to ensure no data loss.



ORACLE – Creating a Data Guard Physical Standby environment – PART1

Share via:
Note: Please test scripts in Non Prod before trying in Production.
1 Star2 Stars3 Stars4 Stars5 Stars (14 votes, average: 5.00 out of 5)

Add Comment