MRP - Managed Recovery Process in Oracle Data Guard

Oracle Data Guard — Managed Recovery Process (MRP) / Redo Apply

The Managed Recovery Process (MRP) is a key component of an Oracle Data Guard physical standby database. It is responsible for applying redo generated by the primary database to the physical standby database so that the standby can remain synchronized with the primary.

Oracle Data Guard is widely used to provide high availability, disaster recovery, data protection, and business continuity for Oracle Database environments.

In a physical standby configuration, redo generated on the primary database is transported to the standby database. The standby then uses Redo Apply to apply that redo to its datafiles. The MRP is the process associated with this managed recovery operation.

Oracle describes a physical standby database as a block-for-block copy of the primary that is maintained through Redo Apply, which continuously applies redo received from the primary using Oracle database recovery mechanisms.

---

What Is MRP?

MRP stands for Managed Recovery Process.

It is the Oracle background recovery process responsible for applying redo information to a physical standby database when managed recovery is running.

In simple terms:

Primary Database
       |
       | Redo
       v
   RFS Process
       |
       v
Standby Redo Log / Archived Redo Log
       |
       v
      MRP
       |
       v
Standby Datafiles

The important point is that MRP does not generate redo on the primary database. Its job is to consume redo that has reached the standby and apply the corresponding changes to the standby database.

---

MRP and Oracle Data Guard

A Data Guard configuration normally contains a primary database and one or more standby databases.

For a physical standby, Oracle uses Redo Apply to maintain the standby as a synchronized copy of the primary.

The overall process can be represented as:

Application
     |
     v
Primary Database
     |
     | Redo Generation
     v
Redo Transport
     |
     v
Standby Database
     |
     v
RFS
     |
     +-----------------------+
     |                       |
     v                       v
Standby Redo Log       Archived Redo Log
     |                       |
     +-----------+-----------+
                 |
                 v
                MRP
                 |
                 v
          Standby Datafiles

Oracle Data Guard separates the work into major services, including Redo Transport Services and Apply Services. Redo Transport moves redo from the primary to the standby, while Apply Services applies that redo on the standby.

---

MRP vs Redo Apply

These terms are closely related but should not be treated as exactly identical.

Term	Meaning
Redo Apply	The Data Guard mechanism used to apply redo to a physical standby database.
MRP	The managed recovery process associated with applying redo on a physical standby.
RFS	Remote File Server process that receives redo transported from the primary.
Standby Redo Log	Redo log files on the standby that receive redo transported from the primary.
Archived Redo Log	A completed redo log that can be used by the standby for recovery.

---

MRP Architecture

Understanding the processes involved in Data Guard is important when troubleshooting standby synchronization problems.

1. Primary Database

The primary database generates redo whenever transactions modify database blocks.

For example:

INSERT
UPDATE
DELETE
DDL
Transaction Commit

These operations generate redo information that can subsequently be transported to the standby database.

---

2. Redo Transport

Data Guard's redo transport mechanism transfers redo from the primary database to configured standby destinations.

Depending on the configuration, redo can be transported using the primary database's transport processes and received by the standby's RFS process.

Oracle describes Redo Transport Services as responsible for transmitting redo data from the primary to standby systems and for helping manage redo gaps.

---

3. RFS — Remote File Server

The RFS process runs on the standby system and receives redo sent from the primary database.

Depending on the Data Guard configuration, RFS writes incoming redo into standby redo logs or receives archived redo information.

Oracle documentation describes RFS as the process that receives redo on the standby, while MRP performs the apply operation.

---

4. Standby Redo Logs

A Standby Redo Log (SRL) is similar to an online redo log but is used by a standby database to receive redo transmitted from the primary.

Standby redo logs are particularly important for real-time apply.

With real-time apply, redo can be applied directly from the standby redo log while it is being filled instead of waiting for the entire log to be archived.

Primary
   |
   | Redo
   v
RFS
   |
   v
Standby Redo Log
   |
   | Real-Time Apply
   v
MRP / Redo Apply
   |
   v
Standby Datafiles

---

5. MRP — Managed Recovery Process

The MRP performs the recovery/apply work required to bring the physical standby database forward using redo received from the primary.

Conceptually:

Redo Received
      ↓
Redo Available on Standby
      ↓
MRP Reads Redo
      ↓
Recovery Processing
      ↓
Database Blocks Updated
      ↓
Standby Advances

This is why an MRP problem can cause the standby database to fall behind even when redo transport from the primary is working correctly.

---

Archived Redo Apply vs Real-Time Apply

There are two important concepts to understand when discussing how redo reaches MRP.

Archived Redo Apply

In the traditional model, redo is first received and archived on the standby. Redo Apply then applies the completed archived log.

Primary
  ↓
Redo Transport
  ↓
Standby
  ↓
Archive Log
  ↓
MRP
  ↓
Standby Database

This means the apply process may need to wait until the relevant redo is available as a completed log.

---

Real-Time Apply

With real-time apply, Redo Apply can use the current standby redo log while the redo is still being received.

Primary
  ↓
Redo Transport
  ↓
RFS
  ↓
Standby Redo Log
  ↓
MRP
  ↓
Standby Database

          ↑
     No need to wait
     for full archive

Oracle documents real-time apply as applying redo from the current standby redo log as it is being filled, which can reduce the delay between primary and standby and improve switchover/failover readiness.

---

Why Is MRP Important?

A Data Guard standby database is useful only if it can remain sufficiently synchronized with the primary.

If redo transport is working but Redo Apply is stopped, the standby can continue receiving redo while the unapplied redo accumulates.

For example:

Primary generates redo
        ↓
Redo reaches standby
        ↓
RFS receives redo
        ↓
MRP is stopped
        ↓
Redo accumulates
        ↓
Apply lag increases
        ↓
Standby becomes increasingly behind

Therefore, when investigating a Data Guard problem, a DBA should determine whether the problem is in:

• Redo generation
• Redo transport
• Redo reception
• Standby redo logging
• Redo Apply/MRP
• Archive-gap resolution
• Standby storage or database health

---

How to Check Whether MRP Is Running

One of the first commands an Oracle DBA can use on a physical standby is:

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#
FROM V$MANAGED_STANDBY;

Depending on the Oracle Database release, the exact process information exposed by dynamic performance views can differ. Therefore, use the views and columns supported by your installed release.

On systems where the view reports MRP, an output might look conceptually like:

PROCESS   STATUS        THREAD#   SEQUENCE#
-------   ------------  -------   ---------
MRP0      APPLYING_LOG       1       12543
RFS       RECEIVING           1       12544

The important information is whether the recovery process is active and whether it is applying redo.

---

Useful MRP Status Values

Depending on the Oracle release and view being queried, you may encounter statuses such as:

