Brief Information About the Oracle Data Guard

Hello Friends,

In this article, I will write about Oracle’s disaster recovery (disaster recovery) solution. I will give the basic terminology in a short brief information about the Data Guard .

First, let’s try to understand  the word “Disaster”. We can see some of the disasters occurred in many parts of the world by television, radio, newspapers, etc. through the media .  Some of them lived in the past such as Tsunami in Indonesia , hurricanes and hoses in America , close to the 1999 earthquake in Turkey. Such events is called as disaster. As a result of natural disasters,  If we lose our data center, I’m sure it will be very high cost to us. Our data is very valuable for us to say that even the company’s treasury. Not only natural disasters, instantaneous power failure, disk failures and user errors can give rise to events such as losing our data.

As data managers, we are obligated to take necessary actions before these disasters occur. Also need to consider taking the necessary actions which are very important. These are;

RPO (Recovery Point Objective) – How much data can you afford to lose?

RTO (Recovery Time Objective) – Without data access what time can you stand?

According to the answers of these questions We must establish the backup system. Not satisfied with just setting up our system, and we must monitor our system.

Now, let’s learn Oracle’s beautiful solution “Oracle Data Guard”.

Oracle Data Guard is the disaster recovery solution. Protects our production database from disasters, reducing the work load on it and more effective use it. Technology, first introduced by setting the standby database manually with Oracle 7. Appeared as a Data Guard with Oracle 8i. If we examine a Data Guard features from past to present;


Read-Only Standby Database

Managed recovery

Remote archiving redo log files


“Zero Data Loss” Integration

Data Guard Broker and Data Guard Manager GUI

Swithcover and Failover operations

Automatical synchronous

Logical Standby Database

Maximum Protection


Real-Time Apply

Forced support for Oracle RAC

Fast-Start Failover

Asynchronous redo transfer

Flashback Database


Active Standby Database (Active Data Guard)

Snapshot Standby

Heterogeneous platform support (Production –Linux, Standby – Windows)

Characteristics and evolved over time as it stands today.


Process flow;

1 – The user initiates a transaction. This transaction is written to a redo buffer. When the user commit the transaction then the LGWR process writes it redo log file.

2 LNS (logwriter Network Service) reports to RFS (Remote File Service) committed redo. RFS writes to standby redo log file. If we use physical standby, the MRP (Managed Recovery Process) will apply to standby database . In  Logical Standby this is made by LSP (Logical Standby Process) .

3 – RFS sends information to LNS that data is processed successfully. LNS transmits this information to LGWR . Finally, commit information is send to the user that initiated the transaction (transaction) .

Data transfer is ensured by the synchronous redo transfer. But there is a disadvantage. If  a network failure occurs between production database (Primary) and the standby database  or  Primary database can not access  to the standby database then the primary database  will hang until standby response. In other words, the primary database can not serve. To avoid such situation, I think the most logical one to use “NET_TIMEOUT” parameter. With this parameter you can determine the timeout period. In case of an outage, Primary waits until the timeout period and will continue to serve when timeout period expires. Default value of this parameter in 10g is 180s and in 11g is 30s.


Asynchronous reod transfer flow;

1 – The user initiates a transaction. This transaction is written to a redo buffer. When the user commit the transaction then the LGWR process writes it redo log file.

2 – LNS (logwriter Network Service) reports to RFS (Remote File Service) committed redo. RFS writes to standby redo log file. If we use physical standby, the MRP (Managed Recovery Process) will apply to standby database . In  Logical Standby this is made by LSP (Logical Standby Process) .

3 – Once Redo Buffer is recycled, LNS  automatically reads redo log files and begins to send redo from log files.

RFS doesn’t send information to LNS that data is processed successfully.

The most common used process architecture. Asynchronous redo transfer does not guarantee zero data loss. The system has recovered with minimal data loss.


There are 3 protection modes. Summarized in the table below.

Mode The risk of data loss Transfer method Primary status
Maximum Protection Zero data loss – two-sided protection SYNC primary waits for the receipt of information. if it doesn’t respond to primary, primary hangs
Maximum Availability Zero data loss – single-sided protection SYNC primary waits for the receipt of information. if it doesn’t respond to primary, primary waits until the timeout parameter . (NET_TIMEOUT)
Maximum Performance least data loss ASYNC primary never waits for the receipt of information


Physical Standby Database is block by block  copy of production database. It uses database recovery function to apply the changes. When redo apply is active, it can be opened for reporting and querying in read-only mode (a feature that comes with the Active Data Guard-11g). Also it can be used for backup operations. For opening in Read-Write mode, you must enable Flashback log . Onece Flashback log enabled you can open it in read-write mode after creating restore point. And again you can revert to standby. I have explained above, with one of the desired modes you can transfer redo. I’ll write the next article on Creating Standby Database with RMAN Active Database Duplication in 11gR2

In some cases, you may want to create a time lag between the time when redo data is received from the primary site and when it is applied to the standby database. If you enabled the delayed apply, then real-time apply will be disabled. Real-time apply can be activated as follows.

SQL>alter database recover managed standby database using current logfile disconnect;

If the real-time apply feature is enabled as shown above , log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. This results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins. As the remote file server (RFS) process writes the redo data to standby redo log files on the standby database, log apply services can recover redo from standby redo log files as they are being filled.

Delayed apply can be activated;

SQL> alter database recover managed standby database delay 10;


A snapshot standby database is a fully updatable standby database that is created by converting a physical standby database into a snapshot standby database. Snapshot standby is a feature that comes with 11g. A snapshot standby database receives and archives, but does not apply, redo data from a primary database. Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database. When it is converted back into a  physical standby database, it discars all local updates. You can do test, patch, etc.  by opening it in Read-write mode the test.


Logical Standby Databases are logically identical to primary databases although the physical organization and structure of the data can be different. Logical Standby Databases are updated using SQL statements. Logical standby database can be used for recovery and reporting simultaneously. Determine if the primary database contains tables and datatypes that were not supported by a logical stand by database. If the primary database contains tables that were unsupported, log apply services will exclude the tables applying to the logical stand by database. Run the following queries to see unsupported tables.




Thanks to this feature that comes with 11g standby database can be open in read-only mode while redo apply  (Read-Only with Apply). Therefore, the database is called the Active Standby. If we look at in terms of benefits to us of the Active Data Guard; We can make our real-time reporting (while continuing to apply redo),backup operations through the active standby database.Thus, we will reduce the processing load of production. Production database will serve our customers more effectively.

The other beauty that comes with 11g R2 is standby database count. Prior to 11g R2, you can use 9 standby database at the same time. With 11g R2 you can use 32 standby database at the same time.


Finally, I want to mention briefly the terms of switchover and failover.Switchover is the planned role change. It does not require re-installation of a new database. It can be used to test interoperability of  standby database, OS and hardware maintenance. The failover is the deformation of the production (primary) database and activating standby database as the primary. It is not reversible. When enabled, re-create the standby database.

Pictures that I used from sources:

Oracle Data Guard 11g Handbook – Charles Kim

Talip Hakan Öztürk


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s