Recovery Process Flow of Physical Standby

The Actual Recovery Process Flow of Physical Standby (10gR2 & 11G)

Story is to present the step by step process how recovery is performed at standby side.

Let’s start the journey with important background process:

From Primary side :-

ORL: Online redo log file. Any changes happen, it is captured and store in redo log file that is very frequently also called ORL.

LGWR: The log writer process flushes the data from log buffer (SGA) to ORL.

LNS: The Logwritter Network Services which read the redo being flushed from the log buffer and send over the network to standby site.

ARCH: The Archiver process the archive the ORL.

From Standby Side:-

RFS: Remote file server process and its main objective is to receive the data send by LNS process and write into the Standby redo logfile.

MRP: The managed recovery process and it work for the media recovery management.

PROx: Works as recovery process.

Objective is to focus on how data is received and it is applied to the standby. I will try to cover the step by when replicated data is written in datafiles for standby database.

The actual Recovery process done in three phases:

As data is collected by the LNS process and send over the network. Where it is recoved by the RFS process and written down to standby redo logfile. So upto now, the replicated data or better say changes are present in standby redo logfile.

Log red phase: The background process MRP will keep reading the SRL asynchronously. Many times it also read from archived log files when recovery falls behind the real time apply. The blocks that require the redo apply (changes) and parsed and placed into the memory.

Redo Apply phase: The MRP process transfer redo data to the recovery slaves process using the parallel query process. the Parallel media recovery (PMR) causes the required data block to be read into the buffer cache and apply redo changes to the buffer in buffer cache.

Checkpoint phase: This is the last step performed in recovery phase. It involves the flushing the recently modified data to the disk and also update the datafile header to record checkpoint completion.

Real Time Apply: So in brief redo is received by RFS on the standby system, The RFS process writes the redo to SRL and thus changes where directly captured and applied. This is also called as Real Time Apply in terms of standby database.

Following command is needed to start RTA (Real Time Apply) that is to be executed at sql prompt.

alter database recover managed standby database using current logfile disconnect;

Below can be used to check where RTA is started that is to be executed at Primary side.

select recovery_mode from v$archive_dest_status where dest_id=2;