How Oracle Data Guard Works

<<Back to Oracle DataGuard Main Page

Understanding the Working of Oracle Data Guard

The concept of oracle data guard is designed to utilize oracle redo logs/archive logs to keep the target standby database continuously synchronize with primary database.
There are 2 services which facilities the log transfer (redo or archive) from primary to standby and apply them on the standby and these are
Redo Transport Services: This service performs the following task in Oracle data guard Configuration

• Control the automated transfer of redo data from the production database to one or more standby destinations.
• Manage the process of resolving any gaps between Primary and standby database
• Automatically detect missing or corrupted archived redo log files on a standby system and automatically retrieves replacement archived redo log files from the primary database or another standby database.

Apply Services: Apply services automatically apply the redo /archive logs on the standby database to keep the standby database consistent with the primary database.

Let us see the various possible ways, oracle transfers the redo to the standby database

Flow of Redo from Primary to Standby when no Standby Redo Logs(SRLs) are configured

• Each transaction has redo records into the Redo Log Buffer Cache in SGA.
• The Log Writer Process(LGWR) flushes these redo records from Redo Log Buffer to  Online Redo Log Files
• Archiver process then archives these online redo logs ( normally when the online log file is full and log switch happens) and creates the archived redo log files
• The archiver process is also responsible to ship these archived logs to the standby database server using oracle net services
• On the standby database server there is Remote File Server (RFS) process which receives these archived logs
• The RFS then sends the redo stream to the local Archiver process (ARCn).
• The ARCn (on the standby server) then writes the redo to the archived redo log location on the standby server.
• Once the archived redo log is shipped completely on the standby server, the Managed Recovery Process (MRP0) apply these redo to roll forward the standby database

This process is depicted in the picture above.

What is Standby Redo Logs (SRLs)

SRLs is same as online redo logs but is used only when the database role is standby. If SRLs are configured RFS process writes the redo streams received from primary to these SRLs and MRP process reads the redo directly from SRLs and apply to the standby database (MRP don't have to wait for the archived redo logs). When SRLs are full ( normally when the log switch occurs) the archiver process archives these SRLs and generates archived log files.

Flow of Redo from Primary to Standby when Standby Redo Logs(SRLs) are configured

• Each transaction has redo records into the Redo Log Buffer Cache in SGA.
• The Log Writer Process(LGWR) flushes these redo records from Redo Log Buffer to  Online Redo Log Files
• If DG Configuration is Maximum Protection Mode, then redo transport is SYNC . The Network Server SYNC process (NSSn), also known as Redo Transport Process, is a slave process to LGWR which ships redo to the RFS process on the standby server. The RFS on the standby server simply writes the redo stream directly to the SRLs.
• If DG Configuration is Maximum Performance mode, then redo transport is ASYNC. The Network Server ASYNC process (NSAn), also known as Redo Transport Process, in this case reads redo stream from Online Redo logs and transports them to the RFS process on the standby server. The RFS on the standby server simply writes the redo stream directly to the SRLs.
• If Standby database is using real time apply then MRP process reads the redo stream directly from the SRLs and apply the redo to the standby database.
• If Standby database is not using real time apply, MRP process will wait for the SRL’s contents to be archived. MRP process in this case reads the redo stream from archived logs and apply it to the standby database.