• APPLYING_LOG — redo apply is actively processing a log.
• WAIT_FOR_LOG — apply is waiting for the next required redo.
• WAIT_FOR_GAP — a required archive-log gap must be resolved.
• ERROR — an error has occurred during processing.
• CONNECTED — a process is connected and participating in the Data Guard operation.

Do not interpret a waiting status automatically as a failure. For example, if MRP is waiting for a log and the standby is fully caught up, that can be normal.

---

MRP Is Not the Same as RFS

This distinction is extremely important during troubleshooting.

Process	Main Responsibility
RFS	Receives redo transported from the primary.
MRP	Applies redo to the physical standby.
ARCn	Handles archiving of redo, including standby redo log archival as applicable.

For example, if RFS is receiving redo but MRP is not applying it, the transport side may be functioning while the apply side is not.

---

Typical Data Guard Flow

A simplified physical standby architecture looks like this:

                    PRIMARY DATABASE
                           |
                           |
                    Redo Generation
                           |
                           v
                   Redo Transport
                           |
                           |
=========================== NETWORK ===========================
                           |
                           v
                    STANDBY DATABASE
                           |
                           v
                          RFS
                           |
                +----------+----------+
                |                     |
                v                     v
        Standby Redo Log       Archived Redo Log
                |                     |
                +----------+----------+
                           |
                           v
                          MRP
                           |
                           v
                    Redo Apply
                           |
                           v
                  Standby Datafiles

This architecture explains why Data Guard troubleshooting should normally be divided into two major areas:

1. Redo Transport — can redo reach the standby?
2. Redo Apply — can the standby apply the received redo?

---

MRP and Physical Standby Database

MRP/Redo Apply is specifically associated with maintaining a physical standby through redo-based recovery.

A logical standby uses a different apply mechanism called SQL Apply, which reconstructs SQL statements from redo and executes those statements against the logical standby.

Oracle explicitly distinguishes Redo Apply for physical standby databases from SQL Apply for logical standby databases.

Standby Type	Apply Technology
Physical Standby	Redo Apply
Logical Standby	SQL Apply

---

What Happens When MRP Stops?

If MRP stops while redo transport continues, the standby can accumulate redo that has not yet been applied.

For example:

Primary
  |
  | Redo
  v
Standby
  |
  | RFS receives redo
  v
Redo stored
  |
  X
MRP stopped
  |
  v
Redo not applied
  |
  v
Apply lag increases

This is one of the most common situations an Oracle DBA investigates when a standby database is reported as being behind the primary.

However, a standby being behind does not necessarily mean that MRP itself is broken. The underlying issue could be network transport, missing archive logs, storage problems, I/O performance, insufficient apply capacity, or another Data Guard configuration issue.

---

Real-Time Apply and MRP

Real-time apply is an important feature for modern Data Guard environments.

When standby redo logs are configured, Redo Apply can apply redo directly from those logs while they are being populated by RFS.

This reduces the need to wait for a complete archived log before applying its redo. Oracle notes that this can improve synchronization and reduce the amount of redo remaining to be applied during a role transition.

Conceptually:

Without Real-Time Apply:

Redo
 ↓
Standby Redo Log
 ↓
Log Archived
 ↓
MRP
 ↓
Apply


With Real-Time Apply:

Redo
 ↓
Standby Redo Log
 ↓
MRP
 ↓
Apply while log is being filled

---

When Should a DBA Check MRP?

You should investigate MRP/Redo Apply when you observe symptoms such as:

• Standby database apply lag increasing.
• Standby is not synchronized with the primary.
• Redo logs are arriving but not being applied.
• MRP is not visible or is stopped.
• Data Guard reports an apply error.
• Switchover readiness is affected by unapplied redo.
• A standby database has entered an unexpected recovery state.
• Archive gaps are reported.
• Standby storage is full or nearly full.

---

Important DBA Commands — Introduction

The detailed troubleshooting procedures will be covered in Parts 2 and 3. However, the following commands are useful starting points:

Check Database Role

SELECT DATABASE_ROLE,
       OPEN_MODE,
       DB_UNIQUE_NAME
FROM V$DATABASE;

Check Managed Recovery Processes

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#
FROM V$MANAGED_STANDBY;

Check Archive Destination Status

SELECT DEST_ID,
       STATUS,
       DESTINATION,
       ERROR
FROM V$ARCHIVE_DEST
WHERE STATUS <> 'INACTIVE';

Check Recent Archived Logs

SELECT THREAD#,
       SEQUENCE#,
       FIRST_TIME,
       NEXT_TIME,
       APPLIED
FROM V$ARCHIVED_LOG
ORDER BY THREAD#, SEQUENCE#;

These views form the foundation of Data Guard monitoring, but the exact columns and recommended monitoring approach depend on the Oracle Database release and whether Data Guard Broker is being used.

---

Oracle DBA Tip

When troubleshooting Data Guard, do not immediately assume that MRP is the problem. Always separate the investigation into redo generation → redo transport → redo reception → redo availability → redo apply. This approach makes it much easier to identify the actual point of failure.

---

MRP — Managed Recovery Process in Oracle Data Guard

Starting, Stopping, Monitoring and Troubleshooting Redo Apply

In this section, we move from architecture to practical Oracle DBA administration. We will see how to start and stop Redo Apply, verify MRP status, monitor transport and apply lag, identify archive gaps, and perform an initial investigation when a physical standby database is not applying redo.

---

1. Prerequisites Before Starting MRP

Before starting Redo Apply, verify that the database you are working on is actually a physical standby database.

Run:

SELECT DATABASE_ROLE,
       OPEN_MODE,
       DB_UNIQUE_NAME
FROM V$DATABASE;

A typical physical standby may report:

DATABASE_ROLE    OPEN_MODE
---------------  --------------------
PHYSICAL STANDBY MOUNTED

The exact open mode depends on the configuration and Oracle Database release. For example, an Active Data Guard environment can have a physical standby open read-only while Redo Apply is active.

The important point is that the standby must be in an appropriate state for the Redo Apply operation you are attempting to start.

---

2. Start Redo Apply / MRP

For a physical standby database, Redo Apply can be started using:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

This starts managed recovery and returns control to the SQL session.

Oracle documentation shows ALTER DATABASE RECOVER MANAGED STANDBY DATABASE as the command used to start Redo Apply on a physical standby.

The DISCONNECT FROM SESSION clause is commonly used when the DBA wants recovery to continue as a background operation rather than keeping the current SQL session occupied.

---

3. Start MRP in the Foreground

Redo Apply can also be started without disconnecting the session:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE;

In this mode, the recovery operation remains associated with the current session. Oracle documentation notes that Redo Apply can run as either a foreground session or as a background process.

For normal production administration, DBAs commonly use the disconnected/background form so that the SQL session remains available.

---

4. Start Real-Time Apply

Real-time apply allows Redo Apply to use redo from the current standby redo log while that redo is being received.

