Oracle Data Guard

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.

Simple Example:

Your primary database is running and you want to reduce downtime because of unplanned outages. You create a replica of this primary database (termed as standby database).You regularly ship redo generated in the primary database to standby database and apply it there. So that is our ‘Data Guard’ standby database and it is in a continuous state of recovery, validating and applying redo to remain in sync with the primary database.

Oracle Dataguard provides enhancements in different versions:

->ORACLE 8i

-Read-Only Standby Database
-Managed recovery
-Remote archiving redo log files

->ORALCE 9i

-“Zero Data Loss” Integration
-Data Guard Broker and Data Guard Manager GUI
-Swithcover and Failover operations
-Automatical synchronous
-Logical Standby Database
-Maximum Protection

->ORACLE 10g

-Real-Time Apply
-Forced support for Oracle RAC
-Fast-Start Failover
-sAsynchronous redo transfer
-Flashback Database

->ORACLE 11g

-Active Standby Database (Active Data Guard)
-Snapshot Standby
-Heterogeneous platform support (Production –Linux, Standby – Windows)
-Active Data Guard is another extension of physical standby, which is open in read-only mode, but applying the logs in the background. This keeps the database up-to-date and allows Real-Time Queries During Managed Recovery process.
-Zero data loss DR protection across any distance without impacting performance


DATA GUARD 11g SYNCHRONOUS REDO TRANSFER PROCESS ARCHITECTURE (SYNC)-ZERO DATA LOSS

Sync 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, We need 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.

DATA GUARD 11g ASYNCHRONOUS REDO TRANSFER PROCESS ARCHITECTURE (ASYNC)

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.