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.

Why Data Guard Lag Happens in Production: Sync, I/O and Network Deep Dive

6 Root Causes of Transport and Apply Lag, With Diagnostic SQL to Prove Each One

06 March 2026

Chetan Yadav, Senior Oracle & Cloud DBA

⏱️ 14 - 16 min read

⏱️ Estimated Reading Time: 14 - 16 minutes

Transport Lag, Apply Lag, SYNC vs ASYNC, Network RTT, Standby I/O, MRP Apply Bottleneck

⚙️ Production Environment Referenced

Oracle Database: 19.18.0.0.0 Enterprise Edition  •  Primary: 2-Node RAC, 4.8 TB OLTP  •  Standby: Physical Standby (Active Data Guard)
Protection Mode: Maximum Availability (SYNC/AFFIRM)  •  Network: Dedicated 1 GbE WAN, 120 km, RTT 1.8 ms
Peak Load: 2,800 TPS, 180 MB/sec redo generation  •  Application: Core banking transaction processing

The monitoring alert fires at 11:43 PM: "Data Guard apply lag exceeds 900 seconds." Transport lag is 180 seconds. Apply lag is 900 seconds. The standby is 15 minutes behind the primary. If the primary fails right now, 15 minutes of financial transactions are at risk.

This scenario happens in production Data Guard environments more often than most teams admit. The problem looks the same from the outside every time, but the root cause is completely different each time. Transport lag and apply lag each have different causes, different diagnostic queries, and different fixes. Treating them as the same problem wastes hours of investigation.

This guide covers all six real production causes of Data Guard lag, the exact SQL to identify each one, and the specific fix for each. No guesswork. Precise diagnosis first, then precise resolution.

Why Data Guard Lag Happens in Production: Sync, I/O and Network Deep Dive

Six Root Causes of Transport and Apply Lag , With Diagnostic SQL to Prove Each One

30 March 2026

Chetan Yadav , Senior Oracle & Cloud DBA

⏱️ 14–16 min read

⏱️ Estimated Reading Time: 14–16 minutes

Transport Lag • Apply Lag • SYNC vs ASYNC • Network RTT • Standby I/O • MRP Apply Bottleneck

⚙️ Production Environment Referenced in This Article

Oracle Database: 19.18.0.0.0 Enterprise Edition  •  Primary: 2-Node RAC, 4.8 TB OLTP  •  Standby: Physical Standby (Active Data Guard)
Protection Mode: Maximum Availability (SYNC/AFFIRM)  •  Network: Dedicated 1 GbE WAN (120 km distance, RTT 1.8 ms)
Peak Load: 2,800 TPS, 180 MB/sec redo generation  •  Application: Core banking transaction processing

The alert arrives at 11:43 PM: "Data Guard apply lag exceeds 900 seconds." The DBA on call opens the monitoring dashboard. Transport lag is 180 seconds. Apply lag is 900 seconds. The standby is 15 minutes behind the primary. If the primary fails right now, 15 minutes of financial transactions could be at risk.

This scenario plays out in production Data Guard environments more often than most teams admit. Lag is not a single problem , it is six different problems that look identical from the outside. Transport lag and apply lag each have completely different root causes, different diagnostic queries, and completely different fixes. Treating them the same wastes hours of investigation time.

This guide covers every real cause of Data Guard lag I have diagnosed in production, the exact SQL to prove which one you are dealing with, and the specific fix for each. No guesswork. No generic advice about "check your network." Precise diagnosis first, then precise resolution.