In current Oracle Database releases, the following command starts Redo Apply:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

When the standby is configured with standby redo logs and is running in ARCHIVELOG mode, Oracle can automatically enable real-time apply with this command.

Older Oracle versions commonly used:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
USING CURRENT LOGFILE
DISCONNECT FROM SESSION;

Important: The USING CURRENT LOGFILE clause is historical syntax. Oracle documentation states that it is deprecated from Oracle Database 12c Release 1 because real-time apply is enabled automatically when the required standby redo logs are configured.

---

5. Stop MRP / Redo Apply

To stop Redo Apply on a physical standby database, use:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Oracle documents this statement as the command for stopping Redo Apply.

After stopping recovery, verify the status:

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#
FROM V$MANAGED_STANDBY;

Depending on the Oracle release, V$MANAGED_STANDBY may expose different process information. On newer releases, Oracle recommends using the appropriate current Data Guard monitoring views and interfaces where applicable.

---

6. Verify That MRP Is Running

A simple check is:

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#,
       BLOCK#,
       BLOCKS
FROM V$MANAGED_STANDBY
ORDER BY PROCESS;

A traditional output may look like:

PROCESS   STATUS         THREAD#  SEQUENCE#  BLOCK#  BLOCKS
--------  -------------  -------  ---------  ------  ------
RFS       RECEIVING             1      12543      72      72
MRP0      APPLYING_LOG          1      12542      10      72

This output should be interpreted as a snapshot of Data Guard activity.

For example:

• RFS receiving indicates redo is being received.
• MRP applying indicates Redo Apply is processing redo.
• A sequence difference may indicate that transport and apply are at different points.

However, sequence numbers alone should not be used to diagnose every Data Guard problem. Always combine them with lag, archive-gap, destination status and Data Guard alert information.

---

7. MRP Status: APPLYING_LOG

One of the most desirable statuses is:

MRP0    APPLYING_LOG

This generally means that Redo Apply is actively processing a redo log.

For example:

PROCESS   STATUS
--------  -------------
MRP0      APPLYING_LOG

This is normally a positive indication, but it does not by itself prove that the standby is fully synchronized.

A standby may still have significant apply lag even though MRP is actively applying redo.

---

8. MRP Status: WAIT_FOR_LOG

You may see:

MRP0    WAIT_FOR_LOG

This does not automatically mean that MRP has failed.

If the standby has applied all redo currently available and is waiting for the next redo, this can be a normal state.

The DBA should therefore ask:

• Is the primary generating redo?
• Is redo being transported?
• Is RFS receiving redo?
• Is the standby receiving the latest sequence?
• Is there an archive gap?
• Is the standby destination healthy?

Only after answering these questions should the DBA conclude that the apply process is stuck.

---

9. MRP Status: WAIT_FOR_GAP

Another important state is:

MRP0    WAIT_FOR_GAP

This indicates that Redo Apply cannot continue because a required redo sequence is missing.

For example:

Primary:
Sequence 100
Sequence 101
Sequence 102
Sequence 103

Standby:
Sequence 100
Sequence 101
Sequence 103

Missing:
Sequence 102

MRP cannot simply skip sequence 102 and continue with sequence 103 because the missing redo may contain database changes required to bring the standby forward consistently.

---

10. Check for an Archive Gap

On a physical standby, one of the most useful commands for identifying the current blocking archive gap is:

SELECT THREAD#,
       LOW_SEQUENCE#,
       HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

If an archive gap exists, Oracle returns the thread and sequence range that currently prevents Redo Apply from continuing.

For example:

THREAD#   LOW_SEQUENCE#   HIGH_SEQUENCE#
-------   -------------   --------------
1         102             102

This tells the DBA that sequence 102 must be obtained before apply can proceed.

Oracle specifically notes that V$ARCHIVE_GAP reports the gap currently blocking Redo Apply. After resolving that gap, the DBA should query the view again because another gap may then become visible.

---

11. Why Does V$ARCHIVE_GAP Show Only One Gap?

This is an important point that is often misunderstood.

Suppose the standby has several missing sequences:

102 missing
105 missing
108 missing

The view does not necessarily list all missing sequences at once. It identifies the gap currently preventing Redo Apply from progressing.

After resolving the first gap:

Resolve Gap 102
      ↓
Restart / Resume Apply
      ↓
Query V$ARCHIVE_GAP Again
      ↓
Next Blocking Gap
      ↓
Resolve It
      ↓
Repeat

Oracle's documentation explicitly recommends repeating the process until no gap is returned.

---

12. Monitor Apply Lag

A very important Data Guard metric is apply lag.

Apply lag measures how far the standby's applied data is behind the originating primary database.

Run:

SELECT NAME,
       VALUE,
       UNIT,
       TIME_COMPUTED,
       DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('apply lag',
               'transport lag',
               'apply finish time');

Oracle documents V$DATAGUARD_STATS as a source of Data Guard metrics including apply lag, transport lag and estimated apply finish time.

A healthy environment might show:

NAME                VALUE
------------------  ---------------------------
apply lag           +00 00:00:02
transport lag       +00 00:00:01
apply finish time   +00 00:00:00

The exact acceptable lag depends on the organization's recovery objectives and Data Guard configuration.

---

13. Apply Lag vs Transport Lag

These two metrics are frequently confused.

Metric	Meaning	Possible Problem Area
Transport Lag	Redo generated by the source has not yet reached the standby.	Network, transport configuration, primary/standby destination, RFS, storage.
Apply Lag	Redo has reached the standby but has not yet been applied.	MRP, I/O, CPU, storage, apply workload, gaps or recovery problems.

Oracle defines transport lag as the delay caused by redo not yet being transported to the target, while apply lag reflects the delay associated with propagation and application of redo at the target.

---

14. How to Interpret Transport Lag and Apply Lag

Case 1 — High Transport Lag

Transport Lag : 00:15:00
Apply Lag     : 00:01:00

This suggests that the standby is receiving redo too slowly or that redo is not reaching the standby promptly.

Investigate:

• Network connectivity
• Primary archive destination
• Data Guard transport configuration
• RFS activity
• Standby storage
• Network throughput and latency

Case 2 — Low Transport Lag but High Apply Lag

Transport Lag : 00:00:02
Apply Lag     : 00:20:00

This is a very different situation.

Redo is reaching the standby quickly, but Redo Apply is unable to keep up.

Investigate:

• MRP status
• Archive gaps
• Standby I/O performance
• CPU utilization
• Storage latency
• Large transaction workload
• Redo Apply performance
• Standby database configuration

---

15. Check Whether the Standby Is Receiving Redo

Use:

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#
FROM V$MANAGED_STANDBY
WHERE PROCESS LIKE 'RFS%';

If RFS is receiving redo, this provides evidence that the transport path is active.

However, one query should never be considered sufficient proof of end-to-end Data Guard health.

