DataGuard Process Architecture

As shown in the figure below, the Data Guard operations involve many processes.



Let us see what each process is used for one by one,

In the Primary Site,

LGWR or ARCH: The redolog/archivelog from the primary database is shipped to the standby database site through LGWR/ARCH processes.

FAL (Fetch Archive Log): When there is a communication loss between primary and standby (for example, network failure), the log shipping is affected and there may be gaps. When the communication is established again the FAL processes enable the automatic gap resolution and resynchronization process.

In the Standby Site,

RFS (Remote File Server): The RFS process receives the redo records from the Primary site.

MRP (Managed Recovery Process): MRP applies the redo records to the Physical Standby databases.

LSP (Logical Standby Process): The LSP process translates the redo records in to SQL and fires the SQL to the logical standby databases.

If Data Guard Broker is enabled then DMON Process is enabled on both the primary and standby sites.

Thanks

Difference between Physical and Logical Standby

The Data Guard Configuration consists of one Production database and upto nine Standby databases. The production database can be a single instance or RAC database similarly Standby database can be single instance or RAC database. It is also possible to have single instance standby database for a RAC production database.

The standby database is a transactionally consistent copy of the production database. It is created initially from the backup of production database. Once created, the data guard automatically synchronizes the standby.

There are two types of standby database, they are

1. Physical Standby
2. Logical Standby

Physical standby uses the recovery technique to sychronize the standby database where as logical standby uses the sql apply method to synchronize both the database.
The following table provides you with the difference between physical and logical standby databases,

S.No	Physical Standby	Logical Standby
1	Identical to the Primary database including the physical organization inthe disk	Same logical information but physical organization and the structure ofdata are different.
2	DG uses Redo Apply technology, which applies redo data using standardrecovery techniques.	DG uses SQL Apply, which first transforms the redo data into SQLstatements and then executes the statement.
3	Can be used for Backups	Can be opened for reporting.
4	All data types are supported	Not all data types are supported for eg. LONG, NCLOB, LONG RAW, BFILE, XML types are not supported.
5	Can open in ‘Read only’ but cannot apply logs. From 11g open in‘read write’.	Can open in normal mode and simultaneously apply the logs.
6	No additional objects can be created.	Additional indexes, materialized views can be created

Usually organizations use Logical Standby databases mainly for reporting purposes and not for failover/switchover operations. For failover and switchover they use physical standby database. The reason is maintaining logical standby is almost a full time job, need extensive tuning of log apply services, and over hundreds of patches, the logical is usually 3 to 5 hours behind the live database, thus making it impossible for failover/switchover.

Thanks

DataGuard Features History

The concept of Standby database was existing since the Oracle version 7.3. Since then it had undergone a lot of changes and improvements. Let us summarise these changes/improvements from version 7.3 through 11g.

Oracle 7.3: Introduces Standby database. In this release the process of transferring archived redo logs was manual.

Oracle 8i: Supported the automatic shipping and application of archived redolog files from the primary site to standby site. It also supported opening of standby database for read only, however the recovery process must be stopped inorder to open it in read only mode.

Oracle 9iR1: Supported automatic gap resolution. Introduced various protection modes. Also introduced DataGuard Broker, an interface to manage the dataguard environment.

Oracle 9iR2: Introduced the concept of Logical Standby Database.

Oracle 10g: Introduced Real Time Apply, Fast Start Failover, Provided RAC support.

Oracle 11g: Introduces Active Dataguard which enables you to open the physical database in read only mode while the redo apply is active. Introduces Snapshot standby and redo compression.