How to Read Oracle AWR Report in 19c: DBA Guide

How to Read an Oracle AWR Report in 19c

A practical reading order from real production incidents, not a feature tour.

Oracle 19c Performance Tuning AWR Report Production DBA

An AWR report is a snapshot of where your instance spent its time. Reading it in the right order is half the battle.

02:14. The on-call page hit: checkout API p95 had jumped from 180 ms to 4.2 seconds. No errors. No node eviction. No failover. Just a database that had quietly gone slow under a normal load. The first artifact I pulled was a one-hour AWR report, and within four minutes it pointed straight at the cause.

If you have ever stared at a 30-page AWR report and not known where to look first, this guide is for you. Knowing how to read an Oracle AWR report in 19c is not about understanding every section. It is about reading a handful of sections in the right order so you can go from "the database is slow" to "this SQL on this object is the problem" in minutes. That is exactly what I did at 02:14, and it is the workflow I will walk you through here.

AWR (Automatic Workload Repository) takes regular snapshots of performance statistics and stores them in the SYSAUX tablespace. A report compares two snapshots and shows you the delta: what the instance did, where it waited, and which statements drove the load. The trick is to stop reading top to bottom and start reading by importance.

Who this guide is for

Junior and mid-level DBAs who can generate an AWR report but freeze when it comes to interpreting it, and senior engineers who want a tighter triage checklist for incidents. Examples use Oracle 19c, but the reading order applies to 12c and 18c as well.

Standby Redo Logs Not Applying Oracle Data Guard Fix

Standby Redo Logs Not Applying in Oracle Data Guard: Complete Fix Guide

MRP process troubleshooting, SRL configuration, apply lag resolution, and parallel apply tuning from 15 years of production Oracle environments.

Oracle 19c / 21c Data Guard Troubleshooting Senior DBA Production Guide

Who This Is For: Junior to Senior Oracle DBAs managing Oracle 19c or 21c Data Guard environments who are troubleshooting standby redo logs not applying, MRP process failures, or unexplained apply lag. Freshers studying for Oracle certification will also benefit from the architecture walkthrough.

It was 2:41 AM. PagerDuty fires. The on-call message reads: "Data Guard apply lag 38 minutes and climbing." I SSH into the standby. ORA-16766 stares back at me from the alert log. A quick check of V$MANAGED_STANDBY confirms it -- MRP0 is gone. No standby redo logs are applying. The business had a 4-hour RPO commitment. We had maybe 90 minutes before the DBA team had a very uncomfortable conversation with the CTO.

Standby redo logs not applying in Oracle Data Guard is one of the highest-stress incidents a production DBA faces. It is also one of the most fixable -- if you know the exact diagnostic tree. In this post I am going to walk through every root cause I have encountered across 15 years of Oracle production work, the precise SQL to diagnose each one, and the fix you run to get apply moving again.

Environment Reference: Oracle 19c (19.19 RU), 2-node RAC primary + single-node physical standby, SYNC transport, 6 TB database, peak 12,000 TPS. All SQL verified in this environment. Steps also apply to Oracle 21c and Oracle 23ai Data Guard configurations.

MRP Process Not Running in Data Guard: Fix in Oracle 19c

MRP Process Not Running in Data Guard? Fix It Step-by-Step (Oracle 19c)

5 Root Causes, DGMGRL Diagnosis and Exact Fix Commands for Every Scenario

📅 April 2026

👤 Chetan Yadav, Senior Oracle & Cloud DBA, Oracle ACE Apprentice

⏱️ 12,14 min read

⏱️ Estimated Reading Time: 12,14 minutes

MRP Not Running, ORA-16766, DGMGRL Fix, SRL Creation, Broker State, Auto-Start Trigger, Oracle 19c

⚙️ Environment Referenced in This Article

Oracle Database: 19.18.0.0.0 Enterprise Edition  •  Primary: 2-Node RAC, 4.8 TB OLTP, 2,800 TPS
Standby: Physical Standby with Active Data Guard enabled
Protection Mode: Maximum Availability (SYNC/AFFIRM)  •  Broker: Data Guard Broker enabled

The monitoring alert arrived at 2:48 AM: "Standby apply lag crossing 90 minutes." I connected to DGMGRL immediately. SHOW CONFIGURATION confirmed it: the MRP process was not running on the standby. Every transaction committed on the primary for the past 90 minutes was sitting unprocessed in Standby Redo Logs, and the gap was growing by the second.

In my 15 years managing Oracle production environments, a stopped MRP process is one of the most common Data Guard incidents I have resolved. It is not complicated once you know which of the five root causes you are dealing with. The problem is that each cause has a completely different fix, and applying the wrong one wastes critical time.

This guide gives you the exact decision path, the diagnostic commands to identify your specific cause, and the precise fix for each scenario. In most cases the MRP process not running in Data Guard is resolved in under 5 minutes.

SAP HANA Logging Behavior Explained: Commit, Savepoint & Crash Recovery (Real Production Guide)

⏱️ Estimated Reading Time: 12–14 minutes

SAP HANA Logging Behavior: What Really Happens During a Production Crash

It’s 2:13 AM. Your SAP application suddenly freezes. End users can’t post transactions. SAP HANA Studio shows the database restarting. Phone calls start coming in.

“Did we lose data?”

In real production environments, this question does not depend on luck. It depends entirely on how SAP HANA logging behavior works behind the scenes.

This article explains SAP HANA logging not as documentation theory, but as it behaves during real crashes, restarts, and recovery situations.

Oracle Listener Health Check: Preventing Silent Production Outages

This guide explains how Oracle Listener failures silently impact production systems

⏱️ Estimated Reading Time: 14 minutes

Oracle Listener Health Check

It’s 2 AM. Your phone lights up with alerts. Applications are down, dashboards are red, and every connection attempt fails with TNS-12541: TNS:no listener. The database is up — but the business is still dead.

In real production environments, a failed Oracle Listener can block thousands of users, cause SLA breaches, and trigger revenue loss within minutes. We’ve seen P99 login latency jump from milliseconds to total outages.

This guide shows how to implement a production-grade Oracle Listener health check using scripts, monitoring logic, and automation — before the listener becomes your single point of failure.