A proper check should correlate:

Primary Redo Generation
        ↓
Redo Transport
        ↓
RFS Reception
        ↓
Standby Redo Log
        ↓
MRP / Redo Apply
        ↓
Applied Redo
        ↓
Apply Lag

---

16. Check Archived Logs on the Standby

The V$ARCHIVED_LOG view is useful for checking which redo sequences are known to the standby.

SELECT THREAD#,
       SEQUENCE#,
       FIRST_TIME,
       NEXT_TIME,
       APPLIED,
       ARCHIVED,
       DELETED
FROM V$ARCHIVED_LOG
ORDER BY THREAD#, SEQUENCE#;

For a focused query:

SELECT THREAD#,
       SEQUENCE#,
       APPLIED,
       FIRST_TIME,
       NEXT_TIME
FROM V$ARCHIVED_LOG
WHERE THREAD# = 1
ORDER BY SEQUENCE# DESC;

This can help determine whether the required archive logs have reached the standby and whether they have been applied.

---

17. Check Standby Redo Logs

Because real-time apply depends on standby redo logs, verify their configuration.

Run:

SELECT GROUP#,
       THREAD#,
       SEQUENCE#,
       BYTES,
       STATUS
FROM V$STANDBY_LOG
ORDER BY THREAD#, GROUP#;

You should verify that the standby has an appropriate number of standby redo log groups for the Data Guard configuration and redo threads being used.

The standby redo log size should also be appropriate for the primary redo log configuration.

---

18. Check the Primary Online Redo Logs

On the primary database:

SELECT GROUP#,
       THREAD#,
       SEQUENCE#,
       BYTES,
       STATUS
FROM V$LOG
ORDER BY THREAD#, GROUP#;

Compare the primary redo configuration with the standby redo configuration.

A Data Guard environment should be designed so that the standby can continuously receive redo generated by the primary.

---

19. Check Data Guard Status Messages

The V$DATAGUARD_STATUS view is useful when an apply or transport problem is suspected.

SELECT TIMESTAMP,
       SEVERITY,
       ERROR_CODE,
       MESSAGE
FROM V$DATAGUARD_STATUS
ORDER BY TIMESTAMP DESC;

To focus on recent serious events:

SELECT TIMESTAMP,
       SEVERITY,
       ERROR_CODE,
       MESSAGE
FROM V$DATAGUARD_STATUS
WHERE SEVERITY IN ('Error','Fatal')
ORDER BY TIMESTAMP DESC;

Oracle's current monitoring guidance also recommends checking Data Guard status information for serious errors when assessing standby health.

---

20. Check Standby Datafile Problems

MRP can also be affected by datafile problems.

Check the datafile headers:

SELECT FILE#,
       STATUS,
       ERROR,
       RECOVER
FROM V$DATAFILE_HEADER
WHERE STATUS = 'OFFLINE'
   OR ERROR IS NOT NULL;

If files are offline or have recovery/I/O errors, Redo Apply may not be able to proceed normally.

Oracle's current Data Guard monitoring recommendations include checking V$DATAFILE_HEADER for offline or errored datafiles when investigating standby health.

---

21. Basic MRP Troubleshooting Workflow

When someone reports:

"Standby database is not applying redo."

Do not immediately restart MRP repeatedly.

Use a structured troubleshooting process.

Step 1
Check DATABASE_ROLE
        ↓
Step 2
Check MRP status
        ↓
Step 3
Check RFS status
        ↓
Step 4
Check Apply Lag
        ↓
Step 5
Check Transport Lag
        ↓
Step 6
Check V$ARCHIVE_GAP
        ↓
Step 7
Check V$ARCHIVED_LOG
        ↓
Step 8
Check V$STANDBY_LOG
        ↓
Step 9
Check V$DATAGUARD_STATUS
        ↓
Step 10
Check storage / datafile errors
        ↓
Identify the actual failure point

---

22. Example: MRP Is Not Running

Suppose the DBA executes:

SELECT PROCESS,
       STATUS
FROM V$MANAGED_STANDBY;

and MRP is not present.

The next step should not simply be:

START MRP

Instead, first verify:

1. Database role.
2. Database open/mounted state.
3. Data Guard status messages.
4. Archive gap.
5. Standby redo log configuration.
6. Recent alert log messages.
7. Whether another recovery operation is already active.

Then start Redo Apply using the appropriate command for the Oracle Database release and configuration.

---

23. Example: MRP Is Running but Apply Lag Is Increasing

Consider:

MRP Status      : APPLYING_LOG
Transport Lag   : 00:00:02
Apply Lag       : 00:30:00

This indicates that redo is reaching the standby quickly, but the standby is taking much longer to apply it.

Possible causes include:

• Heavy primary workload.
• Large transactions.
• Standby storage latency.
• CPU pressure.
• Insufficient I/O throughput.
• Recovery/apply bottlenecks.
• Temporary system resource contention.
• Configuration or database-specific apply limitations.

In this situation, restarting MRP repeatedly is usually not the correct first response. The DBA should determine why the apply rate cannot keep up with the incoming redo rate.

---

24. Example: MRP Is Waiting for a Gap

Suppose:

MRP0    WAIT_FOR_GAP

Run:

SELECT THREAD#,
       LOW_SEQUENCE#,
       HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

If the result is:

THREAD#  LOW_SEQUENCE#  HIGH_SEQUENCE#
-------  -------------  --------------
1        12540           12540

then sequence 12540 is currently blocking apply.

The DBA must locate the required archive log on the primary or another suitable source, transfer/register it as appropriate for the environment, and then allow Redo Apply to continue.

Detailed archive-gap recovery procedures will be covered in Part 3.

---

25. Apply Finish Time

Another useful metric is:

APPLY FINISH TIME

It estimates how long it may take the standby to apply the redo that has been received but not yet applied.

For example:

NAME
------------------
apply finish time

VALUE
------------------
+00 00:05:30

This means the standby estimates approximately five minutes and thirty seconds to apply the currently outstanding redo, subject to the assumptions behind the metric.

Oracle documents this as an estimate of the time required to apply received but unapplied redo. If an archive gap exists, the calculation is affected by that gap.

---

26. Important Difference: Received Redo vs Applied Redo

A common DBA mistake is to assume:

"The standby received the archive log, therefore the standby is synchronized."

This is not necessarily true.

There are several stages:

Redo Generated
      ↓
Redo Transported
      ↓
Redo Received
      ↓
Redo Available
      ↓
Redo Applied
      ↓
Changes Visible on Standby

A redo log can exist on the standby but still be unapplied.

Therefore, when checking synchronization, distinguish between:

• Received redo
• Available redo
• Applied redo

---

27. Practical DBA Health Check

The following compact health-check sequence can be useful when investigating a physical standby:

Database Role

SELECT DATABASE_ROLE,
       OPEN_MODE,
       DB_UNIQUE_NAME
