ORA-16766 Error in Oracle Data Guard: Causes and Fix (19c Guide)

ORA-16766 Error in Oracle Data Guard: Causes and Fix (Oracle 19c Guide)

Redo Apply Service Not Running, How to Diagnose and Restart MRP in Under 5 Minutes

📅 4 May 2026

👤 Chetan Yadav, Senior Oracle & Cloud DBA

⏱️ 10-12 min read

⏱️ Estimated Reading Time: 10-12 minutes

ORA-16766, MRP Not Running, DGMGRL Diagnosis, MRP Restart, Standby Apply Fix, Oracle 19c

ORA-16766

Full Error: ORA-16766: Redo Apply is stopped

This error appears in DGMGRL SHOW CONFIGURATION output against the standby database. It means the Managed Recovery Process (MRP) on the standby has stopped and redo is no longer being applied. The standby is diverging from the primary with every passing second.

It was 3:22 AM. The monitoring alert fired: "Data Guard configuration warning — ORA-16766 on standby." Apply lag had jumped from zero to 47 minutes in under an hour. The standby database was alive, connected, receiving redo, but not applying any of it.

ORA-16766 is one of the most common Oracle Data Guard errors in production Oracle 19c environments. It always means the same thing: the MRP process on the standby has stopped. But the reasons it stops, and the correct fix for each reason, are completely different.

This guide covers every root cause of ORA-16766 in Oracle 19c, the exact DGMGRL and SQL commands to diagnose it, and the step-by-step fix commands for each scenario. Most ORA-16766 errors are resolved in under 5 minutes once you know which cause you are dealing with.

How to Fix Data Guard Lag in Oracle 19c: Step-by-Step Troubleshooting Guide

5 Proven Fixes for Transport Lag and Apply Lag with Exact SQL Commands

 March 2026

 Chetan Yadav, Senior Oracle & Cloud DBA

⏱️ 12 - 14 min read

⏱️ Estimated Reading Time: 12 - 14 minutes

Missing SRLs, Parallel Apply, Network Compression, RMAN Conflict, Protection Mode Mismatch

⚙️ Environment Referenced

Oracle Database: 19.18.0.0.0 Enterprise Edition  •  Standby Type: Physical Standby (Active Data Guard)  •  Protection Mode: Maximum Availability (SYNC/AFFIRM)
Primary: 2-Node RAC, 4.8 TB OLTP  •  Network: Dedicated 1 GbE WAN, RTT 1.8 ms  •  Peak Load: 2,800 TPS

Data Guard lag is one of the most stressful production alerts a DBA receives. The standby is falling behind the primary. Every second of lag is a second of potential data loss if the primary fails right now. The pressure to fix it quickly is real.

The problem is that "Data Guard lag" is not one problem. It is five different problems that all show the same symptom. Applying the wrong fix wastes time and can make things worse. This guide gives you the exact decision path, the exact diagnostic queries, and the exact fix commands for each root cause, in the order you should check them.

Follow the steps in order. Each step either identifies your problem and gives you the fix, or clears that cause and moves you to the next. Most Data Guard lag issues are resolved within Steps 1 to 3.

 Table of Contents

1. Before You Start: Run These 4 Queries First
2. Step 1: Check for Transport Lag vs Apply Lag
3. Step 2: Fix Missing Standby Redo Logs (Most Common Root Cause)
4. Step 3: Enable Parallel Apply to Fix MRP Bottleneck
5. Step 4: Fix Network Latency and Bandwidth
6. Step 5: Resolve RMAN vs MRP I/O Conflict
7. Step 6: Fix Protection Mode Mismatch
8. Fix for Active Data Guard (ADG) Apply Lag
9. After the Fix: Verify and Monitor
10. Prevent Lag From Returning: Configuration Checklist
11. FAQ
12. Related Reading