Overview of Oracle Data Guard Architecture

Introduction

Oracle data guard is high availability and disaster recovery solution provided by Oracle. Here we refer production database as primary database and there is another copy of database running which is referred as standby database. Any data guard configuration consists of one primary and one or many standby databases. Standby databases are always in the state of recovery mode and it gets automatically re-synchronized, in case standby goes out of sync, due to network issue etc. There are different types of standby databases

Physical Standby:-

Its is physically identical copy of the primary database on block-for-block basis. Physical standby database gets synchronized with primary via redo apply. Redo data is received from primary database and applied or recovered on to the standby database through redo apply

Logical Standby:-

It contains same logical information as of primary, however physical structure of data can be different. Logical standby database is kept in sync via SQL Apply, which transforms data received from primary into SQL statements and then execute those SQL statements on standby database

Snapshot Standby(New in Oracle 11gR2):-

Snapshot standby allows database to opened in read/write mode. This is new feature in Oracle 11gR2. Physical standby database is converted into snapshot standby and to do this database has to be enabled with flashback mode. Snapshot standby database can be used to perform application testing on production data and transaction processing is allowed on to the database. This snapshot standby database can be converted back to the physical standby

Active Data Guard(New in Oracle 11gR2):- 

Its the Oracle 11g new feature which allows standby database to opened while redo apply is still in progress. You can offload reporting on active data guard so that, load can be reduced on the primary database 

Protection Modes in Oracle Data Guard

Maximum Protection:- It uses SYNC redo transport and commit acknowlegment will not happen in primary until transactions are not applies on to the atleast one standby database. Standby database in this mode guarantees data protection but it causes overhead to the primary database as it was to wait to acknowledge the commit. In case primary is not in sync with standby or there is some transaction faults then the primary database will be shutdown to ensure data protection.

Maximum Performance:- When you configure the standby database, default it operates in maximum performance mode. It allows transactions to be commited as soon as redo data required to recover is written on to the online redolog file. Primary database continues to function even when there is gap between primary and standby database or standby is in out of sync. It uses ASYNC redo transport.

Maximum Availability:- This mode works like the maximum protection mode by default i.e. transactions will not commit on the primary database until transactions are applied to atleast one standby database. But primary database will not be shutdown in case there is transaction fault or standby getting out of sync. When standby database gets out of sync it will wait for number of seconds specified in NET_TIMEOUT parameter, if it exceeds number of NET_TIMEOUT seconds then standby database will start to operate in Maximum performance mode.

Data Guard Services

Redo Transport Service

This service is responsible transfer of redo data from primary to standby database.

LNS (Log Network Service):- reads data from redolog buffer and passes to Oracle Net server for transmission to standby database
RFS (Remote File Server):- receives data from LNS and writes it to the standby redolog file

LNS transfers the data in two modes

Synchronous Mode:- This is also called as "Zero loss method", because LGWR will not commit transaction until LNS confirms transactions have been applied to standby side 
Asynchronous Mode:- In this mode transaction will not wait commit to be successful on the standby, regardless of transaction status on standby database and primary will continue to commit all the transactions happening on the primary side. One of the disadvantage is in case there is a lag between primary to standby database and if primary is lost then there is chance of significant loss of data

Log Apply Service

There are two methods to apply for standby database i.e. Redo apply(physical standby) and SQL apply(logical standby) 

Redo Apply:- Redo apply maintains block-to-block copy of standby database which is in par with primary database. It uses media recovery process(MRP process) that reads records from standby redologs and apply the data received to the standby database

SQL Apply:- SQL apply uses LSP process to apply changes received from primary on to the standby database. It requires more processing than the redo apply and also consumes more system resources like CPU, memory etc. Advantage of using this apply process is standby database can be kept in read-write mode and starting from Oracle 11g logical standby database can be used to perform rolling upgrade

Role Transitions

In Oracle Data Guard, role of the database can be changed either via switchover or failover operation.

Switchover:- Its the role transition from primary to standby and standby database gets converted on to the primary. Switchover ensures there is no data loss occurs and usually it would be planned activity

Failover:- It occurs when primary database is not available or its crashed, this will result in conversion of standby database into primary role