FROM V$DATABASE;

MRP / RFS

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#
FROM V$MANAGED_STANDBY;

Lag

SELECT NAME,
       VALUE,
       TIME_COMPUTED,
       DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('apply lag',
               'transport lag',
               'apply finish time');

Archive Gap

SELECT THREAD#,
       LOW_SEQUENCE#,
       HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

Standby Redo Logs

SELECT GROUP#,
       THREAD#,
       SEQUENCE#,
       BYTES,
       STATUS
FROM V$STANDBY_LOG
ORDER BY THREAD#, GROUP#;

Data Guard Errors

SELECT TIMESTAMP,
       SEVERITY,
       ERROR_CODE,
       MESSAGE
FROM V$DATAGUARD_STATUS
WHERE SEVERITY IN ('Error','Fatal')
ORDER BY TIMESTAMP DESC;

---

28. Do Not Restart MRP Without Understanding the Cause

Restarting MRP can sometimes clear a transient problem, but repeatedly stopping and starting recovery without identifying the underlying issue is not a proper Data Guard troubleshooting strategy.

For example, if the actual problem is:

• Missing archive log
• Archive gap
• Corrupt redo
• Datafile I/O error
• Insufficient filesystem space
• Standby redo log problem
• Transport failure
• Network failure

then simply restarting MRP will not solve the root cause.

Best DBA Practice: Identify whether the failure is in transport, reception, redo availability, or apply before taking corrective action.

---

Key Takeaway

A healthy physical standby is not determined merely by whether MRP exists. A professional Data Guard health check must establish that redo is generated, transported, received, available and successfully applied, while transport lag and apply lag remain within the organization's recovery objectives.

---

MRP — Managed Recovery Process in Oracle Data Guard

Advanced Troubleshooting, Archive Gaps, Recovery Errors and DBA Best Practices

In this final section, we will focus on real-world Oracle Data Guard troubleshooting. The objective is not simply to restart MRP, but to identify exactly why Redo Apply cannot continue and then apply the appropriate corrective action.

---

1. The Most Important Data Guard Troubleshooting Principle

When a physical standby database is behind the primary, always determine where the delay is occurring.

The complete flow is:

Primary Database
       |
       | Redo Generation
       v
Redo Transport
       |
       v
Network
       |
       v
RFS
       |
       v
Standby Redo Log
       |
       v
Redo Apply / MRP
       |
       v
Standby Datafiles

A problem at any point in this chain can cause the standby to fall behind.

Therefore, the first question should not be:

"How do I restart MRP?"

The better question is:

"At which stage is the Data Guard synchronization process failing?"

---

2. First Check — Database Role and Open Mode

Always confirm that you are connected to the expected standby database.

SELECT DB_UNIQUE_NAME,
       DATABASE_ROLE,
       OPEN_MODE,
       PROTECTION_MODE,
       PROTECTION_LEVEL
FROM V$DATABASE;

For a physical standby, you should normally see:

DATABASE_ROLE
----------------
PHYSICAL STANDBY

The open mode depends on the configuration. A standby may be mounted, read-only, or read-only with apply in an Active Data Guard environment.

Oracle documents that a physical standby can run Redo Apply while open read-only when the appropriate Active Data Guard capability is available.

---

3. Check the Current Redo Apply Process

On older Oracle Database releases, you may use:

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#,
       BLOCK#,
       BLOCKS
FROM V$MANAGED_STANDBY
ORDER BY PROCESS;

For newer Oracle Database releases, prefer:

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#
FROM V$DATAGUARD_PROCESS
ORDER BY PROCESS;

Oracle documents V$MANAGED_STANDBY as deprecated beginning with Oracle Database 12c Release 2 and recommends V$DATAGUARD_PROCESS instead.

---

4. Scenario — MRP Is Not Running

Suppose the query returns no MRP process.

SELECT PROCESS,
       STATUS
FROM V$MANAGED_STANDBY
WHERE PROCESS LIKE 'MRP%';

If no rows are returned, Redo Apply may not currently be running.

Before starting it, check:

• Database role.
• Database open mode.
• Data Guard status.
• Alert log.
• Archive gaps.
• Standby redo logs.
• Available storage space.
• Any previous recovery error.

If the standby is correctly configured and there is no blocking error, Redo Apply can normally be started with:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Oracle documents this command for starting Redo Apply in the background.

---

5. Scenario — MRP Is Applying Redo but the Standby Is Still Behind

Consider:

MRP Status      : APPLYING_LOG
Transport Lag   : 00:00:03
Apply Lag       : 00:25:00

This is an important diagnostic situation.

Redo is reaching the standby, but Redo Apply is not keeping pace with the incoming redo rate.

Possible causes include:

• Very high redo generation on the primary.
• Large transactions.
• Slow standby storage.
• High I/O latency.
• CPU contention.
• Insufficient standby resources.
• Recovery bottlenecks.
• Temporary resource contention.

In this situation, repeatedly restarting MRP is generally not the correct solution. The DBA should investigate the apply rate and the resources available to the standby.

---

6. Scenario — MRP Shows WAIT_FOR_LOG

If MRP shows:

MRP0    WAIT_FOR_LOG

do not immediately assume that Redo Apply has failed.

If the standby has applied everything currently available and is waiting for additional redo, this can be completely normal.

Check:

SELECT NAME,
       VALUE,
       TIME_COMPUTED,
       DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag','apply lag');

If both values are effectively zero and the standby is current, MRP waiting for more redo is expected.

---

7. Scenario — MRP Shows WAIT_FOR_GAP

If you see:

MRP0    WAIT_FOR_GAP

check:

SELECT THREAD#,
       LOW_SEQUENCE#,
       HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

Example:

THREAD#   LOW_SEQUENCE#   HIGH_SEQUENCE#
-------   -------------   --------------
1         12540           12542

This means that sequences 12540 through 12542 are currently required before Redo Apply can continue.

Oracle specifically documents that V$ARCHIVE_GAP reports the gap currently blocking Redo Apply.

---

8. Locate Missing Archive Logs on the Primary

Once the missing sequence range has been identified, connect to the primary database and locate the required archive logs.

For example:

SELECT THREAD#,
       SEQUENCE#,
       NAME
FROM V$ARCHIVED_LOG
WHERE THREAD# = 1
AND SEQUENCE# BETWEEN 12540 AND 12542
ORDER BY SEQUENCE#;

A result may look like:

THREAD#  SEQUENCE#  NAME
-------  ---------  -----------------------------------
1        12540      /u01/arch/1_12540.arc
1        12541      /u01/arch/1_12541.arc
1        12542      /u01/arch/1_12542.arc

Oracle documentation uses the same general approach: identify the gap on the standby and locate the corresponding archived redo files on the primary.

---

9. Copy the Missing Archive Logs to the Standby

