Oracle 19c Performance Tuning
Monday, June 8, 2026
Monday, June 1, 2026
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.
Monday, May 25, 2026
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.
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.
Subscribe to:
Posts (Atom)