Why Standby Redo Logs is Required in Oracle Data Guard?

 

This article will help one understand why a standby redo log is required in an oracle data guard and what will happen if we don’t use a standby redo log in an oracle data guard. Our discussion will give you a clear idea of how redo transfer from the oracle Primary database to the standby database as well as it will assist one in troubleshooting real-time log apply as well as the log transfer issues. 

a) Now we are going to briefly describe how redo transport work when Standby Redo Log doesn’t use in the oracle data guard database.

Step 1: A transaction writes the redo record into the buffer log in the System Global Area (SGA)

Step 2: The Log Writer Process (LGWR) writes the undo record from Buffer Log to the Online Redo Log

Step 3: When the Online Redo Log fills up or manually issue log switch command Online Redo Log switch to the next log sequence, and the Archive Process (ARC0) will copy the online redo log to the Archive Redo Log.

Step 4: As standby database exists, another archive process (ARC1) will read the complete Archive log and transfer the redo over the network to the Remote File Server (RFS) process, RFS process is running in Standby Database Instance. 

Step 5: The RFS process sends the redo stream to the local archive process (ARCn) 

Step 6:  The Archive process (ARCn) will write the redo into the Archived Redo Log location on the standby server

Step 7: Once the archive redo log is completed, the Management Recovery Process (MRP0) sends the redo to the standby database instance for applying the transaction. 

b) Here, we would like to explain briefly another scenario if we use standby redo log in oracle data guard database.

Step 1: A transaction writes the redo record into the buffer log in the System Global Area (SGA)

Step 2: The Log Writer Process (LGWR) writes the undo record from Buffer Log to the Online Redo Log

Step 3: If use configured Max performance mode, then ASYNC redo transport is used. The Network Server ASYNC process (NSAn) read the redo from Online Redo Log and transport the redo to the Remote File Server (RFS) process on the standby instance.

Step 4: The Remote File Server (RFS) process on the standby instance simply writes the redo stream directly to the Standby Redo Logs.

Step 5: If we use real-time apply, the MRP0 process will read the redo from Standby Redo Log and apply the redo to the standby database.

Step 6:  If we don’t use real-time apply, then MRP0 process will wait for the standby redo log to be archived, and once archived and once the delay has elapsed, the MRP0 process will start to apply the redo to the standby database. 

Keep learning… Have a great day!!!