After locating the files, copy them to the standby server using the organization's approved file-transfer method.

For example, a Linux environment might use:

scp /u01/arch/1_12540.arc oracle@standby:/u01/arch/
scp /u01/arch/1_12541.arc oracle@standby:/u01/arch/
scp /u01/arch/1_12542.arc oracle@standby:/u01/arch/

The actual directories will obviously depend on your Data Guard configuration.

Important: Never blindly copy files into an arbitrary directory and assume Oracle will automatically use them. The archive logs must be available to the standby according to the configured archive destinations and, where required, registered with the standby database.

---

10. Register a Missing Physical Standby Archive Log

If a manually copied archive log is not automatically recognized, it can be registered on the physical standby with:

ALTER DATABASE REGISTER PHYSICAL LOGFILE
'/u01/arch/1_12540.arc';

Repeat for the other missing logs when required.

For example:

ALTER DATABASE REGISTER PHYSICAL LOGFILE
'/u01/arch/1_12541.arc';

ALTER DATABASE REGISTER PHYSICAL LOGFILE
'/u01/arch/1_12542.arc';

Oracle documents this method for registering missing archived redo logs on a physical standby.

---

11. Check the Archive Gap Again

After resolving the first gap, run:

SELECT THREAD#,
       LOW_SEQUENCE#,
       HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

If no rows are returned, there is no currently reported archive gap.

If another gap appears, resolve it and repeat the query.

This is important because Oracle notes that V$ARCHIVE_GAP reports the gap currently blocking Redo Apply rather than necessarily listing every future gap.

Find Gap
   ↓
Retrieve Missing Logs
   ↓
Copy Logs
   ↓
Register Logs
   ↓
Check V$ARCHIVE_GAP Again
   ↓
Another Gap?
   ├── YES → Resolve It
   └── NO  → Continue Redo Apply

---

12. Resume Redo Apply After Resolving the Gap

If Redo Apply was stopped during troubleshooting, restart it:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Then monitor the recovery process and lag.

SELECT NAME,
       VALUE,
       TIME_COMPUTED
FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag','apply lag','apply finish time');

Oracle documents the same background Redo Apply command for physical standby databases.

---

13. Scenario — Archive Log Does Not Exist on the Primary

A difficult situation occurs when the required archive log has already been deleted from the primary and is no longer available in the configured backup/archive sources.

First determine exactly which sequence is missing.

SELECT THREAD#,
       LOW_SEQUENCE#,
       HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

Then determine whether the missing redo can be recovered from:

• RMAN backups.
• Another archive destination.
• Another standby database.
• Archive storage.
• Backup/recovery infrastructure.

Do not immediately recreate the standby. First determine whether the missing redo can be restored from an available backup source.

---

14. Scenario — Archive Gap Cannot Be Resolved

If required redo has been permanently lost and cannot be obtained from any available source, the standby may not be able to continue normal Redo Apply from its current state.

The correct recovery strategy depends on:

• How much redo is missing.
• Whether backups are available.
• Whether Flashback Database is enabled.
• Whether the standby has diverged from the primary.
• The organization's Recovery Point Objective (RPO).
• The organization's Recovery Time Objective (RTO).

Depending on the circumstances, the standby may need to be refreshed or recreated from the primary or an appropriate backup.

Do not use a destructive recovery command simply to make MRP start again.

---

15. Scenario — MRP Stops With an Error

If MRP stops unexpectedly, check the Data Guard status messages:

SELECT TIMESTAMP,
       SEVERITY,
       ERROR_CODE,
       MESSAGE
FROM V$DATAGUARD_STATUS
WHERE SEVERITY IN ('Error','Fatal')
ORDER BY TIMESTAMP DESC;

Also check the Oracle alert log.

Look for messages involving:

• Media recovery.
• Archive logs.
• Datafile errors.
• I/O failures.
• Storage problems.
• Redo corruption.
• Standby redo logs.
• Database incarnation changes.
• Data Guard transport errors.

Oracle's Data Guard monitoring guidance recommends checking V$DATAGUARD_STATUS for serious Error and Fatal events.

---

16. Check Datafile Errors

A physical standby cannot apply redo correctly if required datafiles have I/O or recovery problems.

Run:

SELECT FILE#,
       STATUS,
       ERROR,
       RECOVER
FROM V$DATAFILE_HEADER
WHERE STATUS = 'OFFLINE'
   OR ERROR IS NOT NULL;

If rows are returned, investigate those files before assuming that MRP itself is the root cause.

Oracle's Data Guard monitoring documentation specifically recommends this check when assessing standby health.

---

17. Check Standby Storage

A filesystem that becomes full can cause apparently unrelated Data Guard failures.

On Linux, check:

df -h
df -i

Also check the filesystem containing:

• Archive logs.
• Standby redo logs.
• Online redo logs.
• Datafiles.
• Fast Recovery Area.
• Oracle diagnostic files.

If the Fast Recovery Area is full, archive operations and other database activities can be affected.

---

18. Check Fast Recovery Area Usage

Use:

SELECT NAME,
       SPACE_LIMIT,
       SPACE_USED,
       SPACE_RECLAIMABLE,
       NUMBER_OF_FILES
FROM V$RECOVERY_FILE_DEST;

Compare the amount of space used with the configured recovery area limit.

A full recovery area should be treated as a storage-management problem, not simply as an MRP problem.

---

19. Check Archive Destination Status

On the primary, inspect configured archive destinations:

SELECT DEST_ID,
       STATUS,
       TARGET,
       DESTINATION,
       ERROR
FROM V$ARCHIVE_DEST
WHERE STATUS <> 'INACTIVE'
ORDER BY DEST_ID;

Look carefully at the ERROR column.

Errors can point toward:

• Network problems.
• Authentication issues.
• Invalid destination.
• Filesystem problems.
• Standby availability problems.
• Configuration errors.

---

20. Check Archive Destination Status on the Standby

For a physical standby, you can also examine Data Guard destination information:

SELECT DEST_ID,
       STATUS,
       TYPE,
       DATABASE_MODE,
       RECOVERY_MODE,
       GAP_STATUS
FROM V$ARCHIVE_DEST_STATUS
WHERE TYPE = 'PHYSICAL';

Oracle's Data Guard monitoring documentation uses V$ARCHIVE_DEST_STATUS to detect synchronization and gap conditions.

---

21. Scenario — Transport Lag Is High

Suppose:

Transport Lag : 00:20:00
Apply Lag     : 00:20:00

This points toward a transport-side problem.

Investigate:

• Primary archive destination.
• Network connectivity.
• Network latency.
• Network throughput.
• RFS status.
• Standby listener/service availability.
• Standby storage.
• Data Guard transport configuration.

The key question is:

Is the redo actually reaching the standby?

---

22. Scenario — Transport Lag Is Low but Apply Lag Is High

