Common symptoms

  • Monitoring shows growing transport lag or apply lag in V$DATAGUARD_STATS
  • SHOW CONFIGURATION in DGMGRL shows Warning or Error status
  • The standby doesn't have the most recent archive logs from the primary
  • The MRP process doesn't appear in V$MANAGED_STANDBY or shows WAIT_FOR_LOG status for too long
  • Alerts in the standby's alert.log about archive log sequence gaps
  • The standby is in MOUNT mode instead of OPEN READ ONLY

Business risks

  • If the primary fails with the standby lagging, the data difference between them is lost
  • A standby with lag cannot be activated as new primary with zero RPO
  • An unrecoverable archive gap may require a complete rebuild of the standby
  • The standby may not be available for reads if there are recovery gaps

Detailed technical checklist

  • 1. Verify the status of archive log destinations on the primary If the destination to the standby shows ERROR or INACTIVE, the primary is not sending redo.
  • 2. Verify files received but not applied on the standby
  • 3. Identify sequence gaps If sequences are missing in the range between the last applied and the current primary, there is a gap.
  • 4. Start the MRP process if it is stopped
  • 5. Stop and restart MRP if it is hung
  • 6. Verify space in the FRA (Fast Recovery Area) If the FRA is full, the standby cannot receive new archive logs.
  • 7. Verify network connectivity between primary and standby A network problem or listener service issue can prevent redo from arriving.
  • 8. Request automatic gap resolution (FAL) Data Guard can automatically request missing files from the primary.
  • 9. Review the standby's alert.log for specific errors
  • 10. Verify configured protection mode Maximum Availability or Maximum Protection mode can block the primary if the standby cannot receive redo.
SQL · ON THE STANDBY 
-- Apply lag on the standby
SELECT name, value, unit
FROM v$dataguard_stats
WHERE name = 'apply lag';

When to escalate to a specialist DBA

  • There is an archive log gap that the primary no longer has available (files purged from FRA)
  • The standby requires a complete rebuild from the primary (RMAN DUPLICATE)
  • The primary is in Maximum Protection mode and has been blocked because it cannot write to the standby
  • The lag exceeds the approved RPO and a planned failover is approaching
  • The alert.log shows block corruption errors in archive logs

Frequently asked questions

What is the MRP process in Data Guard?

MRP (Managed Recovery Process) is the process that applies redo log files received from the primary on the standby. If MRP is not running, the standby receives the files but does not apply them, accumulating apply lag. It can be verified with SELECT process, status FROM V$MANAGED_STANDBY WHERE process LIKE 'MRP%'; and started with ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

What is an archive gap in Data Guard?

A gap occurs when the standby is missing one or more archive logs from the sequence required for continuous recovery. It can occur due to network problems, insufficient FRA disk space, or if the standby was disconnected for a period. Data Guard has an automatic gap resolution process (FAL - Fetch Archive Log) that tries to recover them from the primary, but if the files have already been purged from the primary's FRA, the gap may require a standby rebuild.

What is the difference between transport lag and apply lag?

Transport lag is the time it takes for redo generated on the primary to arrive (be transported) to the standby. Apply lag is the additional time it takes to be applied (replayed) on the standby once received. Both should be close to zero in a healthy Data Guard. High transport lag indicates a network or archive configuration problem; high apply lag indicates that MRP is slow, stopped, or the standby has I/O pressure.

When should I use Synchronous (SYNC) vs Asynchronous (ASYNC) mode?

SYNC (Maximum Availability or Maximum Protection) ensures that each commit on the primary only completes when the redo has reached the standby. This gives zero RPO but may affect primary performance if the network is slow. ASYNC (Maximum Performance) allows the primary to commit without waiting for the standby, with better performance but with the possibility of data loss proportional to the lag. The choice depends on the RPO the business can tolerate.

Related resources