3 Processes That Make Data Guard Work

Have you ever wondered what is happening behind the scene in a Data Guard environment? How and who is sending the logs from the primary to standby? What process is applying the changes on the standby side? How is it all working magically once you set it up? Looking under the hood, there are three processes that make it all work together: one process on the primary database side, and two processes on the standby database side.

As the changes (redo) are generated on the primary database, these changes are transmitted to the standby. On the standby database, the redo is received and written to the standby redo logs, then read and applied. This is how it all works! Do you know what processes make it all possible? This is no secret, but you might not be aware of it. Let me tell you the process names and what they are responsible for!

• LNS – Log Writer Network Server Process
• RFS – Remote File Service Process
• MRP – Managed Recovery Process

LNS – Log Writer Network Server Process

The LNS is a background process, that runs on the primary database, and transmits the redo from the primary to the standby. This process can either work in SYNC mode or ASYNC mode, depending on how you setup the environment, usually through the parameter  log_archive_dest_2. Here is an example where we set the process to async:

alter system set log_archive_dest_2='service=berlin lgwr async noaffirm valid_for=(online_logfiles, primary_role) db_unique_name=berlin';

In synchronous mode the LGWR process waits for confirmation from the standby database, that the redo was applied on the standby database side, before acknowledging a commit on the primary. In asynchronous mode the LGWR process doesn’t wait for confirmation from the standby that the redo was applied. Most Data Guard setups I have seen, use the ASYNC setup, as it is faster than the SYNC setup.

To check on the status of the LNS process and see what the process is doing, you can run the following query on the primary database:

select process, status, sequence#, block# 
from v$managed_standby
where process like '%LNS%';

PROCESS   STATUS        SEQUENCE#     BLOCK#
--------- ------------ ---------- ----------
LNS       WRITING            1012       9876

RFS – Remote File Service Process

RFS is an Oracle background process that runs on the standby database. RFS receives the redo from the primary, from the LNS process, and  writes the redo to the standby log files. To verify the status of this process, run the following on the standby database:

select process, status, sequence#, block# 
from v$managed_standby
where process like '%RFS%';

PROCESS   STATUS        SEQUENCE#     BLOCK#
--------- ------------ ---------- ----------
RFS       WRITING            1012       9877

MRP – Managed Recovery Process

The MRP background process is started when you start the managed recovery process in the background with the following statement:

alter database recover managed standby database disconnect from session;

MRP process reads the redo from the standby redo logs, and then applies the redo to the standby database.

select process, status, sequence#, block# 
from v$managed_standby
where process like '%MRP%';

PROCESS   STATUS        SEQUENCE#     BLOCK#
--------- ------------ ---------- ----------
MRP       APPLYING_LOG       1012       9877

You see that the V$MANAGED_STANDBY view is your friend! You can use this view to confirm that redo is being sent over to the standby and applied. Remember, the flow of redo in a database is continuous, as redo is being generated all the time. There is always something going on in the database, even just Oracle processes updating and writing to the database. You should see a constant change in the SEQUENCE# and BLOCK# in the queries above.

Free Video Tutorial