Now consider:

Transport Lag : 00:00:02
Apply Lag     : 00:30:00

This is a strong indication that redo is reaching the standby but is not being applied quickly enough.

Focus on:

• MRP status.
• Apply performance.
• CPU usage.
• I/O latency.
• Storage throughput.
• Large transactions.
• Standby workload.
• Database configuration.

Oracle defines apply lag as the delay associated with propagating and applying redo at the target database.

---

23. Real-Time Apply Troubleshooting

Real-time apply requires standby redo logs.

Check:

SELECT GROUP#,
       THREAD#,
       SEQUENCE#,
       BYTES,
       STATUS
FROM V$STANDBY_LOG
ORDER BY THREAD#, GROUP#;

Also verify that the standby is in ARCHIVELOG mode:

SELECT LOG_MODE
FROM V$DATABASE;

Oracle documents that starting Redo Apply automatically enables real-time apply when the physical standby has standby redo logs and is running in ARCHIVELOG mode.

---

24. Verify Standby Redo Log Capacity

Standby redo logs should be appropriately sized for the primary redo configuration.

Compare:

SELECT GROUP#,
       THREAD#,
       BYTES,
       STATUS
FROM V$LOG
ORDER BY THREAD#, GROUP#;

on the primary with:

SELECT GROUP#,
       THREAD#,
       BYTES,
       STATUS
FROM V$STANDBY_LOG
ORDER BY THREAD#, GROUP#;

A mismatch in standby redo log configuration can prevent the Data Guard environment from operating as intended.

---

25. Scenario — ORA-01112 When Starting Recovery

An Oracle DBA may encounter:

ORA-01112: media recovery not started

In a Data Guard environment, Oracle documents that this can occur when the physical standby has not yet received redo and Redo Apply cannot determine the starting sequence number.

The solution can involve receiving an archived redo log from the primary and registering it on the standby, or allowing redo transport to begin before starting Redo Apply.

Therefore, do not treat every ORA-01112 occurrence as an MRP failure.

---

26. Scenario — Primary Database Was Opened With RESETLOGS

A primary database can enter a new redo branch after an OPEN RESETLOGS operation.

For example:

ALTER DATABASE OPEN RESETLOGS;

A physical standby can normally follow the new branch automatically when the required conditions are satisfied.

However, if the standby has already applied redo beyond the new resetlogs SCN, the standby may have diverged from the new primary branch.

Flashback Database can provide a recovery path in some configurations. If Flashback Database is not available and the standby has diverged, the physical standby may need to be recreated. Oracle documents these RESETLOGS/redo-branch scenarios in its physical standby administration guidance.

---

27. Check Database Incarnation

When investigating a resetlogs or incarnation-related issue, compare the current database incarnation:

SELECT RESETLOGS_ID,
       RESETLOGS_CHANGE#,
       STATUS,
       RESETLOGS_TIME
FROM V$DATABASE_INCARNATION
ORDER BY RESETLOGS_TIME DESC;

The current incarnation should be understood when troubleshooting redo-branch problems.

---

28. Scenario — Standby Has Diverged From Primary

If the standby has applied redo from a branch that is no longer the current primary branch, normal Redo Apply may not be sufficient to resynchronize it.

The available recovery options depend on the exact point of divergence and whether Flashback Database is enabled.

If Flashback Database is available, the standby may be flashed back to an appropriate point and then Redo Apply restarted.

If the standby has diverged and cannot be repaired using Flashback Database, rebuilding the physical standby may be required. Oracle explicitly documents this distinction.

---

29. Do Not Delete Archive Logs Manually Without a Recovery Strategy

One of the most dangerous mistakes in a Data Guard environment is deleting archived redo logs simply because they appear old.

Before deleting archive logs, verify:

• Which standby databases require them.
• Whether the logs have been transported.
• Whether the logs have been applied.
• Whether backups exist.
• Whether RMAN deletion policies are configured appropriately.

A deleted archive log can create a Data Guard gap and may require recovery from backup or another archive destination.

---

30. A Complete MRP Troubleshooting Checklist

Step 1 — Confirm Role

SELECT DATABASE_ROLE,
       OPEN_MODE,
       DB_UNIQUE_NAME
FROM V$DATABASE;

Step 2 — Check Redo Apply

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#
FROM V$DATAGUARD_PROCESS;

Step 3 — Check Transport and Apply Lag

SELECT NAME,
       VALUE,
       TIME_COMPUTED,
       DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag',
               'apply lag',
               'apply finish time');

Step 4 — Check Archive Gap

SELECT THREAD#,
       LOW_SEQUENCE#,
       HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

Step 5 — Check Data Guard Errors

SELECT TIMESTAMP,
       SEVERITY,
       ERROR_CODE,
       MESSAGE
FROM V$DATAGUARD_STATUS
WHERE SEVERITY IN ('Error','Fatal')
ORDER BY TIMESTAMP DESC;

Step 6 — Check Datafile Errors

SELECT FILE#,
       STATUS,
       ERROR,
       RECOVER
FROM V$DATAFILE_HEADER
WHERE STATUS = 'OFFLINE'
   OR ERROR IS NOT NULL;

Step 7 — Check Standby Redo Logs

SELECT GROUP#,
       THREAD#,
       SEQUENCE#,
       BYTES,
       STATUS
FROM V$STANDBY_LOG
ORDER BY THREAD#, GROUP#;

Step 8 — Check Archive Destination

SELECT DEST_ID,
       STATUS,
       TARGET,
       DESTINATION,
       ERROR
FROM V$ARCHIVE_DEST
WHERE STATUS <> 'INACTIVE';

Step 9 — Check Filesystem

df -h
df -i

Step 10 — Check Alert Log

Review the Oracle alert log and Data Guard-related trace information for the exact error that caused Redo Apply to stop or fall behind.

---

31. Recommended Troubleshooting Decision Tree

Standby Is Behind
       |
       v
Is MRP Running?
       |
   +---+---+
   |       |
  NO      YES
   |       |
   v       v
Check     Check Lag
Errors       |
   |      +--+--+
   |      |     |
   |   Transport Apply
   |      Lag    Lag
   |       |      |
   |       v      v
   |    Transport Apply
   |    Problem  Problem
   |       |      |
   +-------+------+
           |
           v
      Check Archive Gap
           |
       +---+---+
       |       |
      YES      NO
       |       |
       v       v
Retrieve     Check
Missing      Performance
Redo         / Errors
       |       |
       +---+---+
           |
           v
       Resume Apply
           |
           v
      Verify Lag Falls
           |
           v
       Standby Healthy

---

32. Data Guard Broker — An Important Alternative

If your environment uses Oracle Data Guard Broker, many administrative and monitoring operations can be performed through the Broker rather than managing every database parameter and process manually.

The primary Broker command-line utility is:

dgmgrl

For example:

DGMGRL> SHOW CONFIGURATION;

You can also inspect a specific database:

DGMGRL> SHOW DATABASE VERBOSE 'STANDBY_DB';

The exact Broker commands and available properties depend on the Oracle Database version and Data Guard configuration.

---

33. Why Data Guard Broker Is Useful

Data Guard Broker can simplify:

• Configuration management.
• Standby monitoring.
• Role transitions.
• Transport configuration.
• Apply-state management.
• Health reporting.
• Fast-start failover environments.

However, SQL views and the alert log remain extremely valuable for detailed troubleshooting.

---

34. MRP Best Practices for Oracle DBAs

1. Monitor transport lag and apply lag regularly.
2. Use standby redo logs when real-time apply is required.
3. Do not restart MRP repeatedly without identifying the underlying cause.
4. Investigate archive gaps immediately.
5. Protect required archived redo logs from premature deletion.
6. Monitor standby storage and recovery area usage.
7. Monitor Data Guard errors using the appropriate dynamic performance views and alert logs.
8. Use current monitoring views on newer Oracle releases; for example, prefer V$DATAGUARD_PROCESS over the deprecated V$MANAGED_STANDBY.
9. Document your recovery procedures before a disaster occurs.
10. Test switchover and failover procedures regularly according to your organization's operational requirements.

---

35. Frequently Asked Questions

Q1. What does MRP stand for?

MRP stands for Managed Recovery Process. It is associated with Redo Apply on an Oracle physical standby database.

Q2. What is the difference between RFS and MRP?

RFS receives redo transported from the primary, while MRP/Redo Apply applies redo to the physical standby.

Q3. Is WAIT_FOR_LOG an error?

Not necessarily. If the standby has applied all available redo and is waiting for the next redo, this can be normal.

Q4. What does WAIT_FOR_GAP mean?

It generally means Redo Apply cannot continue because required redo is missing. Check V$ARCHIVE_GAP.

Q5. How do I start MRP?

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

This starts Redo Apply in the background.

Q6. How do I stop MRP?

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Q7. How do I check apply lag?

SELECT NAME,
       VALUE,
       TIME_COMPUTED,
       DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME = 'apply lag';

Q8. How do I find an archive gap?

SELECT THREAD#,
       LOW_SEQUENCE#,
       HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

Q9. Does V$ARCHIVE_GAP show every missing archive log?

Not necessarily. It reports the gap currently blocking Redo Apply. After resolving it, query the view again to identify another blocking gap if one exists.

Q10. Is V$MANAGED_STANDBY still recommended on new Oracle versions?

Oracle documents V$MANAGED_STANDBY as deprecated from Oracle Database 12c Release 2 and recommends V$DATAGUARD_PROCESS instead.

---

36. Final Oracle Data Guard MRP Health Check

A physical standby should be considered healthy only after checking more than the MRP process itself.

Check	Healthy Indication
Database Role	PHYSICAL STANDBY
Redo Apply	Running when apply is required
Transport Lag	Within the organization's target
Apply Lag	Within the organization's target
Archive Gap	No blocking gap
Datafile Errors	None
Data Guard Errors	No unresolved Error/Fatal events
Standby Redo Logs	Properly configured
Storage	Adequate free space and healthy I/O

Oracle's own Data Guard monitoring guidance uses checks for apply lag, transport lag, MRP state, archive gaps, Data Guard errors and datafile problems as part of standby monitoring.

---

37. Final Summary

The Managed Recovery Process (MRP) is an important component of Oracle Data Guard physical standby operations. It is associated with applying redo received from the primary database so that the standby remains synchronized.

However, a Data Guard environment is much more than one process.

Primary
   ↓
Redo Generation
   ↓
Redo Transport
   ↓
Network
   ↓
RFS
   ↓
Standby Redo Logs
   ↓
MRP / Redo Apply
   ↓
Standby Datafiles

When a standby falls behind, the DBA should identify the exact stage at which the problem occurs.

If redo is not reaching the standby, investigate transport.

If redo is reaching the standby but is not being applied, investigate Redo Apply/MRP.

If MRP is waiting for a gap, investigate missing archived redo logs.

If MRP reports an error, investigate the exact error message, alert log, Data Guard status and underlying database/storage condition.

If the standby has permanently lost required redo or has diverged from the primary, a more extensive recovery or standby rebuild may be necessary.

Final Oracle DBA Takeaway

Do not troubleshoot MRP in isolation. Always follow the complete Data Guard path: redo generation → transport → reception → redo availability → Redo Apply → standby synchronization. This approach allows an Oracle DBA to identify the actual root cause instead of repeatedly restarting recovery without understanding the problem.

---

Oracle Data Guard Reference Queries

For quick reference, the most useful queries from this three-part guide are collected below.

Database Role

SELECT DB_UNIQUE_NAME,
       DATABASE_ROLE,
       OPEN_MODE
FROM V$DATABASE;

Redo Apply — Current Releases

SELECT PROCESS,
       STATUS,
       THREAD#,
       SEQUENCE#
FROM V$DATAGUARD_PROCESS;

Transport / Apply Lag

SELECT NAME,
       VALUE,
       TIME_COMPUTED,
       DATUM_TIME
FROM V$DATAGUARD_STATS
WHERE NAME IN ('transport lag',
               'apply lag',
               'apply finish time');

Archive Gap

SELECT THREAD#,
       LOW_SEQUENCE#,
       HIGH_SEQUENCE#
FROM V$ARCHIVE_GAP;

Data Guard Errors

SELECT TIMESTAMP,
       SEVERITY,
       ERROR_CODE,
       MESSAGE
FROM V$DATAGUARD_STATUS
WHERE SEVERITY IN ('Error','Fatal')
ORDER BY TIMESTAMP DESC;

Standby Redo Logs

SELECT GROUP#,
       THREAD#,
       SEQUENCE#,
       BYTES,
       STATUS
FROM V$STANDBY_LOG
ORDER BY THREAD#, GROUP#;

---

Conclusion

Oracle Data Guard provides a powerful mechanism for maintaining a standby database for high availability and disaster recovery. Understanding MRP, RFS, standby redo logs, redo transport, archive gaps and apply lag is essential for any Oracle DBA responsible for a Data Guard environment.

The most effective troubleshooting approach is always systematic: identify the symptom, verify the Data Guard state, determine where redo is stopping, resolve the underlying cause, restart or resume Redo Apply when appropriate, and finally verify that the standby is synchronized again.

Remember: A running MRP process alone does not guarantee a healthy standby. Always verify transport, apply, gaps, errors, storage and synchronization status.

---

Technical References: Oracle Database Data Guard Concepts and Administration documentation, Oracle Database Reference documentation, Oracle Data Guard Apply Services documentation, Oracle Data Guard Redo Transport Services documentation, and Oracle Data Guard monitoring documentation.