What is latch contention and how does it spike CPU in Oracle?

Latch contention occurs when multiple sessions spin-wait on library cache or shared pool latches. Spin-waiting burns CPU in a tight loop. A small shared pool relative to parsing workload or hard parsing of non-reusable SQL are the most common triggers.

How do I restart the MRP process in Oracle Data Guard 19c?

Run on the standby: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Then verify with: SELECT process, status FROM v$managed_standby WHERE process='MRP0'; If using Data Guard Broker, run in DGMGRL: EDIT DATABASE standby_db SET STATE='APPLY-ON';

Does ORA-16766 cause data loss?

ORA-16766 itself does not cause data loss immediately. However, while MRP is stopped, the standby is not applying redo. If the primary fails during this window, you will lose all redo generated since MRP stopped. Fix it as soon as it is detected.

How do I ask for a referral without being awkward?

Start with a genuine connection message mentioning something specific about their work. Build the relationship over 1 to 2 weeks of conversation before asking. Always make it easy for them to say no, which actually increases the yes rate.

Chetan Yadav

Oracle High CPU Usage: Causes and Fix in 19c

2026-06-08T11:00:00.000+05:30

Oracle High CPU Usage: Causes and Fix in 19c

Oracle 19c Performance Tuning

Oracle High CPU Usage: Causes and Fix in 19c

 Chetan Yadav — Senior Oracle DBA ⏱ 10 min read  Troubleshoot Guide

It is 3:12 AM. PagerDuty fires. The alert reads: Oracle host CPU at 94% for 8 minutes. You log into the server. The database process is consuming nearly every available core. The application is timing out. Users are getting errors. And nobody knows which query started it or when.

This is the oracle high cpu usage fix 19c scenario that every production DBA eventually faces. The frustrating part is not the incident itself — it is that in most cases the fix takes under ten minutes once you know exactly where to look. The problem is that without a structured diagnostic sequence, engineers burn 45 minutes checking the wrong things first.

This guide covers the three root causes behind the majority of Oracle 19c CPU spikes: runaway SQL and full table scans, parallel query overload, and latch contention in the shared pool. For each cause: exact diagnostic SQL, correct and wrong result interpretation, the fix, its trade-off, and the confirmation step.

Cause 1: Runaway SQL and Oracle CPU Spike from Bad Execution Plans

The most common cause of a sudden Oracle CPU spike in 19c is a single SQL statement consuming a disproportionate share of CPU — typically because it is performing a full table scan on a large table, using a suboptimal join method, or has had its execution plan invalidated by a statistics refresh or cursor invalidation event. In Oracle 19c, Adaptive Query Optimization can occasionally select an execution plan that was correct for initial statistics but behaves catastrophically under production data distribution, and the optimizer will not self-correct until the cursor ages out of the shared pool.

The threshold where a runaway SQL becomes a host-level incident rather than a slow query is when it consumes more CPU than the OS can schedule on its available cores, creating a queue of waiting processes. On a 16-core host, a single parallel query with DOP 32 can drive CPU to 100% in under a minute.

Production Indicator If CPU spiked within minutes of a statistics job completion, an index drop, or an application deployment, assume a plan change first. This is the most common trigger in 19c environments.

Step 1: Find the top CPU-consuming SQL right now.

SQL — Top CPU Consumers from V$SQL

-- Run this first during the incident
SELECT sql_id,
       ROUND(cpu_time/1000000, 2) AS cpu_seconds,
       executions,
       ROUND(cpu_time/NULLIF(executions,0)/1000000,4) AS cpu_per_exec,
       SUBSTR(sql_text, 1, 80) sql_preview
FROM   v$sql
WHERE  last_active_time > SYSDATE - 1/24
ORDER BY cpu_time DESC
FETCH FIRST 10 ROWS ONLY;

Correct result: CPU seconds spread across many SQL IDs, no single statement above 20% of total. Wrong result: One SQL ID showing 80%+ of cumulative CPU seconds. That is your runaway statement.

Step 2: Check what is currently running on CPU using ASH.

SQL — Active Sessions ON CPU (ASH)

-- Shows sessions currently burning CPU right now
SELECT ash.sql_id,
       ash.session_id,
       ash.session_serial#,
       ash.module,
       COUNT(*) AS ash_samples
FROM   v$active_session_history ash
WHERE  ash.sample_time > SYSDATE - 5/1440
  AND  ash.session_state = 'ON CPU'
GROUP BY ash.sql_id, ash.session_id,
         ash.session_serial#, ash.module
ORDER BY ash_samples DESC;

Correct result: No SQL ID appearing in more than 20% of samples over 5 minutes. Wrong result: One SQL ID dominating ASH samples consistently — this is the active runaway. Note the SESSION_ID and SESSION_SERIAL#.

Fix: Kill the session, then fix the plan.

SQL — Kill Session + Apply SQL Profile

-- Step A: Kill the runaway session immediately
ALTER SYSTEM KILL SESSION '<sid>,<serial#>' IMMEDIATE;

-- Step B: Lock the good plan using a SQL Profile
-- First, get the sql_id and the plan hash of the good plan from AWR
DBMS_SQLTUNE.IMPORT_SQL_PROFILE(
  sql_text    => '<full SQL text>',
  profile     => SQLPROF_ATTR('OPT_PARAM(''optimizer_features_enable'' ''19.1.0'')'),
  name        => 'PROFILE_FIX_RUNAWAY_SQL',
  force_match => TRUE
);

-- Step C: Flush only the bad cursor from shared pool
EXEC SYS.DBMS_SHARED_POOL.PURGE('<address>,<hash_value>', 'C');

Trade-off Killing a session with IMMEDIATE rolls back its transaction, which may take time proportional to the undo generated. Do not kill sessions during a financial period close without confirming the transaction is safe to roll back. A SQL Profile is a better long-term fix than hints in the query, because it survives code deployments.

Cause 2: Parallel Query CPU Overload from Uncontrolled DOP in Oracle 19c

Parallel query is Oracle's most powerful performance feature and one of its most dangerous misuse patterns. In Oracle 19c with PARALLEL_DEGREE_POLICY = AUTO, the optimizer can autonomously decide to execute a full table scan or aggregation in parallel, potentially spawning PX slave processes well beyond what the host hardware can sustain. When the degree of parallelism exceeds the number of available CPU cores, the OS scheduler begins context-switching between PX slaves — and context switching itself consumes CPU, creating a feedback loop where adding more parallel slaves makes the query slower while driving CPU higher.

The specific threshold that changes behavior: on a host with N CPU cores, any query spawning more than N/2 PX slaves will begin competing with itself for CPU scheduler time. At N PX slaves, the overhead typically exceeds the parallelism benefit for most OLTP-adjacent workloads. This behavior is version-specific: 19c with AUTO policy is more aggressive than 12c in its autonomous DOP selection, and the PARALLEL_MIN_TIME_THRESHOLD parameter (default 10 seconds) may be set too low in environments that were migrated from earlier versions.

SQL — Identify Parallel Query Overload

-- Step 1: Count active PX slaves per coordinator session
SELECT qcsid,
       qcserial#,
       COUNT(*) AS px_slave_count,
       server_group
FROM   v$px_session
GROUP BY qcsid, qcserial#, server_group
ORDER BY px_slave_count DESC;

-- Step 2: Check current parallel parameters
SHOW PARAMETER parallel_max_servers;
SHOW PARAMETER parallel_degree_policy;
SHOW PARAMETER cpu_count;

Correct result: px_slave_count per coordinator below cpu_count / 2. Wrong result: Any coordinator showing px_slave_count above cpu_count — this coordinator is driving a CPU overload event. If parallel_degree_policy is AUTO and cpu_count is 32, a px_slave_count of 64 means the optimizer autonomously doubled available parallelism.

SQL — Fix Parallel Overload Without Restart

-- Immediate fix: limit DOP system-wide
ALTER SYSTEM SET parallel_degree_policy = MANUAL;
ALTER SYSTEM SET parallel_max_servers = 16; -- = cpu_count / 2

-- Raise the auto-parallel threshold to prevent future AUTO overselection
ALTER SYSTEM SET parallel_min_time_threshold = 30; -- seconds

-- Limit DOP for a specific table permanently
ALTER TABLE schema.large_table PARALLEL 4;

-- Confirm: verify no coordinator now exceeds cpu_count/2 slaves
SELECT qcsid, COUNT(*) slave_count
FROM v$px_session
GROUP BY qcsid
ORDER BY slave_count DESC;

Trade-off Switching from AUTO to MANUAL parallel degree policy disables automatic parallelism for full table scans and aggregations. Long-running batch jobs that relied on AUTO parallelism will run slower. Coordinate with the batch team before making this change permanent. A middle ground is setting PARALLEL_DEGREE_POLICY = LIMITED, which applies auto-DOP only to queries that already have a PARALLEL hint or table-level parallel degree set.

Cause 3: Latch Contention and Library Cache CPU Spin in Oracle 19c

Latch contention is the CPU spike cause that most engineers do not consider first, because it does not involve a visible slow query. When multiple sessions compete for the same latch — most commonly the library cache latch or the shared pool latch — Oracle sessions spin in a CPU-burning busy-wait loop before escalating to a sleep. This spin-wait is intentional: it is faster than a context switch for short contention windows. But when contention is sustained, hundreds of sessions spinning simultaneously drive CPU utilization to the ceiling while appearing idle from an application perspective.

In Oracle 19c, the most common trigger for library cache latch contention is hard parsing at high frequency. Hard parsing occurs when a SQL statement cannot be matched to an existing cursor in the shared pool, typically because literals are used instead of bind variables, because the shared pool is undersized for the workload, or because a cursor invalidation event (statistics refresh, DDL on an underlying object) forced mass re-parsing. The shared pool latch protects the memory management structures of the shared pool itself and contends under heavy allocation and deallocation activity.

SQL — Diagnose Latch Contention

-- Step 1: Find latches with high sleep rates
SELECT name,
       gets,
       misses,
       sleeps,
       spin_gets,
       ROUND(sleeps/NULLIF(gets,0)*100, 4) miss_pct
FROM   v$latch
WHERE  sleeps > 1000
ORDER BY sleeps DESC
FETCH FIRST 10 ROWS ONLY;

-- Step 2: Check hard parse rate
SELECT name, value
FROM   v$sysstat
WHERE  name IN ('parse count (hard)',
                'parse count (total)',
                'execute count')
ORDER BY name;

Correct result: miss_pct below 0.5% for library cache latch. Hard parse count below 5% of execute count. Wrong result: Library cache latch miss_pct above 1%, combined with hard parse count above 20% of execute count. This confirms literal SQL driving hard parses and latch contention.

SQL — Find Literal SQL Driving Hard Parses

-- Find SQL with high version counts (literal explosion)
SELECT sql_id,
       version_count,
       SUBSTR(sql_text, 1, 100) sql_preview
FROM   v$sqlarea
WHERE  version_count > 20
ORDER BY version_count DESC
FETCH FIRST 10 ROWS ONLY;

-- Fix: resize shared pool online
ALTER SYSTEM SET shared_pool_size = 2G SCOPE = BOTH;

-- Enable cursor sharing for literal SQL (temporary relief)
ALTER SYSTEM SET cursor_sharing = FORCE;

-- Confirm: flush shared pool then check latch sleeps trend
ALTER SYSTEM FLUSH SHARED_POOL;
-- Re-run v$latch query above and compare sleeps delta

Trade-off Setting CURSOR_SHARING = FORCE is a temporary relief measure, not a permanent fix. It causes Oracle to replace literals with system-generated bind variables, which can produce suboptimal plans for queries where the optimizer needs literal values for histogram-based selectivity. The correct permanent fix is to modify the application to use bind variables. Use FORCE only during the incident window, then audit and fix the SQL.

What Most DBAs Miss When Diagnosing Oracle High CPU Usage

The diagnostic step that consistently gets skipped is correlating the CPU spike timestamp with the AWR snapshot boundary. When Oracle CPU usage spikes in production, the instinct is to run live queries against V$ views. But if the spike already peaked and is subsiding, V$ views show the current state — not the peak state. AWR captures a snapshot every 60 minutes by default. The peak CPU event may have started and ended within a single AWR interval, leaving no clean before/after comparison.

The correct approach for any Oracle CPU spike that lasts more than 15 minutes is to immediately take a manual AWR snapshot at the peak:

SQL — Manual AWR Snapshot During Incident

-- Take snapshot immediately at peak CPU (preserves state)
EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

-- After incident, generate AWR report between the two snapshots
-- Replace snap_id values with actual snapshot IDs
SELECT *
FROM TABLE(
  DBMS_WORKLOAD_REPOSITORY.AWR_REPORT_TEXT(
    l_dbid       => &dbid,
    l_inst_num   => 1,
    l_bid        => &begin_snap_id,
    l_eid        => &end_snap_id
  )
);

The second thing most engineers miss is checking V$OSSTAT for OS-level CPU breakdown. A high Oracle process CPU does not always mean Oracle is the problem — another OS process could be competing. V$OSSTAT shows the split between user CPU, system CPU, and idle time from the database's perspective, and it takes 30 seconds to check.

SQL — OS CPU Breakdown from Inside Oracle

SELECT stat_name,
       value,
       ROUND(value / 1e6, 2) cpu_seconds
FROM   v$osstat
WHERE  stat_name IN (
  'NUM_CPUS', 'NUM_CPU_CORES',
  'BUSY_TIME', 'IDLE_TIME',
  'USER_TIME', 'SYS_TIME'
)
ORDER BY stat_name;

Prevention: Monitoring Setup for Oracle CPU Spikes in 19c

Enable automatic AWR baselines for peak periods

A static AWR baseline captures the normal operating range for CPU and other metrics. Any deviation from baseline triggers a meaningful alert rather than a raw threshold alert that fires even during legitimate batch windows.

Run: EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id => &normal_snap, end_snap_id => &normal_snap_end, baseline_name => 'NORMAL_PEAK');

Set a hard limit on PARALLEL_MAX_SERVERS

The default value is derived from cpu_count and is often too high for OLTP databases that occasionally run ad-hoc analytical queries. Set PARALLEL_MAX_SERVERS to cpu_count at startup and document the rationale. The most commonly skipped step: verifying this parameter survived a database restart after patching. Check it monthly.

Monitor hard parse rate daily via a scheduled query

Add a daily check of hard parse count as a percentage of execute count. Any day where hard parses exceed 10% of executes warrants investigation before it becomes a latch contention incident. Alert threshold: hard parse rate above 15% of execute count. Schedule this check to run at 08:00 daily and email results to the DBA team.

Frequently Asked Questions

How do I find which SQL is causing high CPU in Oracle 19c?

Query V$SQL ordered by CPU_TIME descending for cumulative CPU consumers, or use V$ACTIVE_SESSION_HISTORY filtering on SESSION_STATE='ON CPU' for real-time identification. ASH is the faster diagnostic during an active incident because it shows what is running right now, while V$SQL shows what has consumed the most CPU since cursor load. Both queries are in the diagnostic section above with exact column lists and correct-vs-wrong result interpretation.

Can parallel query cause Oracle high CPU usage on a well-sized host?

Yes, and it is more likely on a well-sized host than an undersized one. A host with 64 cores and PARALLEL_DEGREE_POLICY=AUTO can spawn 128 PX slaves for a single query. The OS scheduler cannot run 128 threads on 64 cores simultaneously, and the context-switching overhead itself burns CPU. A well-sized host gives Oracle more cores to misuse with AUTO parallelism. The fix is setting an explicit ceiling with PARALLEL_MAX_SERVERS and switching from AUTO to LIMITED or MANUAL degree policy for OLTP workloads.

What causes latch contention in Oracle 19c and how does it relate to CPU spikes?

Latch contention occurs when hundreds of sessions simultaneously compete for the same in-memory serialisation structure — most commonly the library cache latch protecting cursor memory, or the shared pool latch protecting memory allocation. Oracle sessions spin in a CPU-burning busy-wait before sleeping. High-frequency literal SQL that generates thousands of unique cursor versions is the most common trigger in 19c environments. The fix combines resizing the shared pool online, setting CURSOR_SHARING=FORCE as temporary relief, and fixing the application to use bind variables.

How do I apply oracle high cpu usage fix 19c without restarting the database?

All three fixes described in this guide are online operations that require no database restart. Kill the runaway session with ALTER SYSTEM KILL SESSION ... IMMEDIATE. Apply a SQL Profile to lock a good execution plan using DBMS_SQLTUNE.IMPORT_SQL_PROFILE. Limit parallel degree with ALTER SYSTEM SET PARALLEL_DEGREE_POLICY=MANUAL. Resize the shared pool with ALTER SYSTEM SET SHARED_POOL_SIZE=Xg SCOPE=BOTH. Each change takes effect within seconds. Confirm with the verification queries provided in each section above.

Want the Complete Oracle Performance Toolkit?

Drop a comment on this post with the keyword below and I will send you the AWR Analysis Walkthrough PDF — includes the full diagnostic SQL pack, execution plan interpretation guide, and the monitoring dashboard queries I use in production.

Comment: AWR

Oracle DBA Performance Tuning Oracle 19c Production DBA High Availability LevelUp Careers

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

2026-06-01T11:00:00.000+05:30

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.

What this guide covers

What an AWR report actually tells you
How to read an Oracle AWR report in 19c: the 6-step order
Steps 1 to 3: the 90-second triage
Step 4: Top 10 Foreground Wait Events (the heart)
Step 5: SQL Statistics, mapping waits to SQL
Generating the report in 19c
What NOT to do with an AWR report
Frequently asked questions

The 6-step reading order and the key metrics to watch in an Oracle 19c AWR report.

What an AWR report actually tells you

An AWR report answers one question: during this window, where did the database spend its time? Everything else is supporting detail. The single most important concept is DB Time, the total time spent by sessions inside the database, either working on CPU or waiting on something. If you understand DB Time and where it went, you understand the report.

Think of it like a budget. DB Time is the total money spent. The Top Wait Events section is the itemised bill. The SQL Statistics section names who was spending it. Your job is to read the bill, not to audit every line item in the building.

FROM PRODUCTION

My reference environment for this guide: Oracle 19c (19.21), three-node RAC, roughly 8 TB database, peak around 4,500 transactions per second, on 32-core nodes. On that system a healthy one-hour report shows DB Time well within the combined core count. When a single instance shows DB Time several multiples of its 32 cores, I know sessions were queuing before I read another line.

How to read an Oracle AWR report in 19c: the 6-step order

Here is the order I read every report in, regardless of the symptom. The goal of the first three steps is a fast sanity check. The real diagnosis happens in steps four and five.

The reading order

Header and DB Time - confirm the window, instance, and how busy the DB was
Load Profile - per-second and per-transaction rates, spot the spike
Instance Efficiency - a quick sanity check, not a scorecard
Top 10 Foreground Wait Events - where DB Time actually went
SQL Statistics - the statements behind those waits
Advisories and Segment Statistics - confirm the fix and find the object

Reading direction matters. Reports are laid out roughly in this order anyway, but the instinct most people fight is the urge to read carefully from the top. Skim steps one to three, then spend your real attention on the waits and the SQL.

Steps 1 to 3: the 90-second triage

Step 1: Header and DB Time

The header confirms the instance name, the host, the database version, and the snapshot interval. Check that you are looking at the right instance and the right window. Then find the DB Time line near the top. Compare DB Time against the Elapsed Time. DB Time divided by elapsed time gives you the average number of active sessions. Hold that number against your CPU core count.

Step 2: Load Profile

The Load Profile gives you rates per second and per transaction: logical reads, physical reads, redo size, executes, and parses. You are not memorising numbers here. You are looking for the one metric that is wildly out of line with a normal day. A 10x jump in hard parses per second, for example, screams "missing bind variables" before you read anything else.

Step 3: Instance Efficiency

This is the section most often misused. Buffer Hit and Library Hit percentages look reassuring near 99 percent, but a high ratio does not mean a healthy database. A runaway query doing millions of buffer gets can show a 99.9 percent buffer hit ratio while crippling the instance. Glance at it, then move on. Never tune toward a ratio.

FROM PRODUCTION

At 02:14 the Load Profile told the story before I reached the waits. Logical reads per second had gone from a baseline near 1.2 million to over 9 million, while transactions per second were flat. Same work, far more gets. That pattern, more reads with no more business volume, almost always means a plan flip on a heavy statement. The buffer hit ratio, meanwhile, sat at a smug 99.8 percent.

Step 4: Top 10 Foreground Wait Events (the heart)

This is where you spend your attention. The Top 10 Foreground Wait Events section, in 19c, ranks the events foreground sessions waited on, by total wait time and as a percentage of DB Time. Whatever sits at the top of this list is, by definition, where your database spent most of its non-CPU time.

A few common patterns and what they usually point to:

db file sequential read high - single-block I/O, often index reads. Frequently a sign of physical reads that should have been cached, or a plan using the wrong index.
db file scattered read high - multi-block I/O, classic full table scans. Pair this with the SQL section to find the offending scan.
log file sync high - commits waiting on redo to be written. Look at commit frequency and redo log device latency.
gc buffer busy / gc cr high - RAC interconnect or block contention across instances.
enq: TX - row lock contention - application locking, not an infrastructure problem.

The key habit: do not just note the top wait, note what percentage of DB Time it represents. A wait that is 4 percent of DB Time is noise. A wait that is 68 percent of DB Time is your incident.

68%

of DB Time sat on db file scattered read in the 02:14 report - full scans where an index should have been used

Step 5: SQL Statistics, mapping waits to SQL

Once you know the dominant wait, the SQL Statistics section names the suspect. AWR ranks SQL several ways, and which list you read depends on the wait you found in step four:

SQL ordered by Elapsed Time - the default starting point. Total wall-clock time per statement.
SQL ordered by CPU Time - when the instance was CPU bound.
SQL ordered by Buffer Gets - when logical reads spiked, as in the 02:14 case.
SQL ordered by Physical Reads - when I/O waits dominated.

Match the list to the wait. I had a buffer-gets spike, so I went straight to SQL ordered by Buffer Gets. One statement, a single SQL_ID, accounted for the overwhelming majority of gets in the window. That is your target. Grab its SQL_ID and pull its execution plan.

SQL

-- Pull the plan history for the offending SQL_ID from AWR
SELECT  sql_id,
        plan_hash_value,
        TO_CHAR(timestamp, 'DD-MON HH24:MI') AS captured,
        optimizer_cost
FROM    dba_hist_sql_plan
WHERE   sql_id = '&sql_id'
GROUP BY sql_id, plan_hash_value, timestamp, optimizer_cost
ORDER BY captured;

If you see two different PLAN_HASH_VALUE rows for the same SQL_ID around the incident, you have confirmed a plan flip. That was exactly the 02:14 root cause: the optimizer had switched from an index range scan to a full table scan after a stats refresh.

The fix, and the result.

I pinned the good plan with a SQL Plan Baseline, then corrected the stale statistics that caused the flip. p95 on the checkout API dropped from 4.2 seconds back to 190 ms within one snapshot interval. Total time from opening the report to identifying the SQL_ID: under five minutes, because I read by importance instead of top to bottom.

Generating the report in 19c

Before you can read a report you need to generate one. In 19c the scripts live under the RDBMS admin directory. For a single instance, use awrrpt.sql. On RAC, where you almost always want one specific instance, use awrrpti.sql.

SQL*Plus

-- Single instance report (interactive)
SQL> @?/rdbms/admin/awrrpt.sql

-- RAC: target a specific instance
SQL> @?/rdbms/admin/awrrpti.sql

-- The script asks for: report type (html/text),
-- number of days, begin snap id, end snap id, and filename.

To choose the right snapshot IDs, list the recent snapshots first so you can pick a window that brackets the incident tightly rather than a generic "last hour".

SQL

-- Find snapshot IDs around the time of the problem
SELECT  snap_id,
        instance_number,
        TO_CHAR(begin_interval_time, 'DD-MON HH24:MI') AS snap_start
FROM    dba_hist_snapshot
WHERE   begin_interval_time > SYSDATE - 1
ORDER BY snap_id;

Keep the window tight. Pick the begin and end snap IDs that hug the slowdown. A report that averages a spike across a quiet hour will dilute the very wait you are hunting for.

What NOT to do with an AWR report

Most wasted hours in AWR analysis come from a handful of repeatable mistakes. Here is the contrast I teach every junior DBA on my team.

Do NOT do this

Read the report top to bottom and get lost in section 2
Chase the buffer hit ratio toward 99 percent as a goal
Generate a 24-hour report for a 5-minute spike
Look only at the top wait, ignoring its share of DB Time
Fix a SQL without confirming the plan actually changed

Do this instead

Jump to Top 10 Foreground Wait Events first faster
Treat efficiency ratios as a sanity glance only
Bracket the incident with a 30 to 60 minute window
Read the percentage of DB Time, not just the rank
Confirm a plan flip via PLAN_HASH_VALUE before acting

FROM PRODUCTION

A common trap on RAC: pulling the global report and missing that only one instance was sick. On a three-node cluster, instance 2 can be on fire while 1 and 3 idle, and the aggregate looks merely "a bit busy". When the symptom is on one node, generate awrrpti.sql for that instance specifically. I have watched engineers tune the wrong instance for an hour because they read the cluster-wide numbers.

Frequently asked questions

How do you read an Oracle AWR report in 19c quickly?

Skip the top-to-bottom read. Start with the header to confirm the snapshot window and DB Time, then jump straight to the Top 10 Foreground Wait Events. That section tells you where time was actually spent. Trace the biggest wait back to the Top SQL section, and you have your suspect in under five minutes.

What is the first section to check when you read an Oracle AWR report in 19c?

Check the report header and the DB Time figure first. The header confirms the instance, the snapshot interval, and the elapsed time. DB Time divided by elapsed time tells you roughly how many sessions were active. If DB Time is far higher than your CPU count, the instance was overloaded during that window.

What is a healthy DB Time to Elapsed Time ratio?

There is no single magic number, but a useful rule is to compare average active sessions against your CPU core count. If DB Time divided by elapsed time stays near or below the number of CPU cores, the instance had headroom. When it runs several times higher than the core count, sessions were queuing and the database was CPU or wait bound.

How long should the AWR snapshot window be?

Keep the window tight around the problem. A one-hour report that spans both a quiet period and a spike will average the spike away and hide it. For a sharp incident I generate a report covering only the two or three snapshots around the slowdown, often a 30 to 60 minute window, so the wait profile reflects the real event.

Is AWR free to use in Oracle 19c?

No. AWR, ASH, and the related advisors are part of the Oracle Diagnostics Pack, which is a separately licensed option on Enterprise Edition. Running awrrpt.sql on an unlicensed instance is a license violation. If you do not hold the pack, use Statspack instead, which is free but collects less detail than AWR.

Want my AWR triage cheat sheet?

I am putting together a one-page printable version of this 6-step reading order with the red-flag thresholds.

Comment the keyword below and I will send it over.

Comment AWR

Chetan Yadav

Senior Oracle & Cloud DBA · Oracle ACE Apprentice · 15+ years production experience

I write field-tested Oracle and Cloud DBA guides for LevelUp Careers, drawn from real production incidents on large RAC and Cloud estates. Connect with me on LinkedIn or subscribe on YouTube.

Standby Redo Logs Not Applying Oracle Data Guard Fix

2026-05-25T11:00:00.000+05:30

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.

SRL Architecture: Why Standby Redo Logs Matter

Before you can fix standby redo logs not applying, you need to understand exactly where they sit in the Data Guard pipeline. The Standby Redo Log (SRL) is the buffer between the Remote File Server (RFS) process -- which receives redo from the primary -- and the Managed Recovery Process (MRP), which applies that redo to standby datafiles.

Without SRLs, Oracle falls back to archivelog-based apply, which introduces a structural lag equal to the time between log switches on the primary. On a busy 12,000 TPS system, that lag can balloon to 20+ minutes in under an hour. With SRLs properly configured, redo flows continuously and apply lag stays under 30 seconds.

Figure 1: SRL pipeline from primary Online Redo Logs through RFS to MRP apply engine. See the separately delivered architecture diagram PNG for the detailed flow.

Key Rule: Oracle mandates SRL group count = (online redo log groups) + 1 at minimum. Each SRL member must be at least as large as the largest online redo log member. On a RAC primary with 3 log groups per thread and 2 threads, you need at least (3 x 2) + 1 = 7 SRL groups.

Step 1: Diagnose the Apply Engine

Every standby redo logs not applying incident starts with the same three queries. Run these on the standby database first.

Query 1: MRP and RFS Process Status

SQL -- V$MANAGED_STANDBY

SELECT
    PROCESS,
    STATUS,
    CLIENT_PROCESS,
    SEQUENCE#,
    BLOCK#,
    BLOCKS
FROM  V$MANAGED_STANDBY
WHERE PROCESS IN ('MRP0', 'RFS')
ORDER BY PROCESS;

Interpret the output:

MRP0 / APPLYING_LOG -- healthy, redo is being applied
MRP0 / WAIT_FOR_LOG -- MRP running but waiting; check for sequence gap
MRP0 absent from result -- MRP not started; most common cause of standby redo logs not applying
RFS / IDLE -- transport up but no current redo flowing; check primary
RFS absent -- redo transport broken; check LOG_ARCHIVE_DEST_2

Query 2: Standby Redo Log Status

SQL -- V$STANDBY_LOG

SELECT
    GROUP#,
    THREAD#,
    SEQUENCE#,
    BYTES / 1048576   AS SIZE_MB,
    STATUS,
    ARCHIVED,
    FIRST_CHANGE#
FROM  V$STANDBY_LOG
ORDER BY GROUP#;

A healthy result shows STATUS = ACTIVE or UNASSIGNED with at least one ACTIVE group per thread. If the query returns zero rows, SRL groups do not exist at all -- jump to Step 2 immediately.

Query 3: Apply Lag and Transport Lag

SQL -- V$DATAGUARD_STATS

SELECT
    NAME,
    VALUE,
    UNIT,
    TIME_COMPUTED
FROM  V$DATAGUARD_STATS
WHERE NAME IN ('apply lag', 'transport lag', 'apply finish time')
ORDER BY NAME;

During the 2:41 AM incident: apply lag = +00 00:38:14, transport lag = +00 00:00:02. Transport lag near zero tells me redo is arriving fine -- the problem is 100% in the apply layer. MRP was stopped by a nightly backup script that ran CANCEL but failed to restart MRP after an error.

Query 4: Archive Destination Status

SQL -- V$ARCHIVE_DEST_STATUS

SELECT
    DEST_ID,
    DEST_NAME,
    STATUS,
    TARGET,
    ARCHIVER,
    SCHEDULE,
    VALID_NOW,
    ERROR
FROM  V$ARCHIVE_DEST_STATUS
WHERE STATUS != 'INACTIVE'
ORDER BY DEST_ID;

STATUS should be VALID. Any value in the ERROR column is your root cause signal. Common: ORA-16058 (standby not mounted), ORA-12541 (TNS no listener), ORA-16057 (standby not in correct state).

Step 2: Create or Fix Standby Redo Logs

Missing or undersized SRL groups cause standby redo logs not applying in roughly 35% of incidents I have handled. This typically happens after a redo log resize on the primary where the standby was not updated to match.

Check Current Online Redo Log Size (Run on Primary)

SQL -- V$LOG primary

SELECT
    GROUP#,
    THREAD#,
    BYTES / 1048576  AS SIZE_MB,
    MEMBERS,
    STATUS
FROM  V$LOG
ORDER BY THREAD#, GROUP#;

Add SRL Groups on the Standby

Target size = primary online redo log size + 10%. For a primary with 50 MB log groups, create 55 MB SRL groups. Run on the standby as SYSDBA:

SQL -- Add SRL Groups (Standby)

-- One SRL group per command; repeat until count = online_groups + 1
-- Adjust paths to match your ASM diskgroup or filesystem

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4
    ('/u01/oradata/ORCL_STBY/srl_4.log')
    SIZE 55M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5
    ('/u01/oradata/ORCL_STBY/srl_5.log')
    SIZE 55M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 6
    ('/u01/oradata/ORCL_STBY/srl_6.log')
    SIZE 55M;

-- ASM example:
-- ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 ('+RECO') SIZE 55M;

Drop and Re-create Undersized SRL Groups

SQL -- Drop Undersized SRL

-- Only drop INACTIVE / UNASSIGNED groups; never drop ACTIVE groups
SELECT GROUP#, STATUS FROM V$STANDBY_LOG;

ALTER DATABASE DROP STANDBY LOGFILE GROUP 4;
ALTER DATABASE DROP STANDBY LOGFILE GROUP 5;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 4
    ('/u01/oradata/ORCL_STBY/srl_4.log') SIZE 55M;

ALTER DATABASE ADD STANDBY LOGFILE GROUP 5
    ('/u01/oradata/ORCL_STBY/srl_5.log') SIZE 55M;

RAC Primary Note: For a RAC primary with 2 threads, add SRL groups for each thread using the THREAD# clause: ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 10 .... Without per-thread SRLs, Thread 2 redo transport has no SRL to write into.

Step 3: Start or Restart the MRP Process

The MRP0 process is the engine that applies redo to standby datafiles. It must be explicitly started unless the standby uses broker with fast-start failover configured.

Start MRP in Background (Recommended)

SQL -- Start MRP

-- DISCONNECT FROM SESSION keeps MRP running after you log off
-- Run on standby as SYSDBA

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    DISCONNECT FROM SESSION;

Stop MRP Cleanly Before Restarting

SQL -- Stop then Restart MRP

-- Use CANCEL to stop; never kill MRP with OS kill -9
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- Wait 30 seconds; confirm MRP0 is gone:
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY
WHERE  PROCESS = 'MRP0';

-- Restart:
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    DISCONNECT FROM SESSION;

Root Cause I Have Seen Repeatedly: A nightly RMAN backup script on the standby that runs CANCEL to pause apply during backup, but fails to restart MRP if the backup errors out. The result is standby redo logs not applying all night, discovered at morning alerting. Fix: wrap the backup script in a shell error trap that always restarts MRP regardless of backup exit code.

Verify MRP Started Correctly

SQL -- Verify MRP

SELECT
    PROCESS,
    STATUS,
    SEQUENCE#,
    BLOCK#,
    DELAY_MINS
FROM  V$MANAGED_STANDBY
ORDER BY PROCESS;

-- Expected: MRP0 STATUS=APPLYING_LOG, SEQUENCE# incrementing

Step 4: Fix LOG_ARCHIVE_DEST Configuration

A misconfigured LOG_ARCHIVE_DEST_2 on the primary prevents redo from reaching the standby entirely. The most common error I see is an incorrect VALID_FOR clause that excludes the current redo stream.

Check Current Configuration (Primary)

SQL -- Check LOG_ARCHIVE_DEST_2

SHOW PARAMETER log_archive_dest_2;

SELECT DEST_ID, STATUS, TARGET, ARCHIVER, VALID_NOW, ERROR
FROM  V$ARCHIVE_DEST_STATUS
WHERE DEST_ID = 2;

Wrong Configuration

VALID_FOR=(ONLINE_LOGFILES, ALL_ROLES)
VALID_FOR=(ALL_LOGFILES, STANDBY_ROLE) excludes primary role
No DB_UNIQUE_NAME when broker is in use
REOPEN=0 disables retry on transport failure

Correct Configuration

VALID_FOR=(ALL_LOGFILES, PRIMARY_ROLE)
DB_UNIQUE_NAME= set to standby unique name
REOPEN=300 retries every 5 minutes on failure
SERVICE= matches TNS alias for standby

SQL -- Fix LOG_ARCHIVE_DEST_2 (Primary)

-- Run on PRIMARY as SYSDBA
-- Adjust SERVICE and DB_UNIQUE_NAME to match your environment

ALTER SYSTEM SET log_archive_dest_2 =
    'SERVICE=ORCL_STBY
     ASYNC
     VALID_FOR=(ALL_LOGFILES,PRIMARY_ROLE)
     DB_UNIQUE_NAME=ORCL_STBY
     REOPEN=300
     COMPRESSION=DISABLE'
    SCOPE=BOTH;

-- For SYNC (zero data loss): replace ASYNC with SYNC AFFIRM
-- and add NET_TIMEOUT=30 to prevent hanging the primary

Step 5: Resolve an Archive Gap

An archive gap means the standby is missing one or more archived log files that MRP needs before it can advance. The FAL (Fetch Archive Log) process resolves gaps automatically, but it can fail if FAL parameters are wrong or the primary archive area is full.

Detect Gaps

SQL -- V$ARCHIVE_GAP

SELECT
    THREAD#,
    LOW_SEQUENCE#,
    HIGH_SEQUENCE#
FROM  V$ARCHIVE_GAP;

-- Rows returned = gap exists; archivelogs must be registered before MRP can proceed

Register Missing Archivelogs Manually

SQL -- Register Archivelog

-- Copy missing archivelog from primary to standby first
-- Then register on standby:

ALTER DATABASE REGISTER LOGFILE
    '/u02/arch/1_998_1145678901.dbf';

ALTER DATABASE REGISTER LOGFILE
    '/u02/arch/1_999_1145678901.dbf';

-- Confirm:
SELECT SEQUENCE#, APPLIED, REGISTRAR
FROM  V$ARCHIVED_LOG
WHERE SEQUENCE# BETWEEN 998 AND 1000
ORDER BY SEQUENCE#;

Fix FAL Parameters (Prevents Future Gaps)

SQL -- FAL Parameters on Standby

ALTER SYSTEM SET fal_server  = 'ORCL_PRIM' SCOPE=BOTH;
ALTER SYSTEM SET fal_client  = 'ORCL_STBY' SCOPE=BOTH;

-- fal_server = TNS service name for the primary
-- fal_client = this standby's TNS service name

After a 4-hour network outage on a 6 TB standby, I had a gap of 288 archive sequences. FAL automatic recovery handled all 288 in 23 minutes once fal_server was corrected. Always fix FAL parameters first and give the FAL process 10-15 minutes before manually copying archivelogs.

Step 6: Tune Parallel Apply to Burn Down Lag Faster

Once MRP is running and SRLs are healthy, the standby may still have accumulated lag to work through. Enabling parallel apply dramatically increases recovery throughput on multi-core standby systems.

SQL -- Enable Parallel Apply

-- Stop MRP first
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- Set parallel apply workers (start with 2x CPU count)
ALTER SYSTEM SET recovery_parallelism = 8 SCOPE=BOTH;

-- Restart MRP with parallel option
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE
    PARALLEL 8
    DISCONNECT FROM SESSION;

Apply throughput improvement: moving from serial to parallel=8 on an 8-core standby cleared 38 minutes of lag in 14 minutes vs. an estimated 58 minutes serial.

Caution: USING CURRENT LOGFILE is required when SRLs are present. Without it, MRP applies only archived logs and ignores the active SRL, reverting to archivelog-mode apply and reintroducing structural lag.

Post-Fix Verification Checklist

Run all of these before closing the incident ticket.

MRP0 STATUS = APPLYING_LOG in V$MANAGED_STANDBY with incrementing SEQUENCE#
Apply lag < 30 seconds in V$DATAGUARD_STATS (allow 5 min to normalize after restart)
All SRL groups STATUS = ACTIVE or UNASSIGNED in V$STANDBY_LOG; no INACTIVE
V$ARCHIVE_DEST_STATUS DEST_ID=2 STATUS = VALID with blank ERROR column
V$ARCHIVE_GAP returns zero rows after gap resolution
DGMGRL show database verbose [standby_name] shows no warnings
Standby alert log -- no new ORA-16xxx errors in last 5 minutes

DGMGRL -- Final Verification

DGMGRL> connect sysdg/password@ORCL_PRIM
DGMGRL> show configuration;
DGMGRL> show database verbose ORCL_STBY;

-- Target output:
-- Database Status: SUCCESS
-- Apply Lag:       0 seconds
-- Transport Lag:   0 seconds

What NOT to Do When Standby Redo Logs Are Not Applying

Do NOT kill MRP with OS-level kill -9. Killing MRP at the OS level can corrupt the standby control file's recovery position, forcing a full resync. Always use ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL.

Do NOT assume a snapshot standby conversion fixes apply issues. Converting to snapshot standby and back resets apply but does not fix the underlying cause -- SRL misconfiguration or MRP issues will recur immediately after.

Do NOT add SRL groups while MRP is actively applying. While Oracle supports it, I have seen MRP stall for up to 8 minutes while new SRL groups initialize on a busy system. Cancel MRP first, add the SRLs, then restart.

Do NOT let the FRA fill while SRLs live inside it. If SRLs reside inside the Flash Recovery Area and the FRA fills, Oracle cannot write to SRLs, which silently stops RFS and apply. Always size FRA at 3x daily redo volume.

Frequently Asked Questions

Why are standby redo logs not applying in Oracle Data Guard?+

Standby redo logs not applying in Oracle Data Guard is most often caused by one of four issues: the MRP process is stopped or was never started, the Standby Redo Log (SRL) groups are missing or misconfigured, a LOG_ARCHIVE_DEST_2 parameter has an incorrect VALID_FOR clause, or there is a redo sequence gap. Run SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS='MRP0' as your first diagnostic step.

How do I check if standby redo logs are applying in Oracle Data Guard?+

Run SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY on the standby. Look for MRP0 with STATUS = APPLYING_LOG and an incrementing SEQUENCE#. Also check V$DATAGUARD_STATS WHERE NAME='apply lag' to confirm lag is near zero. If MRP0 is absent or shows WAIT_FOR_LOG, apply has stalled and you need to investigate SRL and gap status.

How many standby redo log groups should I create?+

Oracle recommends at least one more SRL group than the number of online redo log groups per thread on the primary. For a single-instance primary with 3 online redo log groups, create 4 SRL groups on the standby. For a 2-node RAC primary with 3 groups per thread, create at least 7 SRL groups total. Each SRL member must be at least as large as the largest online redo log member, with 10% extra space recommended.

What does ORA-16766 mean in a Data Guard environment?+

ORA-16766 means the redo apply service is disabled on the standby database. This fires when MRP is stopped or crashed unexpectedly. The fix is to confirm SRL groups exist at the correct size, then issue ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION. Monitor V$MANAGED_STANDBY until MRP0 shows STATUS = APPLYING_LOG. If MRP keeps crashing, check the standby alert log for underlying ORA-600 or ORA-10567 errors.

Can I fix Data Guard apply lag without a full resync?+

Yes. For most apply-lag incidents caused by MRP outages or SRL misconfiguration, a full resync is not required. Restart MRP, verify SRL status in V$STANDBY_LOG, and check for archive gaps using V$ARCHIVE_GAP. The FAL process automatically fetches missing archivelogs once its parameters are correct. A full resync is only necessary when the standby SCN has diverged from the primary, which typically occurs only after an incomplete recovery or an improperly reversed switchover.

Want the Full Data Guard Troubleshooting Runbook?

Comment DG below and I will send you the production-ready DBA PDF covering SRL, MRP, transport gaps, switchover, and DGMGRL commands -- all in one sheet.

Watch on YouTube Connect on LinkedIn

Chetan Yadav

Senior Oracle and Cloud DBA | Oracle ACE Apprentice | 15+ Years Production Experience

I manage large-scale Oracle production environments and share real incidents, fixes, and career guidance through LevelUp Careers. Content covers Oracle 19c/21c/23ai, Data Guard, RAC, performance tuning, and cloud DBA careers.

YouTube LinkedIn Instagram

Fresher Resume Format for Tech Jobs 2026: ATS Tips

2026-05-21T11:00:00.000+05:30

Fresher Resume Format for Tech Jobs 2026: ATS Tips

Fresher Resume Format for Tech Jobs 2026

What ATS filters, what recruiters actually read, and the exact structure that gets callbacks in India's tech hiring market

May 21, 2026 Chetan Yadav 9 min read Freshers Resume Writing

Who this is for: Final-year students, recent graduates, and career switchers applying to tech companies in India and globally in 2026. If you have sent 50+ applications and heard nothing back, the problem is almost certainly your resume format and ATS compatibility, not your skills. After reading this post you will have: the correct fresher resume structure, a copy-ready template, the five most common mistakes to fix today, and an action checklist you can execute this week.

Why Fresher Resumes Fail Before a Human Reads Them

Last quarter I was sitting in on a hiring discussion for a backend developer opening. The recruiter had 200 applications in the queue. She spent eight seconds on each resume during the first pass. Of those 200, 148 were filtered out by the ATS before she even saw them. The remaining 52 were reviewed manually. Of those, 38 were rejected in the first scroll. The shortlist was 14 people. Not because 186 candidates lacked skills. Because 186 candidates did not understand how the screening process actually works.

The fresher resume format for tech jobs 2026 is not about design or length or putting your photo in the corner. It is about surviving two filters in sequence: the automated keyword scan and the eight-second human glance. Most resumes fail the first filter before anyone reads a single line.

75%

of resumes rejected by ATS before a recruiter sees them (Jobscan, 2025)

8 sec

average time a recruiter spends on first manual pass of a fresher resume

cause of ATS rejection: keyword mismatch between resume and job description

In hiring discussions I have been part of, the single biggest reason freshers in India are not getting callbacks is not their CGPA or their college. It is that their resume is formatted in a way the ATS cannot parse correctly, or that it is missing the exact keywords the system is scanning for. A two-column resume built in a Canva template looks professional to a human and is completely unreadable to an ATS. The name field gets mixed with the skills section. The section headings do not match what the ATS expects. The resume scores near zero and is rejected automatically.

Having reviewed hundreds of fresher profiles across multiple hiring cycles, the pattern is consistent: candidates with 7+ certifications and no projects get screened out faster than candidates with one live GitHub project and a clean, keyword-matched resume. The ATS does not count certifications. It matches keywords.

The Correct Fresher Resume Format for Tech Jobs 2026

The format that consistently passes ATS filters and survives the first human scan follows a specific structure. Every section has a job. Nothing is decorative.

The Section Order That Works

Name and Contact (top): Name, email, mobile, LinkedIn URL, GitHub or portfolio link. No photo, no date of birth, no address beyond city. These fields belong in the main text body, never in a header or footer, because ATS parsers frequently skip header and footer regions entirely.
Professional Summary (40 words max): Not an objective. A summary. Objective says what you want. Summary says what you offer. One sentence: role target + primary skill + one proof point. This is the most underused section on fresher resumes and the first thing a recruiter reads after your name.
Technical Skills: A clean table or grouped list. Split by category: Languages, Frameworks, Databases, Tools, Cloud Platforms. Match the exact terms from the job descriptions you are targeting. Not "good knowledge of Java" but simply "Java." ATS systems match exact keywords.
Projects (2-3 projects): This replaces Experience for freshers. Each project follows the same structure: the problem it solved, the technology and action you took, and the measurable outcome. Include a GitHub or live URL on every project. Recruiters click these.
Education: Degree, college name, graduation year, CGPA (include only if 7.5 or above). If you have relevant coursework, add 2-3 course names in a single line. No need to list every subject.
Certifications: Name, platform, year. Only include certifications directly relevant to the role. A cloud certification on a backend developer resume is relevant. A digital marketing certificate is not.

Format rules that directly affect ATS score: Single column only. Save as .docx or text-clean PDF. Use standard section headings: Experience, Education, Skills, Projects. No tables for layout. No text boxes. No graphics or icons. No coloured backgrounds. Arial, Calibri, or similar readable font at 10-12pt. Margins between 0.5 and 1 inch on all sides.

Resume structure breakdown, ATS rules, before/after comparison, and 5-step action plan for fresher tech resumes in 2026

Step-by-Step: Build Your Resume This Week

Step 1: Collect Three Target Job Descriptions

Before you write a single word on your resume, open three job postings on LinkedIn or Naukri that match the role you want. Copy the entire requirements and responsibilities sections into a text file. Highlight every technical term that appears more than once across all three JDs. These repeated terms are your keyword targets. Your resume must contain these exact phrases in your Skills section and in your project bullets. This is not gaming the system. This is basic relevance matching.

Rule Do not start writing your resume before you have done this. Without target keywords, your resume is written in the dark.

Step 2: Write Your Projects in PAO Format

PAO stands for Problem, Action, Outcome. Every project bullet follows this pattern. The mistake most freshers make is listing what the project was instead of what it did. Recruiters do not want to know what the project is called. They want to know what problem it solved, what you built, and what the result was.

Weak Version (what most freshers write)

Built a student attendance management system using Java and MySQL
Created a web application for the college fest
Developed a chatbot using Python

Strong Version (PAO format)

Automated manual attendance tracking for 800-student college; built Java/Spring Boot REST API with MySQL, reducing admin time by 4 hours/week. GitHub: [link]
Built event registration portal serving 1,200 users over 3-day college fest; deployed on AWS EC2. Zero downtime during event.
Built FAQ chatbot for college helpdesk using Python and Rasa; deflected 60% of common queries without human intervention.

Step 3: Write a Targeted Summary, Not an Objective

The Objective section has been obsolete in tech hiring for at least five years. Recruiters skip it. Replace it with a three-line Summary that tells them exactly who you are and why they should read further. The format: current status + primary technical strength + one proof point from your projects or internships.

SUMMARY TEMPLATE

Final-year Computer Science graduate (graduating June 2026) with hands-on
experience in Java, Spring Boot, and REST API development. Built 3 live
projects on GitHub including a scalable task management API handling
10K+ requests. Targeting backend developer roles at product companies.

--- Customise these fields ---
[Graduation month/year]
[Your primary technical stack: Python/Django, React/Node, Java/Spring Boot]
[Your top project outcome: stars, users, scale, performance gain]
[Role and company type you are targeting]

Step 4: Build a Clean Skills Section

Group skills by category. Do not list them as a comma-separated paragraph. A grouped list is easier to scan in eight seconds and parses correctly in ATS. Only list skills you can answer questions about in an interview. If you list Docker on your resume, expect a Docker question in the screening call.

Step 5: Run Through a Free ATS Checker Before Applying

Jobscan (free tier) and Resume Worded (free tier) let you paste your resume and a job description and get an ATS compatibility score. Do this before every application. A score below 60% means you are almost certainly getting filtered out. Adjust keywords until you are above 75% for every role you care about.

Warning Do not keyword-stuff. Paste the same keyword 15 times in white text. ATS systems have evolved to penalise this and some employers actively flag it.

5 Mistakes That Guarantee Rejection

These patterns repeat across every hiring cycle without exception. They are not character flaws. They come from outdated advice, college placement cell templates from 2015, and no one ever directly telling freshers what actually gets filtered.

Mistake 1 The Objective Statement

"To obtain a challenging position in a reputed organisation where I can utilise my skills and grow professionally." No recruiter has ever read this and thought positively. It says nothing. It takes up the most valuable real estate on your resume. Replace it with a targeted summary immediately.

Mistake 2 One Resume for Every Application

ATS systems score your resume based on how well it matches the specific job description. A single resume sent to 200 jobs will score low on all of them. You do not need 200 different resumes. You need 3-4 targeted versions, one for each role type you are applying to: backend developer, data analyst, frontend developer, DevOps. Adjust keywords for each.

Mistake 3 Creative Templates with Columns and Graphics

Canva templates, Novoresume two-column layouts, and visually impressive designs with skill bars and icons fail ATS parsing. The parser reads left to right, column by column, and mixes your name with your skills. The output is garbled and the resume is rejected. Plain single-column format only for applications going through any portal or applicant tracking system.

Mistake 4 Skills That Are Not Skills

"Good communication," "team player," "MS Word," "Photoshop," "hard working." These are not technical skills. They waste space, dilute your keyword density, and signal to the recruiter that you do not understand what the role requires. Every skill on your resume should be something an interviewer could ask a technical question about.

Mistake 5 Three Pages with No Projects

A three-page fresher resume padded with hobbies, school-level achievements from 2019, and detailed descriptions of every college club activity is a red flag. Recruiters expect freshers to have one page. If you cannot fit in one page, you are including irrelevant content. Cut ruthlessly. Keep what is relevant to the role you are applying for.

Copy-Ready Templates and Before vs After Examples

The template below is a complete one-page fresher resume skeleton in plain text format. It is ATS-clean, keyword-ready, and works for any tech role. Personalise the fields in brackets, replace with your actual project data, and run it through an ATS checker before applying.

FRESHER RESUME TEMPLATE (ATS-Clean, 2026)

YOUR FULL NAME
[city], India | [mobile] | [email] | linkedin.com/in/[yourname] | github.com/[yourname]

SUMMARY
[Role target] with expertise in [primary skill 1] and [primary skill 2].
Built [number] live projects including [one-line project description].
Targeting [role type] roles at [company type: product company / MNC / startup].

TECHNICAL SKILLS
Languages:     [Java / Python / JavaScript / C++]
Frameworks:    [Spring Boot / Django / React / Node.js]
Databases:     [MySQL / PostgreSQL / MongoDB]
Tools:         [Git, GitHub, VS Code, Postman, Docker]
Cloud:         [AWS / GCP / Azure — only if you have used them]

PROJECTS
[Project Name]                                           [GitHub URL]
[Problem statement in one line — what was broken or missing]
Built [what you built] using [tech stack]; achieved [measurable outcome].
[Metric if available: users, performance improvement, stars, scale]

[Project Name]                                           [GitHub URL]
[Problem → Action → Outcome in 2-3 bullets]

EDUCATION
[Degree, e.g. B.Tech in Computer Science]
[College Name], [City] | [Year of passing] | CGPA: [X.X/10]
Relevant coursework: [Data Structures, DBMS, OS, CN — pick 3-4 relevant]

CERTIFICATIONS
[Certification Name] | [Platform: AWS / Oracle / Google / Coursera] | [Year]
[Certification Name] | [Platform] | [Year]

-- Remove any section that is empty. One page total. --

Project Bullet Before vs After

Weak Most Freshers Submit This

Resume Screening Tool

Made a web application that helps recruiters screen resumes. Used Python and HTML. Worked in a team of 3.

Strong What Gets Shortlisted

Resume ATS Scorer — github.com/yourname/ats-scorer

Built a keyword-matching tool to score resumes against job descriptions; used Python/NLTK and Flask REST API. Tested with 500 resume-JD pairs. Accuracy: 84%. Used by 3 classmates during campus placement season.

What changes when you apply this: In the hiring cycle I was reviewing, a candidate from a Tier-3 college with no internship experience got shortlisted for a product company because their resume had two well-written GitHub projects and a summary that matched the JD. The recruiter flagged it in the discussion specifically because the project descriptions were outcome-focused and the links were live. College and CGPA were not the deciding factor.

Frequently Asked Questions

What is the best fresher resume format for tech jobs in 2026?

A reverse-chronological, single-column, one-page format is the correct choice. The section order should be: Summary, Skills, Projects, Education, Certifications. ATS parsers reject multi-column layouts, graphics, and tables. Use standard section headings and match keywords from the job description exactly. Save as .docx or a text-clean single-column PDF.

Does fresher resume format matter for ATS screening in India in 2026?

Yes, it is the primary filter. Most Indian tech companies, MNCs, and global product firms hiring in India use ATS tools including Workday, Greenhouse, and Taleo. A resume with columns, icons, or non-standard headings is parsed incorrectly and rejected before a human ever sees it. A plain, keyword-matched resume consistently scores higher and passes to human review.

What should a fresher put on a resume with no experience?

Projects are the direct replacement for work experience. Build 2-3 projects tied to your target role, host them on GitHub, and write each one using the Problem, Action, Outcome format. This is more valuable to a recruiter than ten certifications with no applied work. One live project with a working demo link outperforms three Udemy completion certificates in an ATS scan and in a recruiter's first pass.

How long should a fresher resume be in 2026?

One page. Always. In hiring discussions I have been part of, multi-page fresher resumes are almost never read past the first page. If you cannot fit your resume on one page, you are including irrelevant content. Remove hobbies, the objective statement, outdated school-level achievements, and any certification unrelated to the target role.

Should I use a creative Canva or Novoresume template as a fresher applying to tech companies?

No. Creative templates with two columns, skill bars, and icons fail ATS parsing. The parser reads left to right and mixes content from adjacent columns. Your name can end up merged with your skills section. Save the design for your portfolio site. Your resume needs to be ATS-readable first. A plain, well-structured resume with strong project bullets consistently outperforms a visually impressive one that gets filtered before a human sees it.

Action Checklist: Do This This Week

Collect 3 target JDs from LinkedIn or Naukri for the exact role you want. Copy every repeated technical keyword into a list.
Rebuild your Skills section to match those exact keywords verbatim. Group by category: Languages, Frameworks, Databases, Tools, Cloud.
Write or rewrite 2-3 project bullets in Problem, Action, Outcome format. Add GitHub or live demo links to every project.
Delete the Objective statement. Replace it with a 40-word targeted Summary: role target + primary skill + one proof point.
Convert to single-column format. If you are using a Canva or two-column template, switch to a plain single-column layout now.
Run through Jobscan or Resume Worded (free tier) against each JD you care about. Target a score above 75% before applying.
Cut to one page. Remove hobbies, outdated achievements, and certifications irrelevant to the target role.
Check that your LinkedIn URL and GitHub URL are active and match what is on your resume. Recruiters click these.

Want a Free Resume Review?

Drop a comment below with the word RESUME and I will share specific feedback on the most common mistake I see in fresher tech resumes right now. I read every comment.

RESUME

Chetan Yadav

Senior Oracle and Cloud DBA | 15+ years production experience | Oracle ACE Apprentice | LevelUp Careers

Chetan has reviewed hundreds of fresher profiles across multiple hiring cycles and has been part of hiring discussions at both large enterprises and growth-stage tech companies. He writes career guidance specifically for freshers and early-career professionals who are missing the direct, practitioner-level information that actually changes outcomes.

LinkedIn Telegram WhatsApp Channel

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

2026-05-11T11:00:00.009+05:30

MRP Process Not Running in Data Guard: Fix It Step-by-Step (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.

Figure 1: MRP Process Not Running in Oracle Data Guard, Root Causes, Decision Flow, Fix Commands and Verification Reference, Oracle 19c

📚 Table of Contents

What MRP Does and Why Its Absence Is Critical
Immediate Diagnosis: Confirm MRP Is Not Running
Cause 1: MRP Was Manually Cancelled
Cause 2: Missing Standby Redo Logs
Cause 3: Data Guard Broker Apply State Is OFF
Cause 4: Protection Mode Conflict
Cause 5: No Auto-Start After Standby Crash
Enable Parallel Apply for Faster Lag Recovery
Verify MRP Is Running and Apply Lag Is Clearing
Prevent MRP from Stopping Again
FAQ: MRP Process Not Running in Oracle Data Guard

1. What MRP Does and Why Its Absence Is Critical

The Managed Recovery Process (MRP0) is the Oracle background process on the standby database responsible for reading redo data from Standby Redo Logs and applying it to the standby datafiles. It is the engine that keeps the standby synchronised with the primary.

When MRP stops, the pipeline freezes. The RFS process may continue receiving redo from the primary and writing it to Standby Redo Logs, but nothing is being applied. The standby falls further behind with every committed transaction on the primary.

Component	Role	When MRP Stops
RFS (Remote File Server)	Receives redo from primary, writes to SRLs	Continues running, redo still arrives
MRP0 (Managed Recovery)	Reads SRLs, applies redo to datafiles	Stopped, redo not applied, lag grows
Apply Lag	Time between redo arrival and apply	Increases continuously until MRP restarts
Data Loss Risk	Redo not yet applied to standby	Equals current apply lag if primary fails

MRP Stopped vs Transport Lag:

When MRP is not running you will typically see apply lag growing while transport lag stays near zero. This is because RFS is still receiving redo (transport working) but nothing is being applied (MRP stopped). If both transport lag and apply lag are growing, the problem is in the network, not just MRP.

2. Immediate Diagnosis: Confirm MRP Is Not Running

Before applying any fix, run these three queries. The results tell you exactly which cause you are dealing with.

SQL + DGMGRL, 3-Query MRP Diagnosis

-- Query 1: Confirm MRP is not running (run on STANDBY)
-- If no rows returned for MRP0 = MRP is stopped
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;

-- Query 2: Check Standby Redo Logs (run on STANDBY)
-- No rows = SRLs missing = Cause 2
SELECT group#,
       thread#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- Query 3: Check apply and transport lag (run on STANDBY or PRIMARY)
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag', 'apply finish time')
ORDER  BY name;

-- DGMGRL: check broker apply state (run from any node)
-- dgmgrl /
-- SHOW DATABASE VERBOSE standby_db;
-- Look for: ApplyState = ON or OFF

How to Read Your Results:

No MRP0 row in v$managed_standby = Cause 1 or 5 (not started or crashed)
No rows in v$standby_log = Cause 2 (missing SRLs, fix first)
DGMGRL ApplyState = OFF = Cause 3 (broker controlling apply)
protection_level differs from protection_mode = Cause 4
Alert log shows MRP0 terminated = Cause 5 (post-crash)

3. Cause 1: MRP Was Manually Cancelled

Most Common The most frequent reason the MRP process is not running in Data Guard is manual cancellation. A DBA runs ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL to perform maintenance, apply an OS patch, or modify a standby parameter, and forgets to restart MRP afterwards.

SQL, Fix Cause 1, Restart MRP After Manual Cancellation

-- Run on STANDBY database

-- Recommended: real-time apply (requires SRLs to exist)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Alternative: archive-based apply (if SRLs are missing)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    DISCONNECT FROM SESSION;

-- Verify MRP started within 30 seconds
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%';
-- Expected: MRP0 with status = WAIT_FOR_LOG or APPLYING

In a recent 4.8 TB core banking environment I managed, MRP had been cancelled during an Oracle PSU patch cycle. The DBA completing the patch restarted the standby instance but did not restart MRP. The monitoring system detected the growing apply lag 47 minutes later. Restarting MRP with real-time apply cleared the lag to zero in 12 minutes using the default single-threaded apply. For faster recovery on larger lag, see Section 8 for parallel apply.

4. Cause 2: Missing Standby Redo Logs Prevent MRP from Starting

Silent Cause If v$standby_log returns no rows, Standby Redo Logs were never created on this standby. Without SRLs, the USING CURRENT LOGFILE option fails and MRP cannot perform real-time apply. In many configurations this prevents MRP from starting at all.

The confusing part: transport lag is zero (RFS is receiving redo fine) but apply lag grows because MRP cannot start. This pattern almost always means missing SRLs.

SQL, Fix Cause 2, Create Standby Redo Logs and Restart MRP

-- Step 1: Confirm SRLs are missing (run on STANDBY)
SELECT COUNT(*) AS srl_count FROM v$standby_log;
-- Result: 0 = SRLs missing, must create before restarting MRP

-- Step 2: Check online redo log size on PRIMARY
-- SRLs must match this size exactly
SELECT group#,
       members,
       bytes/1024/1024  AS size_mb,
       status
FROM   v$log
ORDER  BY group#;

-- Step 3: Create SRLs on STANDBY
-- Rule: same size as online redo logs
-- Rule: (groups_per_thread + 1) SRL groups per thread
-- Example: single-instance primary with 3 x 500MB redo groups
-- Needs 4 SRL groups (3 + 1)

ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 11 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 12 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 13 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 14 ('+DATA') SIZE 500M;

-- For 2-node RAC primary also add THREAD 2 groups 21-24

-- Step 4: Verify SRLs created
SELECT group#,
       thread#,
       bytes/1024/1024  AS size_mb,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- Step 5: Now restart MRP with real-time apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Step 6: Confirm MRP switched to real-time mode
SELECT process, status FROM v$managed_standby WHERE process = 'MRP0';
-- Expected: WAIT_FOR_LOG (not WAIT_FOR_GAP)

Production Incident: 8-Hour Apply Gap from Missing SRLs

A newly rebuilt standby database for a 2-node RAC primary showed zero transport lag but growing apply lag from the first day of operation. Investigation found that SRLs had never been created. MRP was running in archive-based apply mode, only catching up once per hour when archive logs were shipped. By the time the team noticed, the standby was 8 hours behind the primary. Creating SRLs and restarting with real-time apply brought the standby current within 15 minutes.

5. Cause 3: Data Guard Broker Apply State Is OFF

Broker Override When Data Guard Broker is enabled, it controls the apply state of the standby. If an administrator ran DGMGRL> EDIT DATABASE standby_db SET STATE='OFFLINE' or disabled the database in broker, apply is set to OFF. Running a direct SQL restart works temporarily, but broker cancels MRP again within minutes.

This is why some DBAs report that MRP restarts but stops again almost immediately. The broker is winning the battle. The fix must go through DGMGRL.

DGMGRL, Fix Cause 3, Re-Enable Apply via Data Guard Broker

-- Connect to Data Guard Broker (run on primary or standby server)
-- dgmgrl /

-- Step 1: Check current broker state
SHOW CONFIGURATION;
SHOW DATABASE VERBOSE standby_db;
-- Look for: ApplyState = OFF or State = OFFLINE

-- Step 2: Enable database if disabled
ENABLE DATABASE standby_db;

-- Step 3: Set apply state to ON
EDIT DATABASE standby_db SET STATE='APPLY-ON';

-- Step 4: Verify configuration is now healthy
SHOW CONFIGURATION;
-- Expected: SUCCESS with no ORA-16766

-- Step 5: Cross-check MRP on standby SQL
-- SELECT process, status FROM v$managed_standby
-- WHERE process LIKE 'MRP%';

When Broker Is Enabled, Always Fix Through DGMGRL

If dg_broker_start = TRUE in the standby spfile, the broker owns apply state management. A direct ALTER DATABASE RECOVER SQL command will start MRP, but broker will override and cancel it again at the next configuration sync cycle (typically within 1,5 minutes). Always check broker state before applying a direct SQL fix.

6. Cause 4: Protection Mode Conflict Causing MRP Abort

Silent Risk When the Data Guard configuration uses Maximum Protection mode, the primary requires confirmation from the standby for every redo write. If the standby connection becomes unstable or the network experiences sustained packet loss, Oracle may abort MRP to prevent data divergence between primary and standby.

SQL + DGMGRL, Fix Cause 4, Resolve Protection Mode Conflict

-- Step 1: Check effective protection on PRIMARY
SELECT protection_mode,
       protection_level    -- actual vs configured
FROM   v$database;
-- If they differ, primary silently fell back

-- Step 2: Check archive destination for errors on PRIMARY
SELECT dest_id,
       status,
       error,
       gap_status
FROM   v$archive_dest_status
WHERE  target    = 'STANDBY'
AND    status   != 'INACTIVE';

-- Step 3: Lower to Maximum Availability temporarily (dgmgrl /)
EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

-- Step 4: Restart MRP on STANDBY
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Step 5: Monitor stability, then restore original mode if needed
-- EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION;

7. Cause 5: MRP Did Not Auto-Start After Standby Crash

Post-Crash After a standby instance crash from OS reboot, power failure, or OOM kill, the standby database restarts but MRP does not start automatically unless broker or a startup trigger is configured. The standby opens in read-only or mount state with no apply running.

SQL, Fix Cause 5, Restart MRP + Create Auto-Start Trigger

-- Step 1: Verify standby state after crash (run on STANDBY)
SELECT status,
       database_role,
       open_mode
FROM   v$database;

-- Step 2: Check alert log for crash evidence (run on standby server)
-- adrci
-- adrci> SHOW ALERT -TAIL 200
-- Look for: ORA-03113, ORA-29701, or instance terminated messages

-- Step 3: Restart MRP immediately
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Step 4: Create auto-start trigger to prevent recurrence
-- Run on STANDBY database as SYSDBA
CREATE OR REPLACE TRIGGER start_mrp_on_open
    AFTER STARTUP ON DATABASE
DECLARE
    v_role   v$database.database_role%TYPE;
BEGIN
    SELECT database_role
    INTO   v_role
    FROM   v$database;

    IF v_role = 'PHYSICAL STANDBY' THEN
        EXECUTE IMMEDIATE
            'ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
             USING CURRENT LOGFILE DISCONNECT FROM SESSION';
    END IF;
EXCEPTION
    WHEN OTHERS THEN NULL;  -- Never block database startup
END;
/

-- Verify trigger created
SELECT trigger_name,
       status
FROM   dba_triggers
WHERE  trigger_name = 'START_MRP_ON_OPEN';

Broker Is Better Than the Trigger:

If you use Data Guard Broker, you do not need the startup trigger. Enable broker on the standby with dg_broker_start = TRUE in the spfile and ensure the database state is set to APPLY-ON in DGMGRL. Broker automatically restarts MRP after any standby restart. The trigger is only necessary in environments without broker configuration.

8. Enable Parallel Apply for Faster Lag Recovery

If MRP has been stopped for a long time and the standby has accumulated significant apply lag, single-threaded MRP will be slow to catch up. Enabling parallel apply uses multiple CPU cores to apply redo simultaneously, reducing catch-up time by 3,8x depending on the workload.

SQL, Enable Parallel Apply to Reduce Accumulated Lag Faster

-- Step 1: Cancel existing MRP if running
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- Confirm cancelled
SELECT process, status FROM v$managed_standby
WHERE  process LIKE 'MRP%';
-- Expected: No rows

-- Step 2: Restart with parallel apply
-- Set degree to half the standby CPU count as a starting point
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    PARALLEL 8
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Step 3: Verify parallel workers started
SELECT process,
       status,
       thread#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;
-- Expected: MRP0 + PR00 through PR07 (8 parallel workers)

-- Step 4: Monitor lag reduction rate
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag')
ORDER  BY name;
-- Run every 2 minutes to confirm lag is dropping

9. Verify MRP Is Running and Apply Lag Is Clearing

After applying any fix, run this complete verification sequence. Do not close the incident until all five checks pass.

SQL + DGMGRL, Complete Post-Fix Verification

-- Check 1: MRP is running (STANDBY)
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%';
-- Pass: MRP0 status = WAIT_FOR_LOG or APPLYING

-- Check 2: Apply lag dropping (STANDBY)
SELECT name,
       value
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag');
-- Pass: both values trending toward 0

-- Check 3: MRP in real-time mode (STANDBY)
SELECT process, status FROM v$managed_standby
WHERE  process = 'MRP0';
-- Pass: WAIT_FOR_LOG (not WAIT_FOR_GAP)

-- Check 4: Protection level matches mode (PRIMARY)
SELECT protection_mode, protection_level FROM v$database;
-- Pass: both values are identical

-- Check 5: No archive gap (PRIMARY)
SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;
-- Pass: no rows returned

-- Check 6: DGMGRL shows SUCCESS
-- dgmgrl /
-- SHOW CONFIGURATION;
-- Pass: Configuration Status = SUCCESS

10. Prevent MRP from Stopping Again

Configuration Hardening to Keep MRP Running

Standby Redo Logs created: same size as online redo logs, groups + 1 per thread
Data Guard Broker enabled with dg_broker_start = TRUE on standby spfile
Broker database state confirmed as APPLY-ON in DGMGRL
MRP startup trigger created (only if not using broker auto-restart)
Protection mode set to Maximum Availability, not Maximum Protection, unless mandated
Monitoring alert for zero MRP0 in v$managed_standby with 5-minute response SLA
Apply lag alert at 30-second threshold, not 5 minutes
DGMGRL VALIDATE DATABASE scheduled weekly

SQL, Proactive MRP Health Check Query (Run Every 5 Minutes)

-- MRP process health check (run on STANDBY)
SELECT CASE
           WHEN COUNT(*) = 0
           THEN 'CRITICAL: MRP not running, Data Guard apply stopped'
           ELSE 'OK: MRP is running'
       END  AS mrp_health_status,
       SYSDATE AS checked_at
FROM   v$managed_standby
WHERE  process = 'MRP0'
AND    status NOT IN ('IDLE');

-- Apply lag alert
SELECT name,
       value,
       CASE
           WHEN TO_DSINTERVAL(value) > INTERVAL '0 00:00:30' HOUR TO SECOND
           THEN 'ALERT: ' || name || ' exceeds threshold'
           ELSE 'OK'
       END  AS status
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag')
ORDER  BY name;

FAQ: MRP Process Not Running in Oracle Data Guard

Why is the MRP process not running in Oracle Data Guard?

The MRP process stops in Oracle Data Guard for five main reasons: manual cancellation during maintenance where the DBA forgets to restart it, missing Standby Redo Logs that prevent real-time apply from initialising, Data Guard Broker setting apply state to OFF, a protection mode conflict causing Oracle to abort MRP, or no auto-start configuration after a standby instance crash. Each cause requires a different fix command.

How do I restart the MRP process not running in Data Guard 19c?

Run on the standby: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; If using Broker run in DGMGRL: EDIT DATABASE standby_db SET STATE='APPLY-ON'; Verify with: SELECT process, status FROM v$managed_standby WHERE process='MRP0'; Status should show WAIT_FOR_LOG or APPLYING.

What is the difference between MRP not running and ORA-16766?

They describe the same condition. ORA-16766 is the Oracle error code that appears in DGMGRL SHOW CONFIGURATION when MRP is stopped. MRP not running is the technical description of the underlying cause. Both mean the Managed Recovery Process has stopped and redo is no longer being applied to the standby datafiles.

Why does MRP stop immediately after I restart it?

Recurring MRP stop after restart has three causes. First, Data Guard Broker has apply set to OFF and overrides your manual SQL restart within minutes, so fix through DGMGRL instead. Second, missing Standby Redo Logs cause MRP to fail on start immediately, so create SRLs first. Third, Maximum Protection mode with an unstable standby network connection causes repeated MRP abort, so lower to Maximum Availability until the network is stable.

How do I prevent MRP from stopping after a standby reboot?

Create an AFTER STARTUP database trigger on the standby that checks the database role and runs ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT. Alternatively, enable Data Guard Broker with dg_broker_start=TRUE in the standby spfile and confirm the broker state is APPLY-ON, which makes broker auto-restart MRP after any restart automatically.

Dealing with a different Data Guard issue?

Drop a comment with your exact symptom and I will help you diagnose the root cause.

Comment DG

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA, Oracle ACE Apprentice, with 15+ years of hands-on experience managing mission-critical production databases across finance, healthcare, and e-commerce sectors.

Chetan has resolved MRP stopped and ORA-16766 incidents across multiple production Oracle 19c environments, including RAC primaries with Active Data Guard standbys on dedicated WAN links. His writing focuses on exact diagnosis and exact fix commands backed by production experience.

This blog covers real-world DBA problems, cloud architecture, and practical learning, not theoretical documentation or vendor marketing.

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

2026-05-04T16:44:00.001+05:30

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.

Figure 1: ORA-16766 Complete Reference, Root Causes, Diagnosis Queries, Fix Commands, Quick Decision Flow and Scenario Reference Table for Oracle 19c Data Guard

📚 Table of Contents

What ORA-16766 Means and Why It Is Critical
Step 1: Immediate Diagnosis in DGMGRL and SQL
Root Cause 1: MRP Was Stopped or Never Started
Root Cause 2: Missing Standby Redo Logs
Root Cause 3: Data Guard Broker State Set to APPLY-OFF
Root Cause 4: Protection Mode Conflict
Root Cause 5: MRP Stopped After Standby Crash
Verify the Fix: Confirm ORA-16766 Is Resolved
Prevent ORA-16766 from Recurring
FAQ: ORA-16766 in Oracle Data Guard

1. What ORA-16766 Means and Why It Is Critical

ORA-16766: Redo Apply is stopped means the Managed Recovery Process (MRP0) on the standby database has terminated. No redo is being applied. The standby is frozen at the point MRP stopped.

While ORA-16766 is active, every transaction committed on the primary is at risk if the primary fails. The apply lag is your exposure window. A 2-hour apply lag when the primary fails means up to 2 hours of data loss.

State	What Is Happening	Data Loss Risk
MRP Running normally	Standby applies redo, lag near zero	Near zero (depends on protection mode)
ORA-16766 active	MRP stopped, standby frozen, lag growing	Equal to the current apply lag
ORA-16766 + no SRLs	MRP cannot start even if commanded	Growing every minute until fixed

Priority Level: Fix Immediately

ORA-16766 is not a warning to schedule for the next maintenance window. Every minute it remains unfixed is another minute of redo that the standby cannot apply. If the primary fails while ORA-16766 is active, you activate a standby that is not fully synchronised. Treat it as a P1 incident.

2. Step 1: Immediate Diagnosis in DGMGRL and SQL

Before applying any fix, run these diagnostic queries to identify the exact cause. Each cause has a different fix. Running the wrong command wastes time and can make things worse.

DGMGRL, Step 1 Diagnosis, Identify ORA-16766 Root Cause

-- DGMGRL Diagnosis (run from primary or standby server)
-- dgmgrl /

-- Step 1a: Full configuration status
SHOW CONFIGURATION;
-- Look for: ORA-16766 next to standby database name

-- Step 1b: Detailed standby database status
SHOW DATABASE VERBOSE standby_db;
-- Look for: ApplyState, LogXptStatus, StatusReport

-- Step 1c: Validate the standby
VALIDATE DATABASE standby_db;
-- SQL Diagnosis (run on STANDBY)

-- Step 2a: Check if MRP process is running
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;
-- If no rows = MRP not running = ORA-16766 confirmed

-- Step 2b: Check apply and transport lag
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag','apply lag','apply finish time')
ORDER  BY name;

-- Step 2c: Check Standby Redo Logs (missing = root cause)
SELECT group#,
       thread#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;
-- No rows = SRLs missing, MRP cannot do real-time apply

-- Step 2d: Check protection mode vs effective level (PRIMARY)
SELECT protection_mode,
       protection_level
FROM   v$database;
-- If they differ, primary fell back silently

Interpret Your Results:

No MRP0 in v$managed_standby = Root Cause 1 (MRP not started)
No rows in v$standby_log = Root Cause 2 (Missing SRLs)
DGMGRL ApplyState = OFF = Root Cause 3 (Broker disabled apply)
protection_level differs from protection_mode = Root Cause 4
Alert log shows MRP0 terminated after crash = Root Cause 5

3. Root Cause 1: MRP Was Stopped or Never Started

Most Common The standby is open but MRP was manually cancelled during maintenance, stopped by a network timeout, or was never started when the standby was first opened.

SQL, Fix Root Cause 1, Start or Restart MRP

-- Run on STANDBY database

-- Option A: Real-time apply (RECOMMENDED when SRLs exist)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Option B: Without real-time apply (if SRLs missing)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    DISCONNECT FROM SESSION;

-- Option C: With parallel apply for faster lag catch-up
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    PARALLEL 8
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Verify MRP started
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%';
-- Expected: MRP0 status = APPLYING or WAIT_FOR_LOG

In a 4.8 TB core banking RAC primary, ORA-16766 appeared after a maintenance window where MRP was cancelled to apply an OS patch and not restarted. Apply lag had grown to 2.4 hours by the time monitoring fired. Restarting with parallel apply degree 8 cleared the lag to zero in 18 minutes.

4. Root Cause 2: Missing Standby Redo Logs Prevent MRP from Starting

Silent Killer If v$standby_log returns no rows, SRLs were never created. Without SRLs, USING CURRENT LOGFILE cannot function and MRP cannot start real-time apply, triggering immediate ORA-16766.

SQL, Fix Root Cause 2, Create Missing Standby Redo Logs

-- Step 1: Check online redo log size on PRIMARY
SELECT group#,
       bytes/1024/1024  AS size_mb,
       status
FROM   v$log
ORDER  BY group#;

-- Step 2: Create SRLs on STANDBY (same size, groups+1 per thread)
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 11 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 12 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 13 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 14 ('+DATA') SIZE 500M;

-- Step 3: Verify SRLs created
SELECT group#, thread#, bytes/1024/1024 AS size_mb, status
FROM   v$standby_log ORDER BY thread#, group#;

-- Step 4: Restart MRP with real-time apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE DISCONNECT FROM SESSION;

-- Step 5: Confirm real-time mode
SELECT process, status FROM v$managed_standby WHERE process='MRP0';
-- Expected: WAIT_FOR_LOG (real-time) not WAIT_FOR_GAP

5. Root Cause 3: Data Guard Broker Set Apply State to OFF

Broker Managed If you manage Data Guard via DGMGRL, the broker controls apply state. Running direct ALTER DATABASE RECOVER SQL will work temporarily but broker will override it. Fix must go through DGMGRL.

DGMGRL, Fix Root Cause 3, Re-enable Apply via Broker

-- dgmgrl /

-- Check current apply state
SHOW DATABASE VERBOSE standby_db;
-- Look for: ApplyState = OFF

-- Enable the database if disabled
ENABLE DATABASE standby_db;

-- Set apply state to ON
EDIT DATABASE standby_db SET STATE='APPLY-ON';

-- Verify
SHOW CONFIGURATION;
-- Expected: SUCCESS, no ORA-16766

-- Cross-check on standby
SELECT process, status FROM v$managed_standby WHERE process LIKE 'MRP%';

Broker Overrides Direct SQL

When dg_broker_start = TRUE, broker manages apply state. If broker has apply set to OFF, it will cancel MRP again shortly after a direct SQL restart. Always fix ORA-16766 through DGMGRL when broker is enabled.

6. Root Cause 4: Protection Mode Conflict Causing MRP Abort

Silent Risk Maximum Protection mode with an unstable standby connection can cause Oracle to abort MRP to prevent divergence, triggering ORA-16766. Check if protection_level differs from protection_mode on the primary.

SQL + DGMGRL, Fix Root Cause 4, Resolve Protection Mode Conflict

-- Check on PRIMARY
SELECT protection_mode, protection_level FROM v$database;
-- If they differ, primary fell back silently

-- Check archive destination error
SELECT dest_id, status, error, gap_status
FROM   v$archive_dest_status
WHERE  target = 'STANDBY' AND status != 'INACTIVE';

-- Lower protection mode temporarily if needed (dgmgrl /)
EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

-- Restart MRP on STANDBY
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE DISCONNECT FROM SESSION;

-- Restore original mode once standby is stable
EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION;

7. Root Cause 5: MRP Stopped After Standby Instance Crash

Post-Crash After a standby OS reboot or crash, MRP does not automatically restart unless broker or a trigger is configured. Standby is open, ORA-16766 appears immediately.

SQL, Fix Root Cause 5, Post-Crash MRP Restart + Auto-Start Trigger

-- Verify standby state
SELECT status, database_role, open_mode FROM v$database;

-- Restart MRP
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE DISCONNECT FROM SESSION;

-- Prevent recurrence: auto-start trigger on standby
CREATE OR REPLACE TRIGGER start_mrp_on_open
    AFTER STARTUP ON DATABASE
DECLARE
    v_role  v$database.database_role%TYPE;
BEGIN
    SELECT database_role INTO v_role FROM v$database;
    IF v_role = 'PHYSICAL STANDBY' THEN
        EXECUTE IMMEDIATE
            'ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
             USING CURRENT LOGFILE DISCONNECT FROM SESSION';
    END IF;
EXCEPTION
    WHEN OTHERS THEN NULL;
END;
/

Broker Alternative: If Data Guard Broker is enabled, you do not need the trigger. Broker auto-restarts MRP after standby restart if state is APPLY-ON. Ensure dg_broker_start = TRUE in the standby spfile.

8. Verify the Fix: Confirm ORA-16766 Is Fully Resolved

SQL + DGMGRL, Complete Post-Fix Verification

-- 1. MRP running (STANDBY)
SELECT process, status, sequence# FROM v$managed_standby
WHERE  process LIKE 'MRP%';
-- Expected: MRP0 = WAIT_FOR_LOG or APPLYING

-- 2. Apply lag dropping to zero
SELECT name, value FROM v$dataguard_stats
WHERE  name IN ('transport lag','apply lag');

-- 3. Protection level matches mode (PRIMARY)
SELECT protection_mode, protection_level FROM v$database;

-- 4. DGMGRL shows SUCCESS
-- SHOW CONFIGURATION;

-- 5. No archive gap (PRIMARY)
SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;
-- Expected: No rows

Full Resolution Checklist:

DGMGRL shows SUCCESS. MRP0 status is WAIT_FOR_LOG or APPLYING. Apply lag dropping to zero. No rows in v$archive_gap. Protection level matches protection mode. All five = ORA-16766 fully resolved.

9. Prevent ORA-16766 from Recurring

Configuration Hardening Checklist

Standby Redo Logs created: same size as online redo logs, groups + 1 per thread
Data Guard Broker enabled with dg_broker_start = TRUE on both nodes
MRP startup trigger created on standby (if not using broker auto-restart)
Protection mode set to Maximum Availability unless Zero Data Loss is mandated
Monitoring alert for ORA-16766 in alert log with 5-minute response SLA
DGMGRL VALIDATE DATABASE run weekly
Apply lag alert threshold set at 30 seconds

SQL, Proactive ORA-16766 Detection (Run Every 5 Minutes)

-- MRP health check on STANDBY
SELECT CASE
           WHEN COUNT(*) = 0
           THEN 'ALERT: MRP not running — ORA-16766 likely'
           ELSE 'OK: MRP running'
       END  AS mrp_status
FROM   v$managed_standby
WHERE  process = 'MRP0'
AND    status NOT IN ('IDLE');

-- Apply lag alert
SELECT name,
       value,
       CASE
           WHEN TO_DSINTERVAL(value) > INTERVAL '0 00:00:30' HOUR TO SECOND
           THEN 'ALERT: ' || name || ' exceeds 30 seconds'
           ELSE 'OK'
       END  AS lag_status
FROM   v$dataguard_stats
WHERE  name IN ('transport lag','apply lag')
ORDER  BY name;

FAQ: ORA-16766 in Oracle Data Guard

What does ORA-16766 mean in Oracle Data Guard?

ORA-16766 means Redo Apply is stopped. The MRP0 process on the standby has terminated and no redo is being applied. The standby is frozen at the SCN when MRP stopped. It does not mean the standby is down or the network is broken, only that MRP has stopped.

How do I fix ORA-16766 in Oracle 19c Data Guard?

The fastest fix for most cases: on the standby run ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; If using Broker: DGMGRL> EDIT DATABASE standby_db SET STATE='APPLY-ON'; If MRP still does not start, check v$standby_log — if empty, create SRLs first.

Why does ORA-16766 keep coming back after restart?

Recurring ORA-16766 usually means: (1) Broker has apply set to OFF and keeps cancelling MRP — fix via DGMGRL. (2) Missing SRLs cause MRP to fail on start. (3) Maximum Protection mode with unstable standby connection causes repeated abort. Check which one applies using DGMGRL SHOW DATABASE VERBOSE.

Does ORA-16766 mean data loss has already occurred?

No. ORA-16766 means data loss has not yet occurred but the risk window is open. The standby is not applying redo, so if the primary fails, you lose redo generated since MRP stopped. Fix it immediately. Every minute of delay increases your exposure.

Can ORA-16766 appear while the standby is still receiving redo?

Yes. This is the missing SRL pattern. The RFS process receives and archives redo normally (transport lag = zero) but MRP cannot start real-time apply without SRLs. So the standby receives redo but apply lag grows and ORA-16766 appears in DGMGRL.

Dealing with a different Data Guard error?

Drop a comment with your exact error code and DGMGRL output. I will help you diagnose and fix it.

Comment DG

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on experience managing mission-critical production databases across finance, healthcare, and e-commerce sectors.

Chetan has resolved ORA-16766 and related Data Guard errors across multiple production RAC and single-instance environments. His writing focuses on exact diagnosis and exact fix commands, not generic advice.

This blog covers real-world DBA problems, cloud architecture, and practical learning, not theoretical documentation or vendor marketing.

Why You're Not Getting Interview Calls: Blind Applications vs Targeted Strategy

2026-04-30T14:38:00.003+05:30

Why You're Not Getting Interview Calls in 2026: Blind vs Targeted Job Search Strategy

Why You're Not Getting Interview Calls in 2026: Blind Applications vs Targeted Strategy

100 Applications. 0 Responses. Here Is Exactly Why, and How to Fix It.

📅30 April 2026

👤 Chetan Yadav, Senior Oracle & Cloud DBA

⏱️ 12 - 14 min read

⏱️ Estimated Reading Time: 12,14 minutes

Blind Applications, ATS Failures, No Referral Strategy, Quality vs Quantity, Targeted Job Search 2026

🎯 Who This Guide Is For

Final year students sending applications and hearing nothing back. Freshers who have applied to 80,200 jobs over several months with 0,2 responses. Anyone who has been told "just keep applying" without being told why their applications are failing and what to do differently.

If you are not getting interview calls despite sending dozens of applications, the problem is almost never your skills or your degree. Freshers not getting interview calls in 2026 is an epidemic, and the root cause is almost always the same: blind, untargeted applications that fail before any human ever reads them.

A student messaged me last month: "I have applied to 140 jobs in the last 3 months. I have received 2 responses and both were rejections. I have a decent GPA, a relevant degree, and I have been doing everything right. What am I missing?"

The answer was not what she expected. She was not missing skills. She was not missing certifications. She was applying to jobs the wrong way. Every application was a copy-paste of the same generic resume. No keyword matching. No company research. No follow-up. No referral outreach.

She was doing everything she had been told to do, and none of it was working because the advice she had been given was wrong. This guide explains the real reasons, and the exact targeted job search strategy that actually produces interview calls.

Figure 1: Blind vs Targeted Application Framework 2026 — 5 Real Reasons You Are Not Getting Calls and Quality vs Quantity comparison table

📚 Table of Contents

The Real Numbers: Why Blind Applications Fail
Reason 1: ATS Is Silently Rejecting Your Resume
Reason 2: Your Headline Signals You Are Not Worth Reading
Reason 3: You Have No Online Presence
Reason 4: You Are Targeting the Wrong Roles
Reason 5: You Have No Referral Strategy
The Targeted Application Framework: What to Do Instead
How to Ask for a Referral Without Being Awkward
The 10-Application Week: A Practical Schedule
FAQ: Why Am I Not Getting Interview Calls?

1. The Real Numbers: Why Blind Applications Fail

Most freshers believe job searching is a numbers game. Send more applications, get more responses. The data says the exact opposite.

Application Type	Volume	Callback Rate	Interview Rate
Blind (generic, mass)	100+ per month	1,2%	0.5%
Targeted (customised)	10,15 per week	10,15%	5,8%
Referred (employee referral)	5,10 per month	30,40%	15,20%

15x

A referred candidate is 15 times more likely to be hired than a cold applicant

If you spend 80% of your job search time sending cold applications and 0% building referral relationships, you are allocating your effort exactly backwards. The rest of this guide shows you how to flip that ratio.

BLIND APPROACH (What Most Freshers Do)

Send 100+ applications per month on job portals
Same generic resume for every single job
No company research before applying
Apply to jobs requiring 3,5 years experience
Never follow up after applying
Zero recruiter or alumni outreach
Result: 100 applications, 0,2 callbacks

TARGETED APPROACH (What Actually Works)

Apply to 10,15 carefully selected roles per week
Resume customised per role with JD keywords
Research company before applying (1 paragraph)
Only apply to roles matching 70%+ requirements
Follow up on LinkedIn 5 days after applying
Actively seek referrals from your network
Result: 15 applications, 3,5 interview calls

2. Reason 1: ATS Is Silently Rejecting Your Resume Before Any Human Sees It

Applicant Tracking Systems (ATS) scan your resume before any recruiter reads it. If your resume does not contain the right keywords in the right format, it is automatically filtered out.

Studies show that 75% of resumes are rejected by ATS before reaching a human. You are not getting ignored — you are being eliminated before the race even starts.

The 4 Ways Your Resume Fails ATS Right Now

Fail Wrong format: Two-column layouts, tables, text boxes, and graphics confuse ATS parsers which read strictly left to right
Fail Missing keywords: You wrote "database management" but the JD says "Oracle Database Administration" — ATS does not match approximate terms
Fail Wrong file type: Canva exports as a design file. ATS cannot parse design files reliably. Use PDF or DOCX only.
Fail Generic objective statement: "Seeking a challenging opportunity" contains zero searchable keywords and signals a copy-paste resume

I have reviewed over 200 resumes from freshers over the past 5 years. In at least 60% of cases, the resume would fail an ATS scan before any recruiter ever saw it — not because the candidate lacked skills, but because the format and keyword strategy were wrong. The fix takes less than 2 hours.

Checklist, ATS-Proof Resume Requirements

ATS RESUME CHECKLIST:

Format:
  Single column layout only (no tables, no text boxes)
  Font: Arial, Calibri, or Helvetica (10-12pt body)
  File: PDF or DOCX (check job posting requirement)
  Margins: 0.5 to 1 inch all sides
  Standard section headers: Experience, Education, Skills

Keywords:
  Copy exact phrases from job description into your resume
  Include both acronym and full term: SQL / Structured Query Language
  Job title in header must match the role you are applying for
  Skills section must mirror tools listed in the JD exactly

Test before submitting:
  Jobscan.co — paste JD + resume, target 75%+ match score
  Resume Worded — ATS compatibility check (free tier available)

Once your resume passes ATS, it reaches a recruiter. That is where the next filter kicks in — your headline.

3. Reason 2: Your LinkedIn Headline Signals You Are Not Worth Reading

Your LinkedIn headline and resume title are the first things every recruiter sees. If they signal nothing useful, the recruiter moves to the next candidate in under 3 seconds.

HEADLINES THAT GET IGNORED

"Fresher looking for job opportunities"

"Student at Mumbai University"

"B.Tech CSE Graduate 2025 Seeking Placement"

"Hardworking and dedicated professional"

HEADLINES THAT GET READ

"Aspiring Oracle DBA, SQL, Python, OCP Aspirant, Final Year CSE"

"Java Developer, Spring Boot, MySQL, 2 Projects Shipped, Open to Work"

"Data Analyst, Python, Power BI, SQL, Certified, Seeking Entry Role"

"Full Stack Developer, React, Node.js, 3 GitHub Projects, Available Now"

The formula is simple: Role + Core Skills + One Differentiator + Status.

Every word must be a keyword a recruiter would search for. "Fresher" and "seeking" are not searchable keywords. "Oracle DBA" and "SQL" are. Rewrite your headline today — it takes 5 minutes and immediately changes how you appear in recruiter searches.

Want a full LinkedIn profile optimisation guide?

Read: How to Build a Powerful LinkedIn Profile That Attracts Recruiters in 2026 — covers All-Star status, headline formula, About section, and the content strategy that keeps you visible week after week.

4. Reason 3: You Have No Online Presence and Recruiters Notice

When a recruiter sees your resume or LinkedIn profile, the first thing they do is Google your name or check your LinkedIn activity.

If they find nothing — a blank LinkedIn, no GitHub, no portfolio, no blog — it signals no initiative. In competitive fresher hiring, initiative is often the deciding factor.

What Recruiters Look for When They Google You

Good LinkedIn profile with posts showing technical interest or learning
Good GitHub with at least 2,3 real projects (not just tutorial follow-alongs)
Good A personal blog or technical article — even one well-written post counts
Good Participation in hackathons, open source, or technical communities
Red flag No LinkedIn activity in 6+ months
Red flag GitHub with 0 commits or only forked repositories
Red flag Social profiles showing unprofessional content

Build Minimum Online Presence in 2 Weekends:

Weekend 1: Update LinkedIn to All-Star status, write your About section, add your project as an Experience entry, connect with 50 classmates and professors.

Weekend 2: Build one small project relevant to your target role. Push it to GitHub with a proper README. Post one LinkedIn article about what you built and what you learned.

This takes 2 weekends. It changes how recruiters perceive you completely.

5. Reason 4: You Are Targeting the Wrong Roles and Wasting Every Application

This is one of the most common — and most demoralising — job search mistakes freshers make.

They apply to roles that say "entry level" but require 3,5 years of experience. The ATS filters them out in seconds. The application was wasted before it was submitted.

How to Identify Roles You Can Actually Get Shortlisted For

Rule Apply to roles where you match at least 70% of the listed requirements
Rule Target titles that say: Graduate Trainee, Junior, Associate, Entry Level, 0,2 Years
Rule Look for companies that run campus hiring or graduate programs — these are built for freshers
Rule Check if the company has hired freshers before by searching LinkedIn: company + "first job" or "joined as fresher"
Avoid Roles that say "5+ years required" regardless of how well you match the technical skills
Avoid Applying to 10 roles at the same company simultaneously — this flags your profile as spam

The 70% Rule in Practice:

A job description lists 10 requirements. You match 7 of them. Apply. You do not need to match 100%.

Hiring managers expect freshers to be trained on the remaining 30%. What they are looking for is proof you can learn, not proof you already know everything. A fresher who matches 7 out of 10 requirements and shows clear initiative will beat a candidate who matches 10 out of 10 on paper but shows no enthusiasm.

6. Reason 5: You Have No Referral Strategy and It Is Costing You Interviews

Most freshers never ask for referrals because it feels awkward. This is the single most expensive mistake in any job search.

Referrals are not nepotism. They are how most jobs are actually filled. A referral is not a guarantee of a job — it is a guarantee that your resume reaches a human being rather than an ATS filter.

Who Can Refer You Right Now

College seniors who graduated 1,3 years ago and are now at your target companies
Professors who have industry connections or run placement cells
LinkedIn connections who work at companies you are targeting
Relatives or family friends working in your target industry
People you met at webinars, events, or hackathons

Real Example: Referral vs Cold Application at the Same Company

Two freshers applied to the same junior DBA role at a mid-size IT company on the same day. Candidate A submitted through the careers portal with a strong, well-formatted resume.

Candidate B found a senior DBA at the company on LinkedIn, mentioned a specific blog post that DBA had written, asked one genuine technical question, built rapport over 10 days, then asked if they would be comfortable passing on their resume.

Candidate A heard nothing. Candidate B got an interview within 4 days. Same role. Same company. Same week. The difference was one LinkedIn message.

7. The Targeted Job Search Framework: Replace Blind Applications with This

Replace the blind application approach with this structured weekly framework. Ten to fifteen applications per week, every one of them deliberate.

Day	Activity	Time	Goal
Monday	Research 15 target companies, shortlist 3,5 open roles matching 70%+	1,2 hours	Build your weekly target list
Tuesday	Customise resume for each role (headline, skills, keywords per JD)	2,3 hours	3 ATS-optimised applications ready
Wednesday	Find LinkedIn connections at each target company. Send 3,5 personalised outreach messages	1 hour	Referral pipeline building
Thursday	Submit the 3 applications. Follow up on last week's applications via LinkedIn	1 hour	Applications submitted, follow-ups sent
Friday	Post one piece of content on LinkedIn (learning win, project update, or tip)	30 minutes	Profile visibility increased for the week
Weekend	Build or improve one project. Update GitHub. Engage with 10 posts in your domain	2,4 hours	Online presence strengthened

The difference between this and the blind approach is not the number of applications. It is the quality of intention behind each one. Every application in this framework has been researched, personalised, and followed up on.

8. How to Ask for a Referral Without Feeling Awkward

Most freshers avoid asking for referrals because they do not know how to do it without feeling like they are begging. Here is the exact three-step message structure that works.

Template, LinkedIn Referral Request — 3-Step Message Structure

STEP 1: Connect first — NOT a referral request yet
---
"Hi [Name], I came across your post about [specific topic they wrote about].
Really useful perspective on [one specific thing]. Would love to connect."
---

STEP 2: After they accept — start a genuine conversation (wait 3,5 days)
---
"Hi [Name], thanks for connecting. I noticed you work at [Company] as a
[Role]. I am currently a final year CSE student targeting [their domain].
I had a quick question about [specific technical thing in their work].
Do you have 2 minutes to share your perspective?"
---

STEP 3: After they respond — build rapport 1,2 weeks THEN ask
---
"Hi [Name], I have been applying to [Company] for the [Role Name] position.
I know referrals are entirely at your discretion and I completely understand
if it is not something you are comfortable with. If you feel my profile
is a fit after looking at it, I would really appreciate being referred.
Here is my LinkedIn: [URL]. No pressure at all if not."
---

Key rules:
- Never ask for a referral in your first message
- Always reference something specific about their work
- Make it genuinely easy for them to say no (this increases yes rate)
- Keep every message under 5 lines

I have personally used this exact 3-step approach to help 3 freshers I mentored get referral interviews at companies they cold-applied to 3 times without a response. In every case, the referral came from a connection who had never met the candidate in person. Relationship quality matters more than relationship depth.

9. The 10-Application Week: Your Practical Job Search Schedule

Before You Apply to Any Role This Week

LinkedIn profile updated to All-Star status
Base resume ATS-tested on Jobscan (target 75%+ match score)
GitHub has at least 1 project with a proper README file
Open to Work enabled on LinkedIn (private mode is fine)
Custom LinkedIn URL set: linkedin.com/in/yourname

For Each Application You Submit

You match at least 70% of the listed job requirements
Resume headline matches the exact job title in this specific posting
Skills section includes keywords copied from this specific JD
ATS score checked and above 70% on Jobscan
At least one person at the company identified for follow-up outreach
Calendar reminder set 5 days out to send a LinkedIn follow-up message

End of Week Review (15 minutes every Friday)

How many targeted applications submitted this week?
How many follow-up messages sent to last week's applications?
How many referral conversations started or progressed this week?
Did you post at least once on LinkedIn this week?
What is your callback rate so far? Target: 1 call per 10 targeted applications

FAQ: Why Am I Not Getting Interview Calls?

Why am I not getting interview calls despite applying to many jobs?

The most common reasons freshers are not getting interview calls are: your resume is being rejected by ATS before any human reads it (wrong format or missing keywords), you are applying to roles above your experience level, you are using the same generic resume for every job, and you have no follow-up or referral strategy. Fix one of these at a time, starting with ATS optimisation, and you will see a measurable improvement within 2,3 weeks.

How long should a targeted job search take before I get an interview?

With a genuinely targeted approach — 10 to 15 customised applications per week, LinkedIn outreach, and referral requests — most freshers in tech see their first interview within 3 to 6 weeks. If you are not getting any responses after 4 weeks of targeted applications, check three things: your resume ATS score (test it on Jobscan), whether you are applying to the right seniority level, and whether your target domain has active hiring in your location right now.

Is it okay to apply to the same company multiple times?

For different roles, yes, but space them out by at least 2 to 3 weeks. Applying to 5 roles at the same company in the same week flags your application as spam in their ATS. If you were rejected for a role, wait at least 3 to 6 months before applying again — unless you have built a genuine relationship with someone at the company who can refer you, in which case a referral overrides this concern.

What if I have no connections at any company I want to apply to?

Start building connections now, before you need them. Connect with college alumni who graduated 1 to 3 years before you and are now working in your target domain. These people remember what it was like to be in your position and are generally the most willing to help. Search LinkedIn for your college name plus your target company name. You will almost always find 2 to 3 alumni. Send a connection request with a personalised note mentioning your shared college. This is the fastest way to build a referral network from zero.

Should I apply even if I don't meet all the job requirements?

Yes, if you meet at least 70% of the requirements. Job descriptions are often written as a wish list, not a minimum specification. Hiring managers expect to train freshers on the remaining 30%. What they cannot train is initiative, attitude, and the ability to learn quickly — so show those through your projects, your LinkedIn activity, and your personalised application. A candidate matching 7 out of 10 requirements with clear enthusiasm will consistently beat a candidate matching 10 out of 10 with a generic application.

Are you stuck in the blind application cycle?

Drop a comment below with your situation — how many applications you have sent, what responses you have received, and what roles you are targeting. I will give you one specific, actionable fix based on your exact scenario.

Comment JOBS

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on production experience managing mission-critical databases across finance, healthcare, and e-commerce sectors.

Beyond technical work, he mentors freshers and early-career professionals through job searches, LinkedIn optimisation, and career transitions into cloud and database roles. He has reviewed hundreds of resumes and conducted technical interviews across multiple hiring cycles. His career advice is based on what actually produces results, not generic motivation.

This blog covers real-world DBA problems, cloud architecture, career growth, and practical learning — not theoretical documentation or vendor marketing.

How to Fix Data Guard Lag in Oracle 19c (6 Real Production Fixes with SQL)

2026-04-27T16:06:00.000+05:30

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

📅 27 April 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

In Oracle 19c environments, Data Guard lag is one of the most common production issues DBAs face. It is also one of the most stressful 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

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

1. Before You Start: Run These 4 Queries First

Do not start applying fixes before running diagnostics. Two minutes of diagnosis saves two hours of incorrect troubleshooting.

SQL, 4 Mandatory Diagnostic Queries (Run Before Anything Else)

-- QUERY 1: Identify lag type (run on PRIMARY)
-- This tells you which direction to go
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN (
    'transport lag',
    'apply lag',
    'apply finish time'
)
ORDER  BY name;

-- QUERY 2: Check Standby Redo Logs (run on STANDBY)
-- No rows = missing SRLs = most common cause of apply lag
SELECT group#,
       thread#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- QUERY 3: Check MRP parallel workers (run on STANDBY)
-- Only MRP0 with no PR* processes = parallel apply disabled
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;

-- QUERY 4: Check for archive gap (run on PRIMARY)
-- Any rows = URGENT, fix this before everything else
SELECT thread#,
       low_sequence#,
       high_sequence#
FROM   v$archive_gap
ORDER  BY thread#;

Read Query 4 Result First:

If Query 4 returns any rows, you have a sequence gap. This means the standby is missing archived redo logs and cannot apply continuously. Fix the gap by manually copying the missing archives from the primary before doing anything else. A sequence gap takes priority over every other fix.

2. Step 1: Check Transport Lag vs Apply Lag

Identify Which Type of Lag You Have

From Query 1 output:

Transport lag high Redo is not reaching the standby fast enough. Go to Step 4 (network) or check primary I/O.
Apply lag high, transport lag low Redo is arriving fine but MRP cannot apply it. Go to Step 2 (SRLs) then Step 3 (parallel apply).
Both high Check SRLs first (Step 2), then network (Step 4).

Query 1 Result	What It Means	Go To
transport lag: +00 05:00:00, apply lag: +00 00:10:00	Network or primary I/O problem	Step 4
transport lag: +00 00:00:00, apply lag: +02 00:00:00	MRP apply bottleneck	Step 2 then Step 3
transport lag: +00 01:00:00, apply lag: +01 00:00:00	Multiple issues	Step 2, then Step 3, then Step 4
Both show +00 00:00:00	Lag cleared or intermittent	Step 9 (verify and monitor)

3. Step 2: Fix Missing Standby Redo Logs

Check This First Missing Standby Redo Logs (SRLs) is the single most common cause of unexpectedly high apply lag in new or recently rebuilt Data Guard environments. Without SRLs, real-time apply cannot function. The standby only applies redo when archive logs are shipped, typically once per hour, creating a massive lag gap.

Diagnose and Fix Missing SRLs

SQL, Check and Create Standby Redo Logs

-- Step 2a: Check primary online redo log size (run on PRIMARY)
-- SRLs must match this exact size
SELECT group#,
       members,
       bytes/1024/1024  AS size_mb,
       status
FROM   v$log
ORDER  BY group#;

-- Step 2b: Check SRLs on standby (run on STANDBY)
-- If no rows returned = SRLs are missing
SELECT group#,
       thread#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- Step 2c: Create SRLs if missing (run on STANDBY)
-- Rules: same size as online redo logs
-- Need (online_log_groups_per_thread + 1) SRL groups per thread
-- Example: Primary has 3 redo groups per thread, 2 threads (RAC)
-- Need 4 SRL groups for thread 1, 4 for thread 2

-- For ASM storage (recommended):
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 11 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 12 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 13 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 14 ('+DATA') SIZE 500M;

-- For single-instance primary (only thread 1 needed):
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 11 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 12 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 13 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 14 ('+DATA') SIZE 500M;

-- Step 2d: Verify SRLs created and MRP switches to real-time apply
SELECT group#,
       thread#,
       bytes/1024/1024  AS size_mb,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- Check MRP switched to WAIT_FOR_LOG (real-time) not WAIT_FOR_GAP
SELECT process,
       status,
       sequence#
FROM   v$managed_standby
WHERE  process = 'MRP0';

Expected Result After Creating SRLs:

Within 2,5 minutes of creating SRLs, MRP status should change from WAIT_FOR_GAP to WAIT_FOR_LOG. Apply lag should begin dropping immediately and typically reaches under 60 seconds within 10,15 minutes if the only issue was missing SRLs. In one production environment, apply lag dropped from 8 hours to 42 seconds within 12 minutes of SRL creation.

4. Step 3: Enable Parallel Apply

If SRLs are present and correctly sized but apply lag is still growing, the MRP process is the bottleneck. By default, MRP is single-threaded. Enabling parallel apply allows MRP to use multiple CPU cores to apply redo simultaneously, increasing apply throughput by 3,8x on most workloads.

Enable Parallel Apply on the Standby

SQL, Enable Parallel Apply and Verify

-- Step 3a: Check current apply mode (run on STANDBY)
-- If only MRP0 shown and no PR* processes = single-threaded
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;

-- Step 3b: Stop current MRP (run on STANDBY)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- Verify MRP stopped
SELECT process, status
FROM   v$managed_standby
WHERE  process LIKE 'MRP%';

-- Step 3c: Restart with parallel apply
-- Set PARALLEL to match standby CPU count (start with CPU_count/2)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    PARALLEL 8
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Step 3d: Verify parallel workers started
-- Should see MRP0 + PR00, PR01, PR02... workers
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;

-- Step 3e: Monitor apply lag after enabling parallel apply
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag')
ORDER  BY name;

How Many Parallel Apply Workers to Set?

Start with half your standby CPU count. For an 8-CPU standby, start with PARALLEL 4. Monitor apply lag and CPU usage. If apply lag is still growing and CPU has headroom, increase to PARALLEL 8. Do not set parallel degree higher than CPU count. If the standby runs Active Data Guard (read workload), leave at least 25% CPU for read sessions.

5. Step 4: Fix Network Latency and Bandwidth

If transport lag is high and apply lag is low, the problem is between the primary and the standby. The redo is being generated but not arriving fast enough.

Reduce Redo Transport Bandwidth Usage

SQL, Enable Redo Log Compression and Fix Transport Config

-- Step 4a: Check current transport configuration (run on PRIMARY)
SELECT dest_id,
       dest_name,
       status,
       affirm,
       compression,
       net_timeout,
       async_blocks,
       error
FROM   v$archive_dest
WHERE  target  = 'STANDBY'
AND    status  = 'VALID';

-- Step 4b: Enable compression on redo transport (run on PRIMARY)
-- Reduces bandwidth by 30-70% at cost of CPU on both sides
ALTER SYSTEM SET log_archive_dest_2 =
    'SERVICE=standby_db
      SYNC
      AFFIRM
      COMPRESSION=ENABLE
      NET_TIMEOUT=30
      VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
      DB_UNIQUE_NAME=standby_db'
SCOPE=BOTH SID='*';

-- Step 4c: Verify compression is now enabled
SELECT dest_id,
       compression,
       status,
       error
FROM   v$archive_dest
WHERE  target = 'STANDBY'
AND    status = 'VALID';

-- Step 4d: Check current network write latency
SELECT dest_id,
       srl_network_writes,
       ROUND(srl_network_write_time /
             NULLIF(srl_network_writes,0), 3)  AS avg_network_write_ms
FROM   v$standby_log_stats
ORDER  BY dest_id;

-- OS level network test (run from primary server shell)
-- ping -c 50 standby_host_ip
-- iperf3 -c standby_host_ip -t 30 -P 4

6. Step 5: Resolve RMAN vs MRP I/O Conflict

A very common but often overlooked cause of apply lag spikes: RMAN backup running on the standby at the same time as peak MRP apply activity. Both compete for the same disk I/O. RMAN is aggressive by default and can starve MRP of the I/O it needs.

Fix RMAN and MRP I/O Conflict

SQL, Detect and Fix RMAN vs MRP I/O Conflict

-- Step 5a: Check if RMAN is running during lag spike (run on STANDBY)
SELECT session_key,
       input_type,
       status,
       TO_CHAR(start_time, 'YYYY-MM-DD HH24:MI')  AS start_time,
       TO_CHAR(end_time,   'YYYY-MM-DD HH24:MI')  AS end_time,
       input_bytes_display,
       output_bytes_display
FROM   v$rman_backup_job_details
WHERE  start_time > SYSDATE - 2
ORDER  BY start_time DESC;

-- Step 5b: Check datafile I/O latency on standby
-- High write time during backup = RMAN starving MRP
SELECT d.name,
       ROUND(f.writetim / NULLIF(f.phywrts,0), 2)  AS avg_write_ms,
       f.phyrds,
       f.phywrts
FROM   v$filestat  f
JOIN   v$datafile  d ON f.file# = d.file#
WHERE  f.phywrts   > 1000
ORDER  BY avg_write_ms DESC
FETCH FIRST 10 ROWS ONLY;

-- Step 5c: Throttle RMAN to protect MRP I/O (run on STANDBY)
-- Connect RMAN and set channel throttle:
-- RMAN> RUN {
--   ALLOCATE CHANNEL c1 DEVICE TYPE DISK
--       RATE 100M;   -- limit to 100MB/sec
--   BACKUP DATABASE;
-- }

-- Step 5d: Use DBMS_SCHEDULER to move backup to off-peak window
-- Check current backup schedule
SELECT job_name,
       enabled,
       next_run_date,
       last_start_date
FROM   dba_scheduler_jobs
WHERE  job_name LIKE '%RMAN%'
OR     job_name LIKE '%BACKUP%'
ORDER  BY next_run_date;

7. Step 6: Fix Protection Mode Mismatch

A silent lag builder. The protection mode shown in v$database has two columns: protection_mode (what you configured) and protection_level (what is actually in effect). If the standby was temporarily unreachable, the primary may have silently fallen back to a lower level. This can cause steady, unexplained lag accumulation.

SQL, Check and Restore Protection Mode

-- Check effective protection mode (run on PRIMARY)
-- If these two values differ, primary fell back silently
SELECT name,
       db_unique_name,
       protection_mode,    -- what you configured
       protection_level    -- what is actually active
FROM   v$database;

-- Check archive destination status for errors
SELECT dest_id,
       status,
       error,
       gap_status,
       db_unique_name
FROM   v$archive_dest_status
WHERE  target    = 'STANDBY'
AND    status   != 'INACTIVE';

-- Restore protection mode via DGMGRL (after standby reconnects)
-- dgmgrl /
-- DGMGRL> SHOW CONFIGURATION;
-- DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
-- DGMGRL> SHOW CONFIGURATION;

-- Verify protection_level now matches protection_mode
SELECT protection_mode,
       protection_level
FROM   v$database;

8. Fix for Active Data Guard (ADG) Apply Lag

If your standby runs Active Data Guard (open read-only while applying), read queries from reporting users compete with MRP for I/O. During heavy reporting workloads, MRP can be starved of I/O and apply lag grows even when all other configuration is correct.

SQL, Protect MRP from ADG Read Workload Using I/O Resource Manager

-- Check open mode on standby
SELECT open_mode,
       database_role
FROM   v$database;

-- Monitor MRP vs read session I/O competition
SELECT s.program,
       s.status,
       COUNT(*)  AS sessions
FROM   v$session s
WHERE  s.type = 'USER'
OR     s.program LIKE '%MRP%'
GROUP  BY s.program, s.status
ORDER  BY sessions DESC
FETCH FIRST 10 ROWS ONLY;

-- Apply lag while ADG read load active
SELECT name, value
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag');

-- Create I/O Resource Manager plan to protect MRP (run on STANDBY)
BEGIN
    DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
    DBMS_RESOURCE_MANAGER.CREATE_PLAN(
        plan    => 'STANDBY_IO_PLAN',
        comment => 'Protect MRP apply from ADG read workload'
    );
    DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
        plan             => 'STANDBY_IO_PLAN',
        group_or_subplan => '_ORACLE_BACKGROUND_GROUP_',
        comment          => 'MRP gets priority I/O',
        mgmt_p1          => 80
    );
    DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

ALTER SYSTEM SET resource_manager_plan = 'STANDBY_IO_PLAN'
SCOPE = BOTH SID = '*';

9. After the Fix: Verify and Monitor

After applying any fix, do not assume the problem is resolved. Monitor lag for at least 30 minutes under production load before declaring the incident closed.

SQL, Post-Fix Verification Queries

-- Run this every 5 minutes after the fix (run on PRIMARY)
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN (
    'transport lag',
    'apply lag',
    'apply finish time'
)
ORDER  BY name;

-- Confirm no sequence gaps (run on PRIMARY)
SELECT thread#,
       low_sequence#,
       high_sequence#
FROM   v$archive_gap;

-- Confirm MRP running in real-time mode (run on STANDBY)
-- Status must be WAIT_FOR_LOG not WAIT_FOR_GAP
SELECT process,
       status,
       sequence#,
       delay_mins
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;

-- Full DGMGRL health check
-- dgmgrl /
-- DGMGRL> SHOW CONFIGURATION;
-- DGMGRL> VALIDATE DATABASE VERBOSE standby_db;

10. Prevent Lag From Returning: Configuration Checklist

SRL and Transport Configuration

Standby Redo Logs created with same size as online redo logs
SRL count = online redo log groups per thread + 1 per thread
MRP status shows WAIT_FOR_LOG (real-time apply active)
COMPRESSION=ENABLE set in LOG_ARCHIVE_DEST if WAN bandwidth is a concern
NET_TIMEOUT set appropriately for WAN latency (30,60 seconds)

Apply Performance

Parallel apply enabled with degree matching standby CPU count
RMAN backup scheduled outside peak MRP apply window
Standby hardware sized equal to or greater than primary
Dedicated I/O path for standby datafiles (not shared with backup)
I/O Resource Manager plan active if ADG read workload is present

Monitoring

Automated alert when transport lag exceeds 30 seconds
Automated alert when apply lag exceeds 2 minutes
Archive gap check runs every 15 minutes
DGMGRL VALIDATE DATABASE runs weekly
Failover tested under production load every quarter

FAQ

Can I create SRLs without stopping the standby database?

Yes. You can add Standby Redo Log groups to a mounted or open standby database without any downtime. The ALTER DATABASE ADD STANDBY LOGFILE command runs online. MRP does not need to be stopped. After creating SRLs, MRP automatically detects them and switches to real-time apply mode. You should verify the switch by checking that MRP status changes from WAIT_FOR_GAP to WAIT_FOR_LOG within a few minutes.

Will enabling parallel apply cause any data consistency risk?

No. Oracle's parallel apply mechanism uses the same redo-based recovery infrastructure as single-threaded MRP. Oracle guarantees transactional consistency regardless of the parallel degree. Redo records within the same transaction are always applied in the correct order. The only consideration is that enabling parallel apply requires briefly cancelling and restarting MRP, which causes a few seconds of apply pause. During that pause, apply lag may increase slightly before recovering.

How do I fix a sequence gap in Data Guard?

A sequence gap means the standby is missing one or more archived redo log files and cannot apply continuously. First run SELECT * FROM v$archive_gap on the primary to identify the missing sequence numbers. Then manually copy the corresponding archive log files from the primary to the standby using RMAN or OS copy, register them on the standby with ALTER DATABASE REGISTER LOGFILE, and verify MRP resumes applying. If the gap is very old and the archive logs no longer exist on the primary, you may need to rebuild the standby using RMAN active duplication.

Transport lag is zero but apply lag keeps growing slowly every day. Why?

Slow, steady apply lag growth with zero transport lag almost always points to one of three causes: (1) parallel apply is not enabled and MRP is falling behind a high-volume OLTP workload, (2) RMAN backup is running daily and competing with MRP during peak hours, or (3) Active Data Guard read workload is starving MRP I/O. Run the MRP parallel worker check (Query 3) and the RMAN schedule check (Step 5) to identify which one is active in your environment.

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on experience managing production databases across on-premises, hybrid, and cloud environments.

Chetan has resolved Data Guard lag incidents across financial and healthcare production environments, including the 8-hour apply lag from missing SRLs and the firewall-induced transport spike described in related guides. His writing focuses on precise diagnosis and exact resolution commands, not generic advice.

This blog focuses on real-world DBA problems, career growth, and practical learning, not theoretical documentation or vendor marketing.

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

2026-04-21T13:48:00.001+05:30

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

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.

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

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

1. Before You Start: Run These 4 Queries First

Do not start applying fixes before running diagnostics. Two minutes of diagnosis saves two hours of incorrect troubleshooting.

SQL, 4 Mandatory Diagnostic Queries (Run Before Anything Else)

-- QUERY 1: Identify lag type (run on PRIMARY)
-- This tells you which direction to go
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN (
    'transport lag',
    'apply lag',
    'apply finish time'
)
ORDER  BY name;

-- QUERY 2: Check Standby Redo Logs (run on STANDBY)
-- No rows = missing SRLs = most common cause of apply lag
SELECT group#,
       thread#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- QUERY 3: Check MRP parallel workers (run on STANDBY)
-- Only MRP0 with no PR* processes = parallel apply disabled
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;

-- QUERY 4: Check for archive gap (run on PRIMARY)
-- Any rows = URGENT, fix this before everything else
SELECT thread#,
       low_sequence#,
       high_sequence#
FROM   v$archive_gap
ORDER  BY thread#;

2. Step 1: Check Transport Lag vs Apply Lag

Identify Which Type of Lag You Have

From Query 1 output:

Transport lag high Redo is not reaching the standby fast enough. Go to Step 4 (network) or check primary I/O.
Apply lag high, transport lag low Redo is arriving fine but MRP cannot apply it. Go to Step 2 (SRLs) then Step 3 (parallel apply).
Both high Check SRLs first (Step 2), then network (Step 4).

Query 1 Result	What It Means	Go To
transport lag: +00 05:00:00, apply lag: +00 00:10:00	Network or primary I/O problem	Step 4
transport lag: +00 00:00:00, apply lag: +02 00:00:00	MRP apply bottleneck	Step 2 then Step 3
transport lag: +00 01:00:00, apply lag: +01 00:00:00	Multiple issues	Step 2, then Step 3, then Step 4
Both show +00 00:00:00	Lag cleared or intermittent	Step 9 (verify and monitor)

3. Step 2: Fix Missing Standby Redo Logs

Diagnose and Fix Missing SRLs

SQL, Check and Create Standby Redo Logs

-- Step 2a: Check primary online redo log size (run on PRIMARY)
-- SRLs must match this exact size
SELECT group#,
       members,
       bytes/1024/1024  AS size_mb,
       status
FROM   v$log
ORDER  BY group#;

-- Step 2b: Check SRLs on standby (run on STANDBY)
-- If no rows returned = SRLs are missing
SELECT group#,
       thread#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- Step 2c: Create SRLs if missing (run on STANDBY)
-- Rules: same size as online redo logs
-- Need (online_log_groups_per_thread + 1) SRL groups per thread
-- Example: Primary has 3 redo groups per thread, 2 threads (RAC)
-- Need 4 SRL groups for thread 1, 4 for thread 2

-- For ASM storage (recommended):
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 11 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 12 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 13 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 14 ('+DATA') SIZE 500M;

-- For single-instance primary (only thread 1 needed):
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 11 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 12 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 13 ('+DATA') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 14 ('+DATA') SIZE 500M;

-- Step 2d: Verify SRLs created and MRP switches to real-time apply
SELECT group#,
       thread#,
       bytes/1024/1024  AS size_mb,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- Check MRP switched to WAIT_FOR_LOG (real-time) not WAIT_FOR_GAP
SELECT process,
       status,
       sequence#
FROM   v$managed_standby
WHERE  process = 'MRP0';

4. Step 3: Enable Parallel Apply

Enable Parallel Apply on the Standby

SQL, Enable Parallel Apply and Verify

-- Step 3a: Check current apply mode (run on STANDBY)
-- If only MRP0 shown and no PR* processes = single-threaded
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;

-- Step 3b: Stop current MRP (run on STANDBY)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- Verify MRP stopped
SELECT process, status
FROM   v$managed_standby
WHERE  process LIKE 'MRP%';

-- Step 3c: Restart with parallel apply
-- Set PARALLEL to match standby CPU count (start with CPU_count/2)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    PARALLEL 8
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Step 3d: Verify parallel workers started
-- Should see MRP0 + PR00, PR01, PR02... workers
SELECT process,
       status,
       thread#,
       sequence#
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;

-- Step 3e: Monitor apply lag after enabling parallel apply
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag')
ORDER  BY name;

5. Step 4: Fix Network Latency and Bandwidth

If transport lag is high and apply lag is low, the problem is between the primary and the standby. The redo is being generated but not arriving fast enough.

Reduce Redo Transport Bandwidth Usage

SQL, Enable Redo Log Compression and Fix Transport Config

-- Step 4a: Check current transport configuration (run on PRIMARY)
SELECT dest_id,
       dest_name,
       status,
       affirm,
       compression,
       net_timeout,
       async_blocks,
       error
FROM   v$archive_dest
WHERE  target  = 'STANDBY'
AND    status  = 'VALID';

-- Step 4b: Enable compression on redo transport (run on PRIMARY)
-- Reduces bandwidth by 30-70% at cost of CPU on both sides
ALTER SYSTEM SET log_archive_dest_2 =
    'SERVICE=standby_db
      SYNC
      AFFIRM
      COMPRESSION=ENABLE
      NET_TIMEOUT=30
      VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
      DB_UNIQUE_NAME=standby_db'
SCOPE=BOTH SID='*';

-- Step 4c: Verify compression is now enabled
SELECT dest_id,
       compression,
       status,
       error
FROM   v$archive_dest
WHERE  target = 'STANDBY'
AND    status = 'VALID';

-- Step 4d: Check current network write latency
SELECT dest_id,
       srl_network_writes,
       ROUND(srl_network_write_time /
             NULLIF(srl_network_writes,0), 3)  AS avg_network_write_ms
FROM   v$standby_log_stats
ORDER  BY dest_id;

-- OS level network test (run from primary server shell)
-- ping -c 50 standby_host_ip
-- iperf3 -c standby_host_ip -t 30 -P 4

6. Step 5: Resolve RMAN vs MRP I/O Conflict

Fix RMAN and MRP I/O Conflict

SQL, Detect and Fix RMAN vs MRP I/O Conflict

-- Step 5a: Check if RMAN is running during lag spike (run on STANDBY)
SELECT session_key,
       input_type,
       status,
       TO_CHAR(start_time, 'YYYY-MM-DD HH24:MI')  AS start_time,
       TO_CHAR(end_time,   'YYYY-MM-DD HH24:MI')  AS end_time,
       input_bytes_display,
       output_bytes_display
FROM   v$rman_backup_job_details
WHERE  start_time > SYSDATE - 2
ORDER  BY start_time DESC;

-- Step 5b: Check datafile I/O latency on standby
-- High write time during backup = RMAN starving MRP
SELECT d.name,
       ROUND(f.writetim / NULLIF(f.phywrts,0), 2)  AS avg_write_ms,
       f.phyrds,
       f.phywrts
FROM   v$filestat  f
JOIN   v$datafile  d ON f.file# = d.file#
WHERE  f.phywrts   > 1000
ORDER  BY avg_write_ms DESC
FETCH FIRST 10 ROWS ONLY;

-- Step 5c: Throttle RMAN to protect MRP I/O (run on STANDBY)
-- Connect RMAN and set channel throttle:
-- RMAN> RUN {
--   ALLOCATE CHANNEL c1 DEVICE TYPE DISK
--       RATE 100M;   -- limit to 100MB/sec
--   BACKUP DATABASE;
-- }

-- Step 5d: Use DBMS_SCHEDULER to move backup to off-peak window
-- Check current backup schedule
SELECT job_name,
       enabled,
       next_run_date,
       last_start_date
FROM   dba_scheduler_jobs
WHERE  job_name LIKE '%RMAN%'
OR     job_name LIKE '%BACKUP%'
ORDER  BY next_run_date;

7. Step 6: Fix Protection Mode Mismatch

SQL, Check and Restore Protection Mode

-- Check effective protection mode (run on PRIMARY)
-- If these two values differ, primary fell back silently
SELECT name,
       db_unique_name,
       protection_mode,    -- what you configured
       protection_level    -- what is actually active
FROM   v$database;

-- Check archive destination status for errors
SELECT dest_id,
       status,
       error,
       gap_status,
       db_unique_name
FROM   v$archive_dest_status
WHERE  target    = 'STANDBY'
AND    status   != 'INACTIVE';

-- Restore protection mode via DGMGRL (after standby reconnects)
-- dgmgrl /
-- DGMGRL> SHOW CONFIGURATION;
-- DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
-- DGMGRL> SHOW CONFIGURATION;

-- Verify protection_level now matches protection_mode
SELECT protection_mode,
       protection_level
FROM   v$database;

8. Fix for Active Data Guard (ADG) Apply Lag

SQL, Protect MRP from ADG Read Workload Using I/O Resource Manager

-- Check open mode on standby
SELECT open_mode,
       database_role
FROM   v$database;

-- Monitor MRP vs read session I/O competition
SELECT s.program,
       s.status,
       COUNT(*)  AS sessions
FROM   v$session s
WHERE  s.type = 'USER'
OR     s.program LIKE '%MRP%'
GROUP  BY s.program, s.status
ORDER  BY sessions DESC
FETCH FIRST 10 ROWS ONLY;

-- Apply lag while ADG read load active
SELECT name, value
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag');

-- Create I/O Resource Manager plan to protect MRP (run on STANDBY)
BEGIN
    DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
    DBMS_RESOURCE_MANAGER.CREATE_PLAN(
        plan    => 'STANDBY_IO_PLAN',
        comment => 'Protect MRP apply from ADG read workload'
    );
    DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
        plan             => 'STANDBY_IO_PLAN',
        group_or_subplan => '_ORACLE_BACKGROUND_GROUP_',
        comment          => 'MRP gets priority I/O',
        mgmt_p1          => 80
    );
    DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

ALTER SYSTEM SET resource_manager_plan = 'STANDBY_IO_PLAN'
SCOPE = BOTH SID = '*';

9. After the Fix: Verify and Monitor

After applying any fix, do not assume the problem is resolved. Monitor lag for at least 30 minutes under production load before declaring the incident closed.

SQL, Post-Fix Verification Queries

-- Run this every 5 minutes after the fix (run on PRIMARY)
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN (
    'transport lag',
    'apply lag',
    'apply finish time'
)
ORDER  BY name;

-- Confirm no sequence gaps (run on PRIMARY)
SELECT thread#,
       low_sequence#,
       high_sequence#
FROM   v$archive_gap;

-- Confirm MRP running in real-time mode (run on STANDBY)
-- Status must be WAIT_FOR_LOG not WAIT_FOR_GAP
SELECT process,
       status,
       sequence#,
       delay_mins
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'PR%'
ORDER  BY process;

-- Full DGMGRL health check
-- dgmgrl /
-- DGMGRL> SHOW CONFIGURATION;
-- DGMGRL> VALIDATE DATABASE VERBOSE standby_db;

10. Prevent Lag From Returning: Configuration Checklist

SRL and Transport Configuration

Standby Redo Logs created with same size as online redo logs
SRL count = online redo log groups per thread + 1 per thread
MRP status shows WAIT_FOR_LOG (real-time apply active)
COMPRESSION=ENABLE set in LOG_ARCHIVE_DEST if WAN bandwidth is a concern
NET_TIMEOUT set appropriately for WAN latency (30,60 seconds)

Apply Performance

Parallel apply enabled with degree matching standby CPU count
RMAN backup scheduled outside peak MRP apply window
Standby hardware sized equal to or greater than primary
Dedicated I/O path for standby datafiles (not shared with backup)
I/O Resource Manager plan active if ADG read workload is present

Monitoring

Automated alert when transport lag exceeds 30 seconds
Automated alert when apply lag exceeds 2 minutes
Archive gap check runs every 15 minutes
DGMGRL VALIDATE DATABASE runs weekly
Failover tested under production load every quarter

FAQ

Can I create SRLs without stopping the standby database?

Will enabling parallel apply cause any data consistency risk?

How do I fix a sequence gap in Data Guard?

Transport lag is zero but apply lag keeps growing slowly every day. Why?

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on experience managing production databases across on-premises, hybrid, and cloud environments.

This blog focuses on real-world DBA problems, career growth, and practical learning, not theoretical documentation or vendor marketing.

How to Build a Powerful LinkedIn Profile That Attracts Recruiters in 2026

2026-04-09T14:46:00.002+05:30

How to Build a Powerful LinkedIn Profile That Attracts Recruiters in 2026

Weak Profiles Get Ignored. Here Is the Exact Framework to Get Found.

9 April 2026

Chetan Yadav, Senior Oracle & Cloud DBA

⏱️ 12 - 13 min read

⏱️ Estimated Reading Time: 12 - 13 minutes

All-Star Status, Headline Formula, About Section, Experience Bullets, Skills Strategy, Content Plan

 Who This Guide Is For

Final year students building their LinkedIn for the first time, freshers who have a profile but get zero recruiter messages, working professionals who set up LinkedIn years ago and never touched it since, and anyone who has been told "just be on LinkedIn" without being told what that actually means.

I know freshers who applied to 80 jobs on Naukri and got 2 interviews. I know other freshers who optimised their LinkedIn profile over one weekend and received 6 recruiter messages within 3 weeks without applying to a single job. The difference was not their skills, their college, or their GPA. The difference was visibility.

LinkedIn is not a digital version of your resume. It is a search engine for talent. Recruiters run Boolean searches with specific keywords, filter by location, experience level, and skills, and contact candidates who match. If your profile does not contain the right words in the right places, you are invisible, no matter how qualified you are.

This guide covers the exact framework to build a LinkedIn profile that attracts recruiters in 2026: every section, every formula, every mistake to avoid, and a content strategy to keep your visibility growing week after week.

 Table of Contents

How LinkedIn Recruiter Search Actually Works
All-Star Profile Status: Why It Matters
Section 1: Profile Photo and Banner
Section 2: Headline (The Most Important Line)
Section 3: About Section (Your Personal Story)
Section 4: Experience (Show Impact, Not Duties)
Section 5: Skills and Endorsements
Education, Certifications and Projects
LinkedIn Content Strategy: How to Stay Visible
The 10 Mistakes That Keep You Invisible
LinkedIn Profile for Freshers with No Experience
Before You Hit Publish: Final Checklist
FAQ

1. How LinkedIn Recruiter Search Actually Works

Recruiters do not browse LinkedIn profiles randomly. They use LinkedIn Recruiter, a paid search tool, to run structured searches. They type keywords, set filters, and LinkedIn returns a ranked list of matching profiles. Your profile either appears in that list or it does not.

Recruiter Filter	Where It Reads on Your Profile	Your Action
Job title / Keywords	Headline, About section, Experience titles	Use exact industry keywords in all three places
Skills	Skills section (top 3 pinned skills ranked highest)	Add 50 skills, pin your most relevant 3
Location	Your profile location field	Set to your target city, not your hometown if different
Years of experience	Calculated from your Experience section dates	Ensure all experience entries have accurate dates
Education	Education section degree and institution	Add full degree name, not just abbreviation
Open to Work	Open to Work setting (public or private)	Enable it, even privately (only visible to recruiters)
Profile completeness	All-Star status indicator	Complete every section to reach All-Star level

The Algorithm Reality:

LinkedIn's algorithm ranks profiles in search results partly based on your Social Selling Index (SSI) score, your connection proximity to the searcher, and your profile completeness. A complete All-Star profile with regular activity ranks significantly higher than an incomplete profile with the same skills. You can check your own SSI score at linkedin.com/sales/ssi. Target 70+ out of 100.

2. All-Star Profile Status: Why It Matters

LinkedIn rates your profile strength on a scale: Beginner, Intermediate, Advanced, Expert, and All-Star. All-Star is not just a label. LinkedIn's own data shows All-Star profiles receive 40 times more recruiter views than incomplete profiles. Reaching All-Star is the single highest-impact action you can take in the first 30 minutes of optimising your profile.

The 7 Requirements for All-Star Status

Profile photo uploaded (any photo clears this requirement)
Custom headline written (not just your job title)
About section written (minimum 50 words)
At least one experience entry added with description
At least 5 skills added to your Skills section
Education entry added (degree, institution, year)
50 or more connections on your profile

Fresher with zero work experience:

You can still reach All-Star status. Add your college as an experience entry with a description of what you studied and built. Add your final year project as an experience entry. Add 5+ skills (SQL, Python, Communication, Problem Solving, any tools you used). Connect with 50 classmates, professors, and family members. The system does not check the quality of your content for All-Star, only that the sections are filled.

3. Section 1: Profile Photo and Banner

Your profile photo is the first thing every recruiter, hiring manager, and connection sees. It creates an impression before they read a single word. A professional photo increases profile views by up to 14 times compared to no photo.

Profile Photo Rules

Rule Your face should fill roughly 60% of the frame
Rule Plain or blurred background (avoid busy backgrounds)
Rule Look at the camera, natural smile
Rule Professional or smart-casual clothing appropriate for your industry
Avoid Group photos where you are cropped out of
Avoid Sunglasses, filters, or heavily edited images
Avoid Photos from weddings, trips, or parties

Banner Image

The banner is the large image behind your profile photo. Most people leave it as the default grey. A custom banner makes your profile look intentional and professional. Use Canva (free) to create a 1584 x 396 px banner. Include your name, title, and 2,3 key skills or a simple professional background relevant to your field.

Free Photo Without a Professional Shoot:

You do not need a professional photographer. Use your phone, natural light from a window, ask a friend to take 20 shots, and pick the best one. Wear a plain solid-colour top, stand in front of a plain wall, and shoot in portrait orientation. Free tools like remove.bg can clean up the background. This takes 15 minutes and costs nothing.

4. Section 2: Headline (The Most Important Line)

Your headline appears in every search result, every post comment, every connection request, and every InMail preview. It is the most-read line on your entire profile. Yet most people waste it by writing only their job title.

Headline Formula

Template, LinkedIn Headline Formula and Examples

Formula:  [Role / Domain] | [Key Skill 1] | [Key Skill 2] | [Value or Result]

Examples by profile type:

Fresher (Tech):
"Aspiring Oracle DBA | SQL, PL/SQL, Python | Final Year CSE | OCP Certified"

Fresher (Any):
"Final Year Computer Science Student | Java, Python, MySQL | Seeking SDE Role"

Mid-level Professional:
"Senior Oracle DBA | RAC, Data Guard, OCI | 8 Years OLTP Production Experience"

Career Changer:
"Java Developer transitioning to Cloud | AWS, OCI, Python | 5 Years Dev Experience"

Freelancer:
"Freelance Database Consultant | Oracle 19c, PostgreSQL | Remote | Open to Projects"

Rules:
- Max 220 characters (LinkedIn limit)
- Use pipe ( | ) to separate sections for readability
- Include your top searchable keywords
- Never write: Seeking opportunities / Fresher / Looking for job
- Always write: what you DO, not what you WANT

WEAK HEADLINE (Invisible)

"Student at Mumbai University"

"Fresher looking for job opportunities in IT sector"

"Software Engineer"

STRONG HEADLINE (Gets Found)

5. Section 3: About Section (Your Personal Story)

The About section is where you tell your story. It is the only place on LinkedIn where you can write in your own voice, explain your journey, show your personality, and give someone a reason to reach out to you.

Template, LinkedIn About Section (5-Paragraph Framework)

Paragraph 1 - Who You Are (2-3 lines):
"I am a final year Computer Science student at Mumbai University
with a deep interest in database systems, cloud infrastructure, and
backend development. I have been building with Oracle and Python for
the last 2 years."

Paragraph 2 - What You Do / Your Skills (2-3 lines):
"My technical focus is Oracle Database administration, SQL optimisation,
and PL/SQL development. I am also exploring cloud platforms including
OCI and AWS, working toward my OCP certification."

Paragraph 3 - Your Biggest Achievement or Project (2-3 lines):
"My final year project was an automated Oracle DBA monitoring dashboard
built with Python and Telegram Bot API that reduced manual health check
time from 45 minutes to under 3 minutes per shift."

Paragraph 4 - What You Are Building Toward (1-2 lines):
"I am looking to join a team where I can contribute as a junior DBA or
backend developer while continuing to grow in cloud database architecture."

Paragraph 5 - Call to Action (1 line):
"If you work in databases, cloud, or backend engineering, I would love
to connect. Feel free to message me directly."

Do Write in first person: "I am" not "He is" or "Chetan is"
Do End with a clear call to action (what you want people to do)
Do Include your top 5,8 keywords naturally within the text
Avoid Copying your resume summary word for word
Avoid Starting with "I am a hardworking professional seeking..."
Avoid Leaving it blank (this alone disqualifies you from All-Star)

6. Section 4: Experience (Show Impact, Not Duties)

The same rule that applies to your resume applies here with one difference: LinkedIn experience entries can be longer, can include media (project links, screenshots, documents), and are indexed by LinkedIn's search algorithm for keywords.

Template, LinkedIn Experience Entry with Impact Bullets

SENIOR ORACLE DBA
TechCorp Financial Services, Mumbai
Mar 2021 to Present, Full-time

Managed 4-node Oracle 19c RAC cluster on OCI serving 2,400 TPS OLTP
workload for core banking transaction processing system.

Key Achievements:
, Reduced planned downtime from 8 hours to under 30 seconds per quarter
  by implementing Data Guard Maximum Availability with Fast-Start Failover.

, Tuned 47 high-impact SQL queries through AWR analysis, reducing
  peak-hour CPU utilisation from 94% to 61%.

, Automated RMAN backup validation using PL/SQL and Shell scripts,
  cutting backup verification time from 4 hours to 22 minutes.

, Migrated 8.2 TB Oracle database to OCI Autonomous Database with
  zero data loss using GoldenGate replication.

Technologies: Oracle 19c, RAC, Data Guard, RMAN, GoldenGate, OCI, PL/SQL, AWR

Tip Add the Technologies line at the bottom of each experience entry. This is read by LinkedIn's search algorithm and dramatically increases keyword matching in recruiter searches.

7. Section 5: Skills and Endorsements

LinkedIn allows up to 50 skills. Most people add 10 and leave it. Using all 50 dramatically increases the number of recruiter searches your profile appears in.

Skills Strategy

Rule Add all 50 skills. Think: technical tools, programming languages, platforms, soft skills, domain knowledge
Rule Pin your top 3 skills (the ones most relevant to your target role)
Rule Include both the acronym and the full term where relevant
Tip Look at job descriptions for your target role and add every skill they mention that you actually have
Tip Ask 5 colleagues, classmates, or professors to endorse your top 3 skills. Endorsements increase your credibility in search results

Template, 50 Skills List for an Oracle DBA / Database Engineer Profile

Technical Skills (add these to your profile):
Oracle Database, Oracle 19c, Oracle 23ai, SQL, PL/SQL, Oracle RAC,
Oracle Data Guard, Oracle GoldenGate, RMAN, ASM, Oracle Exadata,
Oracle Autonomous Database, OCI (Oracle Cloud Infrastructure),
MySQL, PostgreSQL, MongoDB, NoSQL, AWS RDS, Azure SQL Database,
Performance Tuning, AWR, ASH, SQL Monitor, Execution Plans,
Index Optimization, Query Optimization, Database Migration,
High Availability, Disaster Recovery, Backup and Recovery,
Shell Scripting, Bash, Python, Git, Jenkins, Terraform, Ansible,
Oracle Linux, RHEL, Linux Administration, Database Security,
Data Modeling, ETL, Data Warehousing, Database Architecture,
Cloud Migration, DevOps, CI/CD, JIRA, Confluence, Agile

8. Education, Certifications and Projects

For freshers, the Education and Projects sections are your most important proof of capability. Do not treat them as an afterthought.

Add your degree with the full degree name (Bachelor of Technology in Computer Science Engineering, not just B.Tech)
Add your final year project as a separate experience entry with a description, tech stack, and outcomes
Add certifications as individual entries in the Licenses and Certifications section with the issuing organisation and credential ID
Add relevant courses (Oracle Academy, Coursera, NPTEL) in the Courses section
If you have a GitHub profile, add the link in the Featured section

9. LinkedIn Content Strategy: How to Stay Visible

A complete profile gets you into search results. Consistent content activity keeps you at the top of those results and builds inbound visibility over time. LinkedIn's algorithm heavily rewards regular posting from accounts that generate engagement.

What to Post (Even as a Fresher)

Content Type	Example	Frequency
Learning wins	"Passed my Oracle OCP exam today after 3 months of preparation. Here is what actually helped."	Every achievement
Technical tips	"One AWR query that tells you more than 10 minutes of investigation. Here it is."	1,2 per week
Project showcase	"Built an automated database monitoring dashboard this weekend. Here is what it does."	Every project
Lessons learned	"I made this mistake in my interview last week. Here is what I should have said."	Monthly
Career milestones	"Today is my first day as a junior DBA. Here is what I am looking forward to learning."	Every milestone
Industry observations	"Every DBA job posting I have seen this week asks for OCI experience. Here is my learning plan."	Weekly

The 5-Comment Rule:

Before posting your own content, spend 10 minutes commenting genuinely on 5 posts from people in your target industry. Thoughtful comments (not just "Great post!") increase your profile visibility to the post author's network and signal to LinkedIn's algorithm that you are an active participant. Consistent commenting builds relationships faster than any other LinkedIn activity.

10. The 10 Mistakes That Keep You Invisible

Mistake	Why It Hurts	Fix
No profile photo	14x fewer profile views than with a photo	Upload any professional photo today
Default grey banner	Looks abandoned and inactive	Create a custom banner on Canva in 15 minutes
Job title only in headline	Not searchable, no differentiation	Use Role + Skills + Keywords formula
Empty About section	No story, no reason to connect	Write 5-paragraph About using the template above
Fewer than 10 skills	Missing from many recruiter skill filters	Add all 50 skills immediately
Duties not achievements	Indistinguishable from every other candidate	Rewrite every bullet with Action + Result + Number
Under 50 connections	Profile ranked lower in search results	Connect with classmates, professors, colleagues
Open to Work disabled	Recruiters cannot prioritise your profile	Enable Open to Work (privately if needed)
No activity for months	Algorithm deprioritises inactive profiles	Post or comment at least 3 times per week
No custom URL	Generic URL looks unprofessional in resume	Set custom URL: linkedin.com/in/yourname

11. LinkedIn Profile for Freshers with No Experience

Not having work experience does not mean having nothing to show. Recruiters hiring freshers are not looking for work history. They are looking for proof that you can learn, build, and communicate. Here is how to demonstrate that.

What Freshers Can Add Instead of Work Experience

Final year project as an Experience entry (company = your university, title = Project Lead)
Internships (even 1 month, even unpaid, add all of them)
Freelance or volunteer work (any technical work counts)
Open source contributions (link to GitHub)
Hackathon participation and results
Personal projects (apps, scripts, dashboards, anything you built)
Course projects from Coursera, NPTEL, Oracle Academy
Technical blog posts or articles (add to Featured section)
Leadership roles in college clubs or technical committees

Real Example, Fresher Who Got 6 Recruiter Messages in 3 Weeks:

A final year student in Pune had zero work experience. Over one weekend he: updated his photo and banner, rewrote his headline with keywords, wrote a 4-paragraph About section, added his final year project as an experience entry with 4 impact bullets, added 40+ skills, connected with 80 classmates and professors, and posted one article about what he learned building his project.

Within 3 weeks: 6 recruiter messages for junior developer and DBA trainee roles. Nothing changed about his actual skills. Everything changed about his visibility.

12. Before You Hit Publish: Final Checklist

Profile Completeness

Professional profile photo uploaded
Custom banner image (not the default grey)
Headline uses Role + Skills + Keywords formula
About section written (minimum 150 words, ends with CTA)
All experience entries have impact bullets with numbers
Education section complete with full degree name
At least 40 skills added, top 3 pinned
All-Star profile status achieved

Visibility Settings

Open to Work enabled (private or public)
Custom LinkedIn URL set (linkedin.com/in/yourname)
Profile visibility set to public (not just connections)
Location set to target city or "Open to Remote"
Creator mode enabled if you plan to post content regularly

Ongoing Actions (Week 1 After Optimising)

Connect with 50+ people (classmates, professors, ex-colleagues)
Post your first piece of content (learning win or project showcase)
Comment on 5 posts per day for the first week
Follow 10 companies you want to work for
Check your SSI score at linkedin.com/sales/ssi
Ask 3 people to endorse your top skills

FAQ

How long does it take to start getting recruiter messages after optimising?

Most people see an increase in profile views within 48,72 hours of completing their profile to All-Star status. Recruiter messages typically start within 1,3 weeks if your skills match active hiring needs in your location and domain. The timeline varies by how competitive your target role is. For in-demand technical roles (cloud, data, DevOps) in major cities, well-optimised profiles often get contacted within a week. For more niche roles, it may take longer but inbound will still grow significantly.

Should I connect with strangers or only people I know?

Connect strategically beyond people you know personally. Send connection requests with a brief personalised note to: recruiters at companies you want to work for, senior professionals in your target domain, alumni from your college in relevant roles, speakers at conferences or events you attended virtually, and authors of content you genuinely found useful. A short personalised note ("I read your post about Oracle performance tuning and found it really helpful") converts at 3,4x the rate of a blank connection request.

Should I use LinkedIn Premium?

LinkedIn Premium Career (the job seeker tier) is worth it for 1,2 months while you are actively job searching. The key benefits are InMail credits to contact recruiters directly, visibility into who viewed your profile, and the "Featured Applicant" badge that makes your application stand out. However, a free All-Star profile with consistent content activity will outperform a Premium account that is incomplete and inactive. Optimise first, then consider Premium if you are actively applying.

Comment PROFILE below for a personalised LinkedIn tip.

Drop a comment with PROFILE and share your current headline or the role you are targeting. I will give you one specific, actionable improvement for your LinkedIn profile based on your situation. I read every comment.

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on experience. Beyond technical work, he mentors early-career professionals through job searches, LinkedIn optimisation, and career transitions into cloud and database engineering roles.

Chetan has helped dozens of freshers and junior professionals transform their LinkedIn presence from invisible to actively receiving recruiter outreach. His career content focuses on practical, specific actions that produce measurable results, not generic motivation.

This blog covers real-world DBA problems, cloud architecture, career growth, and practical learning, not theoretical documentation or vendor marketing.

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

2026-04-06T12:27:00.001+05:30

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.

 Table of Contents

Transport Lag vs Apply Lag: The Critical Distinction
Five Diagnostic Queries to Run First
Cause 1: Primary Storage I/O Pressure
Cause 2: Redo Volume Spike from Batch Jobs
Cause 3: Network Latency and Bandwidth
Cause 4: Misconfiguration (The Silent Killer)
Cause 5: MRP Apply Bottleneck
Cause 6: Standby Resource Starvation
SYNC vs ASYNC: Which Mode Creates Which Lag Pattern
Lag Under Active Data Guard (ADG Read Workload)
Proactive Lag Monitoring
FAQ
Related Reading

1. Transport Lag vs Apply Lag: The Critical Distinction

Before diagnosing lag, identify which type you have. They look identical on a dashboard but live in completely different parts of the pipeline.

Lag Type	Definition	Location	Root Cause Area
Transport Lag	Redo generated on primary but not yet received by standby	Network pipe between sites	Network, primary I/O, redo volume
Apply Lag	Redo received by standby but not yet applied to datafiles	Standby MRP apply process	Standby I/O, CPU, misconfiguration

The Fastest Diagnosis Rule:

High transport lag, low apply lag: Network or primary is the problem. The standby applies everything it receives, it just is not receiving fast enough.

Low transport lag, high apply lag: Standby is the problem. Redo arrives quickly but MRP cannot keep up.

Both high: Multiple problems, or a redo volume spike overwhelming the entire pipeline.

2. Five Diagnostic Queries to Run First

Run these immediately when lag is reported. They tell you which cause category you are dealing with before you go deeper.

SQL, Five Immediate Diagnostic Queries for Data Guard Lag

-- 1. Transport lag vs apply lag (run on PRIMARY)
SELECT name,
       value,
       unit,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN (
    'transport lag',
    'apply lag',
    'apply finish time',
    'estimated startup time'
)
ORDER  BY name;

-- 2. Current redo generation rate MB/sec (run on PRIMARY)
SELECT inst_id,
       ROUND(value / 1024 / 1024, 2)  AS redo_mb_total
FROM   gv$sysstat
WHERE  name = 'redo size'
ORDER  BY inst_id;

-- 3. Archive destination status and error (run on PRIMARY)
SELECT dest_id,
       status,
       target,
       destination,
       error,
       gap_status
FROM   v$archive_dest_status
WHERE  status != 'INACTIVE'
ORDER  BY dest_id;

-- 4. MRP apply process status (run on STANDBY)
SELECT process,
       status,
       thread#,
       sequence#,
       block#,
       blocks,
       delay_mins
FROM   v$managed_standby
ORDER  BY process;

-- 5. Archive gap detection (run on PRIMARY)
-- Any rows returned = serious problem, act immediately
SELECT thread#,
       low_sequence#,
       high_sequence#
FROM   v$archive_gap
ORDER  BY thread#;

3. Cause 1: Primary Storage I/O Pressure

Cause 1 LGWR cannot write redo to local online redo logs fast enough. In SYNC mode this directly delays the network send to the standby. In ASYNC mode it slows redo generation and eventually fills the NSA send buffer.

SQL, Diagnose Primary Storage I/O as Lag Root Cause

-- LGWR wait events (run on PRIMARY)
-- High log file parallel write = primary disk problem
SELECT event,
       total_waits,
       ROUND(average_wait, 3)  AS avg_wait_ms,
       wait_class
FROM   v$system_event
WHERE  event IN (
    'log file sync',
    'log file parallel write',
    'log buffer space'
)
ORDER  BY time_waited DESC;

-- Datafile write latency (DBWR pressure on LGWR)
SELECT d.name,
       ROUND(f.writetim / NULLIF(f.phywrts, 0), 2)  AS avg_write_ms,
       f.phywrts
FROM   v$filestat  f
JOIN   v$datafile  d ON f.file# = d.file#
WHERE  f.phywrts > 1000
ORDER  BY avg_write_ms DESC
FETCH FIRST 10 ROWS ONLY;

-- Check ASM rebalance (can throttle I/O on primary)
SELECT group_number,
       operation,
       state,
       power,
       est_minutes
FROM   v$asm_operation;

Fix Move redo log files to dedicated fast storage (NVMe or dedicated ASM disk group). Increase redo log size to reduce switch frequency. Schedule ASM rebalance outside peak hours.

4. Cause 2: Redo Volume Spike from Batch Jobs

Cause 2 A batch job, bulk load, or mass update pushes 10,50x the normal redo rate. The network pipe cannot keep up. Transport lag grows rapidly. This is the most common cause of sudden lag spikes in OLTP systems with nightly batch processing.

SQL, Identify Redo Volume Spike and Source

-- Archive log generation rate per hour (run on PRIMARY)
-- Sudden spike = redo volume surge
SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24')  AS hour,
       COUNT(*)                                  AS logs_generated,
       ROUND(SUM(blocks * block_size)/1024/1024) AS total_mb
FROM   v$archived_log
WHERE  first_time     > SYSDATE - 1
AND    standby_dest   = 'NO'
GROUP  BY TO_CHAR(first_time, 'YYYY-MM-DD HH24')
ORDER  BY hour DESC;

-- Top SQL generating most redo (run on PRIMARY)
SELECT sql_id,
       executions,
       ROUND(buffer_gets / 1024.0, 0)   AS buffer_gets_k,
       last_active_time,
       SUBSTR(sql_text, 1, 80)          AS sql_preview
FROM   v$sql
WHERE  executions > 0
ORDER  BY buffer_gets DESC
FETCH FIRST 20 ROWS ONLY;

Fix Use NOLOGGING or APPEND hints for bulk data loads where tolerable. Schedule batch jobs during off-peak hours. Enable redo log compression on the archive destination (COMPRESSION=ENABLE in LOG_ARCHIVE_DEST).

5. Cause 3: Network Latency and Bandwidth

Cause 3 The most commonly blamed cause and the most commonly misdiagnosed. Network problems cause transport lag only. If apply lag is high and transport lag is low, stop looking at the network.

Metric	Good Value	Problem Threshold	Impact
Round-trip latency (RTT)	< 2 ms	> 5 ms for SYNC	Every commit waits RTT in SYNC mode
Bandwidth utilisation	< 60%	> 80% sustained	Redo bursts cause queuing delay
Packet loss	0%	> 0.01%	TCP retransmit multiplies latency
Jitter	< 1 ms	> 5 ms	Unpredictable LGWR stalls in SYNC mode

SQL, Diagnose Network as Data Guard Lag Cause

-- Redo transport network write statistics (run on PRIMARY)
SELECT dest_id,
       srl_network_writes,
       ROUND(srl_network_write_time /
             NULLIF(srl_network_writes, 0), 3)  AS avg_network_write_ms
FROM   v$standby_log_stats
ORDER  BY dest_id;

-- NSS/NSA send process status (run on PRIMARY)
SELECT process,
       status,
       client_process,
       sequence#,
       delay_mins
FROM   v$managed_standby
WHERE  process LIKE 'NS%'
ORDER  BY process;

-- Archive destination error (run on PRIMARY)
SELECT dest_id,
       status,
       error,
       gap_status,
       db_unique_name
FROM   v$archive_dest_status
WHERE  target    = 'STANDBY'
AND    status   != 'INACTIVE';

Incident: Firewall Stateful Inspection Causing Transport Lag Spikes

A correctly configured Data Guard environment with 1.8 ms RTT had transport lag spike to 120+ seconds randomly, then clear, then spike again. Network team confirmed zero packet loss. Root cause: a next-gen firewall performing deep packet inspection on the redo transport TCP stream. Each 10-second idle gap caused the firewall to drop and re-establish the TCP state table entry, causing a 15,30 second reconnect delay on the NSS process.

Fix: Added a firewall bypass rule for the specific TCP port used by Data Guard redo transport. Lag spikes disappeared immediately.

Fix Add COMPRESSION=ENABLE to LOG_ARCHIVE_DEST_2 to reduce bandwidth by 50,70%. Implement QoS tagging for redo transport traffic. Increase NET_TIMEOUT if packet loss causes premature timeouts. Use a dedicated WAN link for redo transport, never share with application traffic.

6. Cause 4: Misconfiguration (The Silent Killer)

Cause 4 Configuration errors are silent lag causes. No errors in the alert log. No network problems. Reasonable redo rate. But lag slowly accumulates because something is set up wrong. These are the hardest to find.

SQL, Verify Data Guard Configuration for Common Misconfigurations

-- Check 1: Standby Redo Logs exist and are correct size
-- SRL must match online redo log size
-- Need at least (online_log_groups + 1) SRL per thread
SELECT group#,
       thread#,
       sequence#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- Check 2: AFFIRM setting matches intended protection mode
SELECT dest_id,
       dest_name,
       affirm,
       net_timeout,
       compression,
       status
FROM   v$archive_dest
WHERE  target  = 'STANDBY'
AND    status  = 'VALID';

-- Check 3: Real-time apply is running (not archive-based)
-- Status must be WAIT_FOR_LOG not WAIT_FOR_GAP
SELECT process,
       status,
       sequence#
FROM   v$managed_standby
WHERE  process = 'MRP0';

-- Check 4: Protection mode matches protection level
-- If they differ, primary has silently fallen back
SELECT protection_mode,    -- configured mode
       protection_level    -- actual effective mode
FROM   v$database;

Incident: Missing Standby Redo Logs, 8-Hour Apply Gap

A newly built Data Guard environment appeared healthy. Alert log clean. No errors. Archive destination showed SUCCESS. But during failover testing the standby was 8 hours behind the primary despite a low-latency WAN link.

Root cause: Standby Redo Logs had never been created. Without SRLs, real-time apply cannot function. MRP was waiting for archived logs to be shipped rather than receiving redo in real time, meaning the standby only caught up once per hour during log archival.

Fix: Created SRL groups matching primary online redo log size plus one extra group per thread. Apply lag dropped from 8 hours to under 60 seconds within minutes of SRL creation.

7. Cause 5: MRP Apply Bottleneck

Cause 5 Redo is arriving at the standby on time (low transport lag) but MRP cannot apply it fast enough (high apply lag). This is purely a standby-side problem. Do not touch the primary or network until you confirm this is the cause.

SQL, Diagnose and Fix MRP Apply Bottleneck

-- Check MRP status and wait events (run on STANDBY)
SELECT event,
       total_waits,
       ROUND(average_wait, 3)  AS avg_wait_ms,
       wait_class
FROM   v$system_event
WHERE  wait_class NOT IN ('Idle', 'Network')
ORDER  BY time_waited DESC
FETCH FIRST 15 ROWS ONLY;

-- Check parallel apply worker count (run on STANDBY)
-- If only MRP0 shown, parallel apply is disabled
SELECT process,
       status,
       thread#
FROM   v$managed_standby
WHERE  process LIKE 'PR%'
OR     process LIKE 'MRP%'
ORDER  BY process;

-- Enable parallel apply (run on STANDBY)
-- Stop current apply first
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- Restart with parallel apply (match to standby CPU count)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    PARALLEL 8
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Verify parallel workers started
SELECT process,
       status
FROM   v$managed_standby
WHERE  process LIKE 'PR%'
OR     process LIKE 'MRP%'
ORDER  BY process;

Fix Enable parallel apply with degree matching standby CPU count. Give MRP dedicated I/O separate from RMAN backup. If Active Data Guard is enabled, use I/O Resource Manager to prioritise MRP over read queries.

8. Cause 6: Standby Resource Starvation

Cause 6 The standby does not have enough CPU, memory, or I/O bandwidth to keep up with apply. Frequently caused by under-specifying the standby relative to the primary, or by competing workloads such as RMAN backup or ADG read queries running on the same standby host during peak apply windows.

SQL, Diagnose Standby Resource Starvation

-- OS resource pressure (run on STANDBY)
SELECT stat_name,
       value
FROM   v$osstat
WHERE  stat_name IN (
    'NUM_CPUS',
    'LOAD',
    'BUSY_TIME',
    'IDLE_TIME'
);

-- RMAN backup running during peak apply (run on STANDBY)
SELECT input_type,
       status,
       TO_CHAR(start_time, 'YYYY-MM-DD HH24:MI')  AS start_time,
       input_bytes_display,
       output_bytes_display
FROM   v$rman_backup_job_details
WHERE  start_time > SYSDATE - 1
ORDER  BY start_time DESC;

-- Datafile write latency on standby
SELECT d.name,
       ROUND(f.writetim / NULLIF(f.phywrts, 0), 2)  AS avg_write_ms,
       f.phywrts
FROM   v$filestat  f
JOIN   v$datafile  d ON f.file# = d.file#
WHERE  (f.phyrds + f.phywrts) > 1000
ORDER  BY avg_write_ms DESC
FETCH FIRST 10 ROWS ONLY;

Fix Standby should match primary hardware specification. Schedule RMAN backup on the standby during off-peak apply windows. If ADG read workload is heavy, use I/O Resource Manager to protect MRP I/O priority.

9. SYNC vs ASYNC: Which Mode Creates Which Lag Pattern

Scenario	SYNC Mode Behaviour	ASYNC Mode Behaviour
Network spike (100 ms RTT)	Every commit stalls 100 ms, performance crisis on primary	Transport lag grows silently, primary unaffected
Standby reboots	Primary stalls (Max Protection) or falls back to async (Max Availability)	Transport lag grows until standby returns, no primary impact
Redo volume burst	Network saturates, commits queue behind LGWR	NSA buffer fills, lag grows but primary performance maintained
Steady state (good network)	Transport lag near zero, apply lag depends on MRP	Small transport lag always present (1,5 sec typical)
Packet loss	LGWR stalls on every retransmit, very visible on primary	Lag spikes during loss window, primary unaffected

10. Lag Under Active Data Guard (ADG Read Workload)

Active Data Guard introduces an additional lag risk: read queries on the standby compete with MRP for I/O bandwidth. In a busy ADG reporting workload, MRP can be starved of the I/O it needs to apply redo.

SQL, Monitor ADG Read vs MRP Apply I/O Competition

-- Check open mode on standby (ADG = READ ONLY WITH APPLY)
SELECT open_mode,
       database_role,
       db_unique_name
FROM   v$database;

-- Active read sessions vs MRP on standby
SELECT s.type,
       s.status,
       COUNT(*)  AS session_count
FROM   v$session s
WHERE  s.type = 'USER'
OR     s.program LIKE '%MRP%'
GROUP  BY s.type, s.status;

-- Apply lag while ADG read load is active
SELECT name,
       value,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag')
ORDER  BY name;

11. Proactive Lag Monitoring

Build proactive monitoring that catches lag before it becomes an incident. Run this query every 5 minutes from your monitoring system.

SQL, Data Guard Lag Monitoring Alert Query

-- Lag monitoring with alert thresholds (run on PRIMARY every 5 min)
SELECT db_unique_name,
       name                                         AS metric,
       value                                        AS lag_value,
       CASE
           WHEN name = 'transport lag'
                AND TO_DSINTERVAL(value) > INTERVAL '0 00:00:30' HOUR TO SECOND
           THEN 'ALERT: Transport lag exceeds 30 seconds'
           WHEN name = 'apply lag'
                AND TO_DSINTERVAL(value) > INTERVAL '0 00:02:00' HOUR TO SECOND
           THEN 'ALERT: Apply lag exceeds 2 minutes'
           ELSE 'OK'
       END                                          AS alert_status,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag')
ORDER  BY name;

-- Sequence gap detection (run on PRIMARY)
-- Any rows = immediate action required
SELECT thread#,
       low_sequence#,
       high_sequence#
FROM   v$archive_gap
ORDER  BY thread#;

-- DGMGRL health check (run from broker CLI)
-- dgmgrl / "show configuration"
-- dgmgrl / "validate database verbose standby_db"

12. FAQ

Transport lag shows zero but apply lag is 2 hours. What is happening?

Transport lag of zero means redo is arriving at the standby immediately. The network and primary are fine. Apply lag of 2 hours means MRP is 2 hours behind applying what it has already received. This is a pure standby-side problem. Check MRP parallel degree, standby I/O performance, RMAN backup scheduling, and whether ADG read workload is starving MRP. Do not look at the network for this pattern.

Should I increase redo log size to reduce transport lag?

Increasing redo log size reduces log switch frequency, which smooths out the burst pattern of redo transport. However it does not reduce total redo volume, so if the problem is sustained bandwidth saturation, larger logs will not help. The sweet spot for most production systems is 500 MB to 2 GB per redo log group, switching every 10,30 minutes under normal load.

Can I reduce lag without switching from SYNC to ASYNC?

Yes. Enable redo log compression (COMPRESSION=ENABLE) to reduce bandwidth by 50,70% at the cost of CPU on both sides. Upgrade network bandwidth (1 GbE to 10 GbE resolves most SYNC saturation issues). Increase redo log group count so LGWR can switch to a new group while NSS sends the previous one. Ensure SRLs are configured so MRP stays close to the arrival point.

Comment DG below if you want a specific lag scenario diagnosed.

Drop a comment with DG and describe your lag pattern: what are your transport lag and apply lag values, what is your protection mode, and what workload triggers the spike. I will give you a specific diagnostic path based on your exact scenario.

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on experience managing production databases across on-premises, hybrid, and cloud environments.

Chetan has diagnosed and resolved Data Guard lag incidents across financial, healthcare, and e-commerce production environments including the 8-hour apply gap from missing Standby Redo Logs and the firewall stateful inspection transport lag described in this article.

This blog focuses on real-world DBA problems, career growth, and practical learning, not theoretical documentation or vendor marketing.

How to Create a Resume That Actually Gets Shortlisted in 2026

2026-04-02T11:50:00.001+05:30

How to Create a Resume That Actually Gets Shortlisted in 2026

Generic Resumes Get Rejected Instantly. Here Is What Actually Works.

02 March 2026

Chetan Yadav, Senior Oracle & Cloud DBA

⏱️ 14 - 16 min read

⏱️ Estimated Reading Time: 14,16 minutes

ATS Optimisation, Impact Writing, Section Structure, Common Mistakes, Before-Submit Checklist

 Who This Guide Is For

Final year students writing their first resume, freshers who have applied to 50 jobs and heard nothing back, mid-level professionals switching roles or industries, and anyone who has been told their resume is "fine" but it keeps getting rejected. This guide covers the real mechanics of how resumes are screened in 2026 and what you must do differently.

I have reviewed hundreds of resumes over 15 years of hiring, mentoring, and career coaching within the technology industry. The same mistakes appear in almost every rejected resume. Not spelling errors. Not bad formatting. The real problem is almost always this: the resume describes what the person did instead of proving what the person achieved.

A resume is not a job description of your past roles. It is a marketing document with one purpose: to get you into the interview room. Every word, every bullet point, every section must serve that purpose. When a recruiter spends 8 seconds on your resume, you have 8 seconds to make them believe you can solve their problem. Generic resumes fail this test instantly.

This guide will show you the exact structure, the ATS rules, the impact writing formula, the before-submit checklist, and the specific mistakes that are costing you interviews right now.

 Table of Contents

How Your Resume Is Actually Screened in 2026
ATS Optimisation: What Applicant Tracking Systems Look For
Section 1: Header (The First Three Lines)
Section 2: Professional Summary (Four Lines That Sell You)
Section 3: Skills Section (Where ATS Keywords Live)
Section 4: Experience (The Most Important Section)
The Impact Writing Formula: Action, What, Result
Section 5: Education and Certifications
The 15 Mistakes That Get You Rejected
Resume for Freshers and Final Year Students
Before-Submit Checklist
FAQ

1. How Your Resume Is Actually Screened in 2026

Most job seekers imagine a recruiter carefully reading every word of their resume. The reality is a two-stage filter where most resumes are eliminated before any human reads them.

Stage	Who	Time	What They Are Looking For
Stage 1	ATS Software	Seconds	Keywords, file format, section headers, structure
Stage 2	Recruiter	6,8 seconds	Role match, impact, clarity, years of experience
Stage 3	Hiring Manager	1,2 minutes	Achievements, technical depth, career trajectory
Stage 4	Interview Panel	45,60 minutes	Only 2,3% of applicants reach this stage

The Brutal Reality:

For a popular job posting that receives 500 applications, roughly 350 are eliminated by ATS before any human sees them. Of the remaining 150 that reach the recruiter, 130 are rejected in the 8-second scan. Only 20 resumes reach the hiring manager. Your resume must survive two filters before a qualified human even reads it. This is why generic resumes fail.

2. ATS Optimisation: What Applicant Tracking Systems Look For

Applicant Tracking Systems (ATS) are software platforms that parse your resume into a structured database record. The software scores your resume against the job description based on keyword matching, section identification, and format compatibility. If your score falls below a threshold, a human never sees your resume.

ATS Rules You Must Follow

Rule File format: Submit PDF unless the job posting specifically asks for DOCX. Some older ATS systems cannot parse PDF correctly, so always re-read the application instructions.
Rule No tables or columns: ATS reads left to right, top to bottom. A two-column layout causes the ATS to read across both columns in the wrong order, scrambling your content.
Rule Standard section headers: Use exactly these words: Experience, Education, Skills, Certifications, Summary. Do not use creative headers like "My Journey" or "What I Bring."
Rule No text boxes or graphics: ATS software cannot read content inside text boxes, headers/footers, or image-based elements. Put everything in the main document body.
Rule Keyword matching: Copy the exact terminology from the job description. If the JD says "Oracle Real Application Clusters," do not just write "Oracle RAC" on your resume. Write both.
Rule Font: Arial, Calibri, or Helvetica. 10,12pt for body text. Decorative fonts render incorrectly in many ATS systems.

Free ATS Testing Tools:

Before submitting any application, test your resume using Jobscan (jobscan.co) or Resume Worded (resumeworded.com). Paste the job description and your resume and they show you your keyword match score and ATS compatibility issues. Target a match score of 75% or above before submitting.

3. Section 1: Header (The First Three Lines)

The header is the first thing every reader sees. It must communicate who you are and how to reach you in under three seconds. Nothing else.

Template, Resume Header (Copy and Adapt)

CHETAN YADAV
Senior Oracle DBA, Cloud Architect, OCI Specialist
+91-XXXXXXXXXX  |  chetan@email.com  |  linkedin.com/in/chetanyadavvds
Mumbai, India  |  Open to Remote

Include Full name (large, bold), target job title, phone, email, LinkedIn URL, city and country
Include GitHub or portfolio link if relevant to the role (software engineers, data scientists)
Remove Full address (street and postal code), date of birth, marital status, nationality, religion
Remove Photograph (in most countries this invites unconscious bias and ATS cannot process it)
Remove "Curriculum Vitae" or "Resume" as a header title (waste of valuable space)

Job Title Tip:

The title on your resume header should match the job title you are applying for, not necessarily your current job title. If the job description says "Senior Database Engineer" and you are currently a "Senior DBA," use "Senior Database Engineer" in your header. ATS systems keyword-match job titles. This is not dishonest, it is accurate positioning.

4. Section 2: Professional Summary (Four Lines That Sell You)

The professional summary is the most valuable piece of real estate on your resume. A recruiter who spends 8 seconds on your resume will almost certainly read the summary. Make those four lines earn your interview.

Template, Professional Summary (Four-Line Formula)

Line 1 - Experience + Domain + Level:
"Senior Oracle DBA with 15+ years of experience managing mission-critical
production databases across finance, healthcare, and e-commerce sectors."

Line 2 - Core Technical Skills Relevant to This Role:
"Specialising in Oracle RAC, Data Guard, GoldenGate, OCI Autonomous Database,
performance tuning, and disaster recovery architecture."

Line 3 - Biggest Achievement (with a number):
"Reduced database downtime by 94% and cut infrastructure costs by 38% through
implementing a 4-node RAC cluster with automated Data Guard failover."

Line 4 - What You Are Seeking:
"Seeking a Principal DBA or Cloud Architect role to design high-availability
database solutions at enterprise scale."

What NOT to Write in Your Summary:

"A hardworking and dedicated professional seeking a challenging opportunity to utilise my skills and grow with a reputed organisation."

This says nothing. Every applicant believes they are hardworking. Every applicant wants to grow. This generic summary signals to the recruiter that you could not think of a single specific thing to say about yourself. Recruiters stop reading immediately.

5. Section 3: Skills Section (Where ATS Keywords Live)

The skills section exists for one primary purpose: ATS keyword matching. Structure it so that every technical term the job description uses appears somewhere in this section.

Template, Skills Section Format (Grouped by Category)

SKILLS

Databases:         Oracle 19c/23ai, MySQL 8.0, PostgreSQL 15, MongoDB
Cloud Platforms:   OCI (Oracle Cloud Infrastructure), AWS RDS, Azure SQL
HA/DR:             Oracle RAC, Data Guard, GoldenGate, RMAN, ASM
Performance:       AWR, ASH, SQL Monitor, Execution Plans, Index Design
Programming:       SQL, PL/SQL, Python, Bash/Shell Scripting
Tools:             Git, Jenkins, Terraform, Ansible, JIRA, Confluence
Operating Systems: Oracle Linux 8, RHEL 8/9, Windows Server 2019

Do Group skills by category with a colon, not bullet points or tables
Do Include both the acronym and the full term: RAC (Real Application Clusters)
Do Match exact terms from the job description, including capitalisation
Avoid Skill rating bars, stars, or percentage indicators (ATS cannot read them)
Avoid Listing soft skills here (communication, teamwork) — they belong in experience bullets
Avoid Listing skills you cannot discuss confidently in an interview

6. Section 4: Experience (The Most Important Section)

The experience section is where resumes are won or lost. Most candidates list their job duties. Shortlisted candidates list their achievements. This is the single most important distinction between a resume that gets calls and one that does not.

Experience Entry Format

Template, Experience Entry Structure

SENIOR ORACLE DBA                                    Mar 2021, Present
TechCorp Financial Services, Mumbai

, Designed and implemented a 4-node Oracle 19c RAC cluster on OCI,
  reducing planned downtime from 8 hours to under 30 seconds per quarter.

, Tuned 47 high-impact SQL queries identified through AWR analysis,
  reducing peak-hour CPU utilisation from 94% to 61%.

, Automated RMAN backup validation using PL/SQL and Shell scripts,
  cutting backup verification time from 4 hours to 22 minutes.

, Migrated 8.2 TB Oracle database from on-premises to OCI Autonomous
  Database with zero data loss using GoldenGate replication.

, Mentored 3 junior DBAs, all promoted within 18 months.

Rules for Experience Bullets

Start every bullet with a strong past-tense action verb: Designed, Built, Reduced, Increased, Migrated, Automated, Led, Implemented, Optimised
Write 3,5 bullets per role. Most recent role gets the most bullets
Every bullet must show impact, not activity. The difference is a number
List roles in reverse chronological order (most recent first)
Include exact month and year for all dates, right-aligned

7. The Impact Writing Formula: Action, What, Result

Every experience bullet should follow this three-part formula. If a bullet is missing any part, it is weaker than it should be.

Impact Formula, Action + What + Result (with Number)

Formula:  [Action Verb] + [What You Did] + [Measurable Result]

Examples:

Reduced     + backup window through RMAN incremental merge    + from 6hr to 40min (89% faster)
Designed    + Oracle RAC cluster for financial core system    + achieving 99.995% uptime over 2 years
Automated   + index monitoring using PL/SQL alerting script   + saving 12 DBA hours per week
Migrated    + 8TB on-premises Oracle DB to OCI ADB            + cutting infra cost by $180K/year
Identified  + 23 missing indexes via AWR analysis             + reducing avg query time from 8s to 0.9s
Led         + team of 5 DBAs across 3 time zones              + delivering zero-downtime DR drill quarterly

REJECTED: Activity Description

"Responsible for managing database backups and ensuring they complete successfully each night."

"Worked on performance tuning of slow queries using AWR reports."

"Involved in the migration of databases to the cloud platform."

SHORTLISTED: Impact Statement

"Automated RMAN backup validation, reducing manual verification from 4 hours to 22 minutes and eliminating 3 missed backup incidents per quarter."

"Tuned 47 high-impact queries via AWR analysis, cutting average response time from 8.4 seconds to 0.9 seconds."

"Migrated 8.2 TB Oracle DB to OCI with GoldenGate, achieving zero data loss and $180K annual cost reduction."

What If You Do Not Have Numbers?

Every DBA has numbers, they just have not looked for them yet. Think about: how many databases you manage, how much storage, how many users or transactions per second, what the uptime percentage is, how long tasks used to take vs now, how many incidents you resolved, what team size you worked with, what budget you managed. If you genuinely cannot find a number, use an estimate with a qualifier: "approximately," "averaging," or "across 10+ production databases." An approximate number is better than no number.

8. Section 5: Education and Certifications

For experienced professionals, education goes near the bottom. For freshers and final year students, education goes near the top, above experience.

Template, Education and Certifications Section

EDUCATION

B.Tech in Computer Science Engineering                          2018,2022
Mumbai University, Mumbai
Final Year Project: Automated Oracle DBA Monitoring Dashboard
using Python, PL/SQL and Telegram Bot API
GPA: 8.4/10

CERTIFICATIONS

Oracle Database 19c Certified Professional (OCP)               2023
Oracle Cloud Infrastructure 2023 Architect Associate           2023
AWS Certified Database Specialty                                2024
Oracle Certified Expert: RAC and Grid Infrastructure           2024

Include GPA only if it is 3.5+ (on 4.0 scale) or 8.0+ (on 10.0 scale)
List certifications with the full official name and year obtained
For freshers, describe your final year project with the technology stack used and outcome
Include relevant academic projects, internships, or open source contributions if you have limited work experience

9. The 15 Mistakes That Get You Rejected

Mistake	Why It Kills Your Application	Fix
Generic objective statement	Signals you copy-pasted your resume	Write a specific 4-line summary targeting this role
Duties listed, not achievements	Every candidate had the same duties	Apply Action + What + Result formula to every bullet
Missing keywords from JD	ATS scores below threshold, never seen	Copy exact terms from job description into skills and bullets
Two-column layout	ATS reads across columns, scrambles content	Single column only
Tables or text boxes	ATS cannot parse content inside them	Remove all tables and text boxes
Photo or date of birth	Causes bias, ATS cannot process images	Remove completely
Same resume for every job	Never achieves high ATS keyword match	Customise summary and skills for each role
No quantified achievements	Cannot differentiate from 400 other applicants	Add numbers to every bullet
Skill rating bars or stars	ATS reads "5 stars" not the skill name properly	Replace with categorised plain text list
Fancy fonts or colours	ATS often fails to parse non-standard fonts	Use Arial, Calibri, or Helvetica in black
Wrong page count	0,5 years on 3 pages signals padding	1 page for 0,5 years, 2 pages max for 5+ years
Unexplained employment gaps	Raises red flags with no context	Label gap briefly: Freelance, Study, Career Break
No LinkedIn or outdated profile	Recruiter checks LinkedIn before calling	Update LinkedIn to match resume exactly
Spelling or grammar errors	Signals carelessness in detail-oriented roles	Run Grammarly Premium before submitting
Passive voice language	"Was involved in" vs "Led" signals junior mindset	Start every bullet with a strong action verb

10. Resume for Freshers and Final Year Students

If you have no full-time work experience, your resume structure changes. The principles remain identical: show impact, use keywords, write achievements. The sources of those achievements change.

Fresher Resume Section Order

Header (same as experienced candidate)
Professional Summary (focus on skills and what you bring, not years)
Education (goes ABOVE experience for freshers)
Projects (academic, personal, hackathon, open source)
Internships (any, even unpaid or short duration)
Skills
Certifications
Extracurricular / Leadership (only if relevant or impressive)

Template, Fresher Project Entry (How to Write Impact Without Work Experience)

PROJECTS

Oracle DBA Monitoring Dashboard                    Jan 2022,Apr 2022
Final Year Project, Mumbai University

, Built automated database health monitoring system using Python,
  PL/SQL, and Telegram Bot API covering 12 performance metrics.

, Reduced manual health check time from 45 minutes to under 3 minutes
  per DBA shift by automating AWR alert generation.

, Deployed on Oracle Database 19c Express Edition with 99% uptime
  during 3-month testing period across 5 simulated databases.

, Presented to panel of 4 industry judges, awarded Best Final Year
  Project in Computer Science department (batch of 240 students).

Tech Stack: Python 3.10, Oracle DB 19c XE, PL/SQL, Telegram API, Linux

Fresher with No Projects or Internships:

Build something before you apply. Spend 2 weekends building a small project using the technologies in the job description. Install Oracle Database XE (free), create a schema, write some queries, automate a task with Python or Shell script, and put it on GitHub. Then write 3,4 impact bullets about what you built and what it does. A small real project beats a blank projects section every time. Recruiters hiring freshers are looking for proof that you can learn and build, not just that you attended classes.

11. Before-Submit Checklist

Content Checklist

Header title matches the job description title exactly
Summary is specific to this role, not generic
Every experience bullet contains a number or measurable result
All keywords from the job description appear in the resume
Strongest and most relevant experience is listed first
Employment gaps are explained with a brief label
Certifications include official name and year obtained

Format Checklist

Single column layout with no tables or text boxes
Standard section headers: Summary, Experience, Skills, Education
Font is Arial, Calibri, or Helvetica at 10,12pt
Margins are 0.5 to 1 inch on all sides
Page count appropriate: 1 page for 0,5 years, 2 pages max for 5+ years
File saved as PDF (unless DOCX explicitly requested)
No photos, logos, graphics, or skill rating bars

Quality Checklist

Spell check run and passed (Grammarly Premium recommended)
Date format is consistent throughout: Mar 2024, not 03/24 and March 2024 mixed
LinkedIn URL is current and profile matches resume
Contact email is professional: firstname.lastname@gmail.com
ATS tested on Jobscan or Resume Worded, score above 75%
At least one other person has reviewed it and given feedback
You can confidently speak to every single item on the resume

12. FAQ

Should I use a resume template from Canva or similar design tools?

No. Canva templates are designed for visual appeal, not ATS compatibility. They use text boxes, columns, tables, and graphics that ATS systems cannot parse correctly. Your beautifully formatted Canva resume may appear as a blank or scrambled document to the ATS. Use Microsoft Word or Google Docs with a simple, clean, single-column format. Plain is powerful when ATS is involved.

How many resumes should I be sending per week?

Quality over quantity. Sending 100 generic resumes per week produces fewer interviews than sending 10 carefully tailored resumes per week. Each application should have a resume with a customised summary and skills section matching that specific job description. It takes 20,30 minutes to properly tailor a resume. That investment is worth more than blasting the same generic document to 100 companies.

Should I include a cover letter?

Include a cover letter when the application explicitly asks for one, and when you are applying to a company you genuinely want to work for. Keep it to 3 short paragraphs: why you are interested in this specific role and company, your single strongest achievement that is directly relevant, and a clear call to action. Never paste your resume into the cover letter. Add information that is not on the resume, specifically why you want this job at this company.

I have a 2-year employment gap. Will it disqualify me?

A gap alone does not disqualify you. An unexplained gap raises questions. Address it directly and briefly on the resume itself with a one-line label in the date position: "Career Break (Freelance Projects, 2022,2023)" or "Career Break (Full-Time Study, PGDBA, 2021,2022)." Then address it confidently in interviews: what you did during the gap, what you learned, and why you are ready to return. Most hiring managers respect honesty far more than creative attempts to hide a gap.

Comment RESUME below to get a personalised resume review tip.

Drop a comment below with RESUME and share the role you are targeting. I will give you one specific, actionable improvement tip for your resume based on the role and your background. I read every comment.

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on experience managing production databases and building high-performance technology teams.

Beyond technical work, Chetan has reviewed hundreds of resumes, mentored early-career DBAs through job searches, and coached professionals transitioning into cloud and database architecture roles. He has been on both sides of the hiring table, which gives him a clear view of what actually gets candidates shortlisted versus what looks good but fails in practice.

This blog covers real-world DBA problems, cloud architecture, career growth, and practical learning, not theoretical documentation or vendor marketing.

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

2026-03-30T14:23:00.005+05:30

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.

 Table of Contents

Transport Lag vs Apply Lag: Understanding the Difference
The Diagnostic Starting Point: Five Queries to Run First
Cause 1: Primary Storage I/O Pressure
Cause 2: Redo Volume Spike (Batch Jobs)
Cause 3: Network Latency and Bandwidth
Cause 4: Misconfiguration (SRL, NET_TIMEOUT, AFFIRM)
Cause 5: Standby Apply Bottleneck
Cause 6: Standby Resource Starvation
SYNC vs ASYNC: Which Mode Causes Which Lag Pattern
Lag Under Active Data Guard (Read-Only Standby)
Building a Lag Monitoring Alert
FAQ
Related Reading from Real Production Systems

1. Transport Lag vs Apply Lag: Understanding the Difference

Before diagnosing lag, you must understand which type you have. They look the same on a monitoring dashboard but live in completely different parts of the Data Guard pipeline.

Lag Type	Definition	Lives In	Primary Cause
Transport Lag	Redo generated on primary but not yet received by standby	Network pipe between primary and standby	Network, primary I/O, redo volume
Apply Lag	Redo received by standby but not yet applied to datafiles	Standby MRP apply process	Standby I/O, CPU, misconfiguration

Critical Distinction:

If transport lag is high but apply lag is low , your network or primary is the problem. The standby is applying redo as fast as it receives it; it just isn't receiving it fast enough.

If transport lag is low but apply lag is high , your standby is the problem. Redo is arriving quickly but MRP cannot apply it fast enough.

If both are high , you have multiple problems or a severe redo volume spike that is overwhelming the entire pipeline.

2. The Diagnostic Starting Point: Five Queries to Run First

Run these five queries immediately when lag is reported. They tell you which cause category you are dealing with before you go deeper.

SQL , Five Immediate Diagnostic Queries for Data Guard Lag

-- Query 1: Transport lag vs apply lag (run on PRIMARY)
SELECT name,
       value,
       unit,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN (
    'transport lag',
    'apply lag',
    'apply finish time',
    'estimated startup time'
)
ORDER  BY name;

-- Query 2: Current redo generation rate (run on PRIMARY)
-- High rate = redo volume problem
SELECT inst_id,
       ROUND(value / 1024 / 1024, 2)  AS redo_mb_per_sec
FROM   gv$sysstat
WHERE  name = 'redo size'
AND    inst_id IN (SELECT inst_id FROM gv$instance);

-- Query 3: Archive dest status and error (run on PRIMARY)
SELECT dest_id,
       dest_name,
       status,
       target,
       archiver,
       schedule,
       destination,
       error,
       applied_scn,
       gap_status
FROM   v$archive_dest_status
WHERE  status != 'INACTIVE'
ORDER  BY dest_id;

-- Query 4: MRP apply process status (run on STANDBY)
SELECT process,
       status,
       thread#,
       sequence#,
       block#,
       blocks,
       delay_mins
FROM   v$managed_standby
ORDER  BY process;

-- Query 5: Standby redo log receive vs apply position (run on STANDBY)
SELECT thread#,
       low_sequence#,
       high_sequence#,
       applied
FROM   v$archived_log
WHERE  standby_dest = 'YES'
ORDER  BY thread#, high_sequence# DESC
FETCH FIRST 10 ROWS ONLY;

3. Cause 1: Primary Storage I/O Pressure

Cause 1 LGWR cannot write redo to local online redo logs fast enough. Every redo write is now slower than normal. In SYNC mode this directly delays the network send to the standby. In ASYNC mode it slows redo generation which eventually causes the NSA buffer to fill up.

How to Confirm It

SQL , Diagnose Primary Storage I/O as Lag Root Cause

-- Check LGWR wait events (run on PRIMARY)
-- High log file sync or log file parallel write = LGWR I/O problem
SELECT event,
       total_waits,
       time_waited,
       ROUND(average_wait, 3)   AS avg_wait_ms,
       wait_class
FROM   v$system_event
WHERE  event IN (
    'log file sync',
    'log file parallel write',
    'log buffer space'
)
ORDER  BY time_waited DESC;

-- Check datafile I/O latency (high write latency = DBWR pressure on LGWR)
SELECT name,
       phyrds,
       phywrts,
       ROUND(readtim  / NULLIF(phyrds,  0), 2)  AS avg_read_ms,
       ROUND(writetim / NULLIF(phywrts, 0), 2)  AS avg_write_ms
FROM   v$filestat f
JOIN   v$datafile d ON f.file# = d.file#
WHERE  phywrts > 1000
ORDER  BY avg_write_ms DESC
FETCH FIRST 10 ROWS ONLY;

-- Check ASM rebalance activity (can throttle I/O)
SELECT group_number,
       operation,
       state,
       power,
       actual,
       sofar,
       est_minutes
FROM   v$asm_operation;

Fix Separate redo log files onto dedicated fast storage (NVMe or dedicated ASM disk group). Increase redo log size to reduce switch frequency. Schedule ASM rebalance outside peak hours. If on Exadata, verify Smart Flash Cache is handling redo log writes.

4. Cause 2: Redo Volume Spike

Cause 2 The primary is generating far more redo than normal. A batch job, bulk load, or mass update suddenly pushes 10–50x the normal redo rate. The network pipe cannot keep up. Transport lag grows rapidly. This is the most common cause of sudden lag spikes in production OLTP systems with nightly batch processing.

SQL , Identify Redo Volume Spike and Source SQL

-- Check redo generation rate per instance (run on PRIMARY)
SELECT inst_id,
       ROUND(value / 1024 / 1024, 2)  AS redo_mb_total
FROM   gv$sysstat
WHERE  name = 'redo size'
ORDER  BY inst_id;

-- Find top SQL generating most redo (run on PRIMARY)
SELECT sql_id,
       executions,
       ROUND(sorts * 1024 / 1024, 2)        AS sorts_mb,
       ROUND(buffer_gets / 1024.0, 0)       AS buffer_gets_k,
       ROUND(direct_writes / 1024.0, 0)     AS direct_writes_k,
       last_active_time
FROM   v$sql
WHERE  executions > 0
ORDER  BY sorts DESC
FETCH FIRST 20 ROWS ONLY;

-- Check archive log generation rate (run on PRIMARY)
-- Sudden spike in log count = redo volume surge
SELECT TO_CHAR(first_time, 'YYYY-MM-DD HH24')  AS hour,
       COUNT(*)                                  AS logs_generated,
       ROUND(SUM(blocks * block_size)/1024/1024) AS total_mb
FROM   v$archived_log
WHERE  first_time > SYSDATE - 1
AND    standby_dest = 'NO'
GROUP  BY TO_CHAR(first_time, 'YYYY-MM-DD HH24')
ORDER  BY hour DESC;

Fix Use NOLOGGING or APPEND hints for bulk data loads where tolerable. Schedule heavy batch jobs during off-peak hours. Implement redo log compression on the archive destination (COMPRESSION=ENABLE in LOG_ARCHIVE_DEST). For ASYNC mode consider increasing async_blocks parameter.

5. Cause 3: Network Latency and Bandwidth

Cause 3 This is the most commonly blamed cause , and the most commonly misdiagnosed. Network problems cause transport lag. They do not cause apply lag. If apply lag is high and transport lag is low, stop looking at the network.

Network Metrics That Matter for Data Guard

Metric	Good Value	Problem Threshold	Impact
Round-trip latency (RTT)	< 2 ms	> 5 ms for SYNC	Every commit waits RTT in SYNC mode
Bandwidth utilisation	< 60%	> 80% sustained	Redo bursts cause queuing delay
Packet loss	0%	> 0.01%	TCP retransmit multiplies latency
Jitter (latency variance)	< 1 ms	> 5 ms	Unpredictable LGWR stalls in SYNC

SQL , Diagnose Network as Data Guard Lag Cause

-- Check redo transport network statistics (run on PRIMARY)
SELECT dest_id,
       srl_network_writes,
       srl_network_write_time,
       ROUND(srl_network_write_time /
             NULLIF(srl_network_writes, 0), 3)  AS avg_network_write_ms
FROM   v$standby_log_stats
ORDER  BY dest_id;

-- Check NSA (async) or NSS (sync) send process (run on PRIMARY)
SELECT process,
       status,
       client_process,
       sequence#,
       block#,
       blocks,
       delay_mins
FROM   v$managed_standby
WHERE  process LIKE 'NS%'
ORDER  BY process;

-- Check archive destination error status
SELECT dest_id,
       status,
       error,
       gap_status,
       db_unique_name
FROM   v$archive_dest_status
WHERE  target = 'STANDBY'
AND    status != 'INACTIVE';

-- OS-level network check (run from primary server shell)
-- ping -c 100 standby_host | tail -5
-- traceroute -n standby_host
-- iperf3 -c standby_host -t 30 -P 4   (bandwidth test)

Fix Enable redo log compression: add COMPRESSION=ENABLE to LOG_ARCHIVE_DEST_2. Implement QoS tagging on redo transport traffic on your WAN appliance. Increase NET_TIMEOUT if packet loss causes premature timeouts. Switch from SYNC to ASYNC if RTT exceeds 5 ms and strict zero data loss is not mandatory. Use dedicated WAN link for redo transport , never share with application traffic.

Incident: Firewall Stateful Inspection Causing Transport Lag

A Data Guard environment was configured correctly with 1.8 ms RTT on the dedicated WAN link. Transport lag would spike to 120+ seconds randomly, then clear, then spike again. Network team confirmed zero packet loss. Root cause: a next-gen firewall performing deep packet inspection on the redo transport TCP stream. Each 10-second idle gap caused the firewall to drop and re-establish the TCP state table entry, causing a 15–30 second reconnect delay on the NSS process.

Fix: Added a firewall bypass rule for the specific TCP port used by Data Guard redo transport (LOG_ARCHIVE_DEST SERVICE port). Lag spikes disappeared immediately.

6. Cause 4: Misconfiguration

Cause 4 Configuration errors are silent lag causes. Everything looks operationally normal , no errors in alert log, no network problems, reasonable redo rate. But lag slowly accumulates because something is configured wrong. These are the hardest to find because they require knowing what correct configuration looks like.

SQL , Verify Data Guard Configuration for Common Misconfigurations

-- Check 1: Standby Redo Logs exist and are correct size
-- SRL must be same size as online redo logs
-- Must have at least (online_log_groups + 1) SRL per thread
SELECT group#,
       thread#,
       sequence#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- Compare SRL size vs online redo log size (run on PRIMARY)
-- These must match
SELECT 'online' AS log_type,
       group#,
       bytes/1024/1024  AS size_mb
FROM   v$log
UNION ALL
SELECT 'standby',
       group#,
       bytes/1024/1024
FROM   v$standby_log
ORDER  BY log_type, group#;

-- Check 2: AFFIRM setting matches protection mode intention
SELECT dest_id,
       dest_name,
       affirm,
       async_blocks,
       net_timeout,
       delay,
       compression,
       status
FROM   v$archive_dest
WHERE  target = 'STANDBY'
AND    status = 'VALID';

-- Check 3: Real-time apply is running (not archive-based apply)
-- Must show WAIT_FOR_LOG not WAIT_FOR_GAP
SELECT process,
       status,
       sequence#
FROM   v$managed_standby
WHERE  process = 'MRP0';

-- Check 4: Protection mode vs protection level match
-- If they differ, primary has fallen back silently
SELECT protection_mode,    -- configured
       protection_level    -- actual effective
FROM   v$database;

Incident: Missing Standby Redo Logs , 8-Hour Apply Gap

A newly built Data Guard environment appeared healthy. Alert log clean. No errors. Archive destination showed SUCCESS. But during failover testing, the standby was 8 hours behind the primary despite a low-latency WAN link.

Root cause: Standby Redo Logs had never been created on the standby. Without SRLs, real-time apply cannot function. The MRP process was waiting for archived logs to be shipped rather than receiving redo in real time. The standby was only catching up when logs were archived , once per hour by default.

Fix: Created SRL groups matching primary online redo log size and count + 1. Real-time apply started immediately. Apply lag dropped from 8 hours to under 60 seconds within minutes.

7. Cause 5: Standby Apply Bottleneck

Cause 5 Redo is arriving at the standby on time (low transport lag) but MRP cannot apply it fast enough. Apply lag grows. This is purely a standby-side problem , do not touch the primary or network until you have confirmed this is the cause.

SQL , Diagnose and Fix MRP Apply Bottleneck

-- Check MRP apply rate and wait events (run on STANDBY)
SELECT process,
       status,
       thread#,
       sequence#,
       block#,
       blocks
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process = 'RFS';

-- Check what MRP is waiting for (run on STANDBY)
SELECT event,
       total_waits,
       ROUND(average_wait, 3)  AS avg_wait_ms,
       wait_class
FROM   v$system_event
WHERE  wait_class NOT IN ('Idle', 'Network')
ORDER  BY time_waited DESC
FETCH FIRST 15 ROWS ONLY;

-- Check parallel apply worker count (run on STANDBY)
-- If only MRP0 shown, parallel apply is disabled
SELECT process,
       status,
       thread#
FROM   v$managed_standby
WHERE  process LIKE 'PR%'    -- parallel recovery slaves
OR     process LIKE 'MRP%'
ORDER  BY process;

-- Enable parallel apply (run on STANDBY , requires brief MRP restart)
-- Stop current apply
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

-- Restart with parallel apply (match to standby CPU count)
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    PARALLEL 8
    USING CURRENT LOGFILE
    DISCONNECT FROM SESSION;

-- Verify parallel workers started
SELECT process, status
FROM   v$managed_standby
WHERE  process LIKE 'PR%' OR process LIKE 'MRP%'
ORDER  BY process;

Fix Enable parallel apply with a degree matching standby CPU count. Ensure standby has dedicated I/O for datafile writes , separate from RMAN backup disk. If Active Data Guard is enabled, read queries compete with MRP for I/O , use I/O Resource Manager to prioritise MRP. Check standby UNDO tablespace for contention if apply waits show undo-related events.

8. Cause 6: Standby Resource Starvation

Cause 6 The standby server does not have enough CPU, memory, or I/O bandwidth to keep up with apply. This is frequently caused by under-specifying the standby relative to the primary, or by running competing workloads (RMAN backup, ADG reads, OS processes) on the same standby host.

SQL , Diagnose Standby Resource Starvation

-- Check CPU and I/O pressure on standby (run on STANDBY)
SELECT stat_name,
       value
FROM   v$osstat
WHERE  stat_name IN (
    'NUM_CPUS',
    'LOAD',
    'BUSY_TIME',
    'IDLE_TIME',
    'PHYSICAL_MEMORY_BYTES'
);

-- Check if RMAN backup is running during peak apply (run on STANDBY)
SELECT session_key,
       input_type,
       status,
       TO_CHAR(start_time, 'YYYY-MM-DD HH24:MI')  AS start_time,
       input_bytes_display,
       output_bytes_display
FROM   v$rman_backup_job_details
WHERE  start_time > SYSDATE - 1
ORDER  BY start_time DESC;

-- Check I/O contention on standby datafiles (run on STANDBY)
SELECT name,
       ROUND(readtim  / NULLIF(phyrds,  0), 2)  AS avg_read_ms,
       ROUND(writetim / NULLIF(phywrts, 0), 2)  AS avg_write_ms,
       phyrds,
       phywrts
FROM   v$filestat f
JOIN   v$datafile d ON f.file# = d.file#
WHERE  (phyrds + phywrts) > 1000
ORDER  BY avg_write_ms DESC
FETCH FIRST 10 ROWS ONLY;

-- Use I/O Resource Manager to protect MRP (run on STANDBY)
-- Create plan that gives MRP highest I/O priority
BEGIN
    DBMS_RESOURCE_MANAGER.CREATE_PENDING_AREA();
    DBMS_RESOURCE_MANAGER.CREATE_PLAN(
        plan    => 'STANDBY_MGMT_PLAN',
        comment => 'Protect MRP apply from ADG read workload'
    );
    DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
        plan                  => 'STANDBY_MGMT_PLAN',
        group_or_subplan      => '_ORACLE_BACKGROUND_GROUP_',
        comment               => 'MRP background priority',
        mgmt_p1               => 80
    );
    DBMS_RESOURCE_MANAGER.SUBMIT_PENDING_AREA();
END;
/

9. SYNC vs ASYNC: Which Mode Causes Which Lag Pattern

Scenario	SYNC Mode Behaviour	ASYNC Mode Behaviour
Network spike (100ms RTT)	Every commit stalls 100ms , performance crisis on primary	Transport lag grows silently , primary unaffected
Standby reboots	Primary stalls (Max Protection) or falls back to async (Max Availability)	Transport lag grows until standby returns; no primary impact
Redo volume burst	Network saturates; commits queue behind LGWR	NSA buffer fills; lag grows but primary performance maintained
Steady state (good network)	Transport lag near zero; apply lag depends on MRP	Small transport lag always present (1–5 sec typical)
Network intermittent loss	LGWR stalls on each retransmit; very visible on primary	Lag spikes during loss window; primary unaffected

10. Lag Under Active Data Guard (Read-Only Standby)

Active Data Guard (ADG) introduces an additional lag risk: read queries on the standby compete with MRP for I/O bandwidth. In a busy ADG reporting workload, MRP can be starved of the I/O it needs to apply redo quickly.

SQL , Monitor ADG Read vs MRP Apply I/O Competition

-- Check open mode on standby (ADG = READ ONLY WITH APPLY)
SELECT open_mode,
       database_role,
       db_unique_name
FROM   v$database;

-- Monitor read sessions vs MRP on standby
SELECT s.type,
       s.status,
       COUNT(*)  AS session_count
FROM   v$session s
WHERE  s.type = 'USER'
OR     s.program LIKE '%MRP%'
GROUP  BY s.type, s.status;

-- Check I/O split between read sessions and MRP (run on STANDBY)
SELECT n.name,
       s.value
FROM   v$sesstat  s
JOIN   v$statname n ON s.statistic# = n.statistic#
JOIN   v$session  ss ON s.sid = ss.sid
WHERE  ss.program LIKE '%MRP%'
AND    n.name IN (
    'physical reads',
    'physical writes',
    'redo size'
);

-- Temporarily pause ADG reads to let MRP catch up (emergency use)
-- This closes standby to read sessions until apply lag clears
-- ALTER DATABASE CLOSE;
-- ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
--     USING CURRENT LOGFILE DISCONNECT;
-- Then re-open: ALTER DATABASE OPEN READ ONLY;

11. Building a Lag Monitoring Alert

Do not wait for a pager alert at 11 PM. Build proactive lag monitoring that catches problems before they become incidents.

SQL , Data Guard Lag Monitoring Query for Alert System

-- Comprehensive lag monitoring query (run on PRIMARY every 5 minutes)
-- Alerts when transport lag > 30s or apply lag > 120s
SELECT db_unique_name,
       name                                       AS metric,
       value                                      AS lag_value,
       CASE
           WHEN name = 'transport lag'
                AND TO_DSINTERVAL(value) > INTERVAL '0 00:00:30' HOUR TO SECOND
           THEN 'ALERT: Transport lag exceeds 30 seconds'
           WHEN name = 'apply lag'
                AND TO_DSINTERVAL(value) > INTERVAL '0 00:02:00' HOUR TO SECOND
           THEN 'ALERT: Apply lag exceeds 2 minutes'
           ELSE 'OK'
       END                                        AS alert_status,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag')
ORDER  BY name;

-- Archive gap detection (run on PRIMARY)
-- Any rows = sequence gap = serious problem
SELECT thread#,
       low_sequence#,
       high_sequence#
FROM   v$archive_gap
ORDER  BY thread#;

-- Full Data Guard health check (run on PRIMARY via DGMGRL)
-- dgmgrl / "show configuration"
-- dgmgrl / "validate database verbose standby_db"

12. FAQ

My transport lag shows +00 00:00:00 but apply lag is 2 hours. What is happening?

Transport lag of zero means redo is arriving at the standby immediately , the network and primary are fine. Apply lag of 2 hours means MRP is 2 hours behind in applying what it has already received. This is a pure standby-side problem: check MRP parallel degree, standby I/O performance, RMAN backup scheduling, and whether ADG read workload is starving MRP. Do not waste time looking at the network or primary for this pattern.

Should I increase redo log size to reduce transport lag?

Increasing redo log size reduces log switch frequency, which smooths out redo transport by reducing the burst pattern of frequent log switches. However it does not reduce the total volume of redo being generated , so if the problem is sustained bandwidth saturation, larger logs will not help. Larger logs also mean a longer checkpoint interval, which can increase crash recovery time. The sweet spot for most production systems is 500 MB to 2 GB per redo log group, switched every 10–30 minutes under normal load.

Can Data Guard lag cause data corruption?

Lag itself does not cause corruption , it causes data loss risk if the primary fails while the standby is behind. Corruption is a different failure mode (block corruption on primary or standby) which Data Guard can actually detect and prevent using the DB_BLOCK_CHECKING and DB_LOST_WRITE_PROTECT parameters. Enable DB_LOST_WRITE_PROTECT=TYPICAL on both primary and standby to detect lost writes that could cause divergence between the two databases.

How do I reduce lag without changing from SYNC to ASYNC mode?

Several options that preserve SYNC transport: (1) Enable redo log compression (COMPRESSION=ENABLE) to reduce bandwidth by 50–70% at the cost of CPU. (2) Upgrade network bandwidth , going from 1 GbE to 10 GbE typically resolves SYNC lag caused by saturation. (3) Increase redo log group count so LGWR can switch to a new group while NSS sends the previous one. (4) Ensure the standby uses real-time apply (SRLs configured) so MRP stays close to arrival. (5) Schedule batch redo-heavy jobs during off-peak to avoid bursting the SYNC transport pipe.

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on experience managing production databases across on-premises, hybrid, and cloud environments. He specialises in high availability architecture, performance tuning, disaster recovery, and database migrations.

Chetan has diagnosed and resolved Data Guard lag incidents across financial, healthcare, and e-commerce production environments , including the 8-hour apply gap from missing Standby Redo Logs and the firewall stateful inspection transport lag described in this article. His writing focuses on precise diagnosis and precise resolution, not generic advice.

This blog focuses on real-world DBA problems, career growth, and practical learning , not theoretical documentation or vendor marketing.

RMAN ACTIVE DUPLICATE — RUNNER DOC

2026-03-23T23:52:00.003+05:30

RMAN ACTIVE DUPLICATE — RUNNER DOC

Oracle 19c | Target → Auxiliary (DR Clone)

# Env: OL7.9 / 19.3.0.0.0

* Note: This test is done in my lab machine, I will suggest first try in your lab for the test, then use it.

Environment reference

# SOURCE (TARGET)

ORACLE_SID=FINPRD

DB_NAME=FINPRD

ORACLE_HOME=/u01/app/oracle/product/19.3.0/dbhome_1

ORACLE_BASE=/u01/app/oracle

HOST=ora-prod-01.corp.internal

TNS_ALIAS=FINPRD

# DESTINATION (AUXILIARY / DR)

ORACLE_SID=FINDR

DB_NAME=FINDR

ORACLE_HOME=/u01/app/oracle/product/19.3.0/dbhome_1

ORACLE_BASE=/u01/app/oracle

HOST=ora-dr-01.corp.internal

TNS_ALIAS=FINDR

# PATHS — auxiliary host

ORADATA=/data01/oradata/FINDR

FRA=/fra01/FINDR

ADMIN=/u01/app/oracle/admin/FINDR

# RMAN SYS password → do NOT hardcode in prod, use wallet

# SYS_PWD=<get from vault or /etc/oracle/.sys_cred>

Pre Check – Source host

[01] Verify source DB — open mode, archivelog, force logging

sqlplus / as sysdba

SELECT name, open_mode, log_mode, force_logging FROM v$database;

→ expected output:

SQL> SELECT name, open_mode, log_mode, force_logging FROM v$database;

NAME OPEN_MODE LOG_MODE FOR

--------- -------------------- ------------ ---

FINPRD READ WRITE ARCHIVELOG YES

1 row selected.

# WARNING: If FOR=NO → ALTER DATABASE FORCE LOGGING; then re-check.

[02] Check source listener — FINPRD must show READY

# On ora-prod-01.corp.internal

lsnrctl status LISTENER

tnsping FINPRD

→ expected (relevant lines only):

Service "FINPRD" has 1 instance(s).

Instance "FINPRD", status READY, has 1 handler(s) for this service...

TNS Ping Utility for Linux: Version 19.0.0.0.0

OK (10 msec)

# WARNING: If FINPRD shows BLOCKED or UNKNOWN — DB is not fully open. Do not proceed.

OS PREPARATION — AUXILIARY HOST

[03] Set env — run this first in every new shell session

# ssh oracle@ora-dr-01.corp.internal

export ORACLE_SID=FINDR

export ORACLE_BASE=/u01/app/oracle

export ORACLE_HOME=/u01/app/oracle/product/19.3.0/dbhome_1

export PATH=$ORACLE_HOME/bin:$PATH

export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH

# quick sanity

echo $ORACLE_SID && which sqlplus && which rman

→ expected:

FINDR

/u01/app/oracle/product/19.3.0/dbhome_1/bin/sqlplus

/u01/app/oracle/product/19.3.0/dbhome_1/bin/rman

[04] Create directory structure on auxiliary

# WARNING: Run as root or oracle with sudo. RMAN will ORA-01119 if these don't exist.

mkdir -p /data01/oradata/FINDR

mkdir -p /fra01/FINDR

mkdir -p /u01/app/oracle/admin/FINDR/adump

mkdir -p /u01/app/oracle/admin/FINDR/dpdump

mkdir -p /u01/app/oracle/admin/FINDR/hdump

chown -R oracle:oinstall /data01/oradata /fra01

chmod -R 755 /data01/oradata /fra01 /u01/app/oracle/admin/FINDR

# verify

ls -ld /data01/oradata/FINDR /fra01/FINDR /u01/app/oracle/admin/FINDR/adump

→ all 3 lines should show oracle:oinstall ownership:

drwxr-xr-x 2 oracle oinstall 6 Nov 12 09:14 /data01/oradata/FINDR

drwxr-xr-x 2 oracle oinstall 6 Nov 12 09:14 /fra01/FINDR

drwxr-xr-x 2 oracle oinstall 6 Nov 12 09:14 /u01/app/oracle/admin/FINDR/adump

[05] Create password file — must match SYS password on source

# password must match ora-prod-01 SYS password exactly

orapwd file=$ORACLE_HOME/dbs/orapwFINDR \

password=<SYS_PASSWORD> \

entries=5 \

force=y \

format=12

ls -lh $ORACLE_HOME/dbs/orapwFINDR

→ expected:

-rw-r----- 1 oracle oinstall 2.0K Nov 12 09:16 /u01/app/oracle/product/19.3.0/dbhome_1/dbs/orapwFINDR

# WARNING: ORA-01017 during RMAN connect = password mismatch. Recreate orapwd with correct password.

[06] Create minimal pfile — just enough for NOMOUNT

# INFO: Only parameters needed for NOMOUNT. RMAN will set the rest from source spfile during duplicate.

cat > $ORACLE_HOME/dbs/initFINDR.ora << 'EOF'

db_name=FINDR

db_unique_name=FINDR

sga_target=2G

pga_aggregate_target=512M

db_block_size=8192

enable_pluggable_database=false

audit_file_dest=/u01/app/oracle/admin/FINDR/adump

diagnostic_dest=/u01/app/oracle

EOF

cat $ORACLE_HOME/dbs/initFINDR.ora

# INFO: If source is CDB → set enable_pluggable_database=true

[07] Start auxiliary in NOMOUNT

sqlplus / as sysdba

STARTUP NOMOUNT PFILE='/u01/app/oracle/product/19.3.0/dbhome_1/dbs/initFINDR.ora';

→ expected:

SQL> STARTUP NOMOUNT PFILE='...';

ORACLE instance started.

Total System Global Area 2147483648 bytes

Fixed Size 8900952 bytes

Variable Size 503316480 bytes

Database Buffers 1627389952 bytes

Redo Buffers 7876608 bytes

-- validate instance came up

SELECT instance_name, status FROM v$instance;

-- Expected: FINDR STARTED

TNS + LISTENER — AUXILIARY HOST

[08] Add both aliases to tnsnames.ora on auxiliary

vi $ORACLE_HOME/network/admin/tnsnames.ora

# --- append these entries ---

FINPRD =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = ora-prod-01.corp.internal)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = FINPRD)

)

FINDR =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = ora-dr-01.corp.internal)(PORT = 1521))

(CONNECT_DATA =

(SERVER = DEDICATED)

(SERVICE_NAME = FINDR)

)

[09] Configure STATIC listener entry — required while DB is NOMOUNT

# WARNING: Dynamic registration won't work in NOMOUNT. Static SID_LIST entry is mandatory or RMAN connection will fail.

vi $ORACLE_HOME/network/admin/listener.ora

LISTENER =

(DESCRIPTION_LIST =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP)(HOST = ora-dr-01.corp.internal)(PORT = 1521))

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(GLOBAL_DBNAME = FINDR)

(ORACLE_HOME = /u01/app/oracle/product/19.3.0/dbhome_1)

(SID_NAME = FINDR)

)

lsnrctl stop LISTENER

lsnrctl start LISTENER

lsnrctl status LISTENER | grep -A2 'Service\|SID'

→ FINDR will show UNKNOWN — that is normal for static entry in NOMOUNT:

Service "FINDR" has 1 instance(s).

Instance "FINDR", status UNKNOWN, has 1 handler(s) for this service...

[10] Validate TNS + actual login to source before running RMAN

tnsping FINPRD # must be OK

tnsping FINDR # must be OK

# test real connection to source

sqlplus sys/<SYS_PASSWORD>@FINPRD as sysdba

SELECT name, open_mode FROM v$database;

EXIT;

# WARNING: If tnsping OK but sqlplus fails → firewall blocking 1521, or wrong password. Fix before RMAN.

RMAN ACTIVE DUPLICATE

[11] Connect RMAN to both target and auxiliary

# run from ora-dr-01 (auxiliary host)

rman

CONNECT TARGET sys/<SYS_PASSWORD>@FINPRD;

CONNECT AUXILIARY sys/<SYS_PASSWORD>@FINDR;

→ expected:

Recovery Manager: Release 19.0.0.0.0 - Production

connected to target database: FINPRD (DBID=3421876501)

connected to auxiliary database: FINDR (not mounted)

# WARNING: ORA-12541 → listener not running or static entry missing (re-check step 09).

# WARNING: ORA-01017 → password file wrong or not created (re-check step 05).

[12] Execute DUPLICATE — monitor alert log in parallel session

# INFO: Open a second SSH session now and tail the alert log before hitting run.

# --- SECOND TERMINAL (monitor) ---

tail -100f /u01/app/oracle/diag/rdbms/findr/FINDR/trace/alert_FINDR.log

# --- RMAN SESSION (step 11 continued) ---

RUN {

ALLOCATE CHANNEL c1 TYPE DISK;

ALLOCATE CHANNEL c2 TYPE DISK;

ALLOCATE AUXILIARY CHANNEL a1 TYPE DISK;

ALLOCATE AUXILIARY CHANNEL a2 TYPE DISK;

DUPLICATE TARGET DATABASE TO FINDR

FROM ACTIVE DATABASE

SPFILE

PARAMETER_VALUE_CONVERT 'FINPRD','FINDR',

'/data01/oradata/FINPRD','/data01/oradata/FINDR',

'/fra01/FINPRD','/fra01/FINDR'

SET DB_UNIQUE_NAME='FINDR'

SET DB_NAME='FINDR'

SET INSTANCE_NAME='FINDR'

SET AUDIT_FILE_DEST='/u01/app/oracle/admin/FINDR/adump'

SET DIAGNOSTIC_DEST='/u01/app/oracle'

SET DB_FILE_NAME_CONVERT

'/data01/oradata/FINPRD','/data01/oradata/FINDR'

SET LOG_FILE_NAME_CONVERT

'/data01/oradata/FINPRD','/data01/oradata/FINDR'

SET LOG_ARCHIVE_DEST_1='LOCATION=/fra01/FINDR'

SET CONTROL_FILES='/data01/oradata/FINDR/control01.ctl',

'/fra01/FINDR/control02.ctl'

NOFILENAMECHECK;

}

→ last line on success:

Finished Duplicate Db at 12-NOV-2024 11:43:07

# ORA-19505 / ORA-17628 → disk space issue on auxiliary paths

# ORA-01119 → directory missing, re-check step 04

# Channel drops mid-run → network instability or NET_TIMEOUT too low

# workaround: add to RMAN config → CONFIGURE CHANNEL DEVICE TYPE DISK PARAMS 'NET_TIMEOUT=300';

POST-DUPLICATE STEPS

[13] Confirm DB opened — check role, mode, log_mode

sqlplus / as sysdba

SELECT name, db_unique_name, open_mode, log_mode, database_role

FROM v$database;

→ expected:

NAME DB_UNIQUE_NAME OPEN_MODE LOG_MODE DATABASE_ROLE

------ --------------- ----------- ---------- ----------------

FINDR FINDR READ WRITE ARCHIVELOG PRIMARY

[14] Confirm SPFILE is active — not running off pfile

SELECT value FROM v$parameter WHERE name = 'spfile';

-- must return non-null path

-- also check on OS

ls -lh $ORACLE_HOME/dbs/spfileFINDR.ora

# WARNING: If spfile value is NULL → RMAN didn't apply SPFILE clause. Check duplicate command, re-run.

[15] Verify all files are on auxiliary paths — no FINPRD leftover

-- must return ZERO rows

SELECT 'datafile' src, name FROM v$datafile WHERE name LIKE '%FINPRD%'

UNION ALL

SELECT 'tempfile' src, name FROM v$tempfile WHERE name LIKE '%FINPRD%'

UNION ALL

SELECT 'logfile' src, member FROM v$logfile WHERE member LIKE '%FINPRD%';

-- if rows returned → file rename needed before production use

→ expected:

no rows selected

[16] Check redo logs + tempfiles are online

SELECT group#, status, members FROM v$log ORDER BY 1;

-- one group should be CURRENT, others INACTIVE/UNUSED

SELECT file#, name, status FROM v$tempfile;

-- status should be ONLINE

[17] Check invalid objects + registry

SELECT count(*) invalid_obj FROM dba_objects WHERE status='INVALID';

-- compare vs source; minor count is acceptable if same on source

SELECT comp_name, version, status FROM dba_registry ORDER BY comp_name;

-- all components should be VALID

[18] Force listener re-registration + confirm READY

ALTER SYSTEM REGISTER;

-- wait 30 sec then:

-- (from OS)

lsnrctl status LISTENER | grep -A2 FINDR

→ after registration (was UNKNOWN in step 09, now should be READY):

Service "FINDR" has 1 instance(s).

Instance "FINDR", status READY, has 1 handler(s) for this service...

[19] Take immediate backup of controlfile + spfile

rman target /

BACKUP CURRENT CONTROLFILE FORMAT '/fra01/FINDR/cf_%d_%T_%s.bkp';

BACKUP SPFILE FORMAT '/fra01/FINDR/spfile_%d_%T_%s.bkp';

LIST BACKUP SUMMARY;

FINAL VALIDATION — PASTE & RUN

sqlplus / as sysdba << 'EOF'

set linesize 120 pagesize 50

prompt === 1. DB IDENTITY ===

SELECT name, db_unique_name, created FROM v$database;

prompt === 2. OPEN MODE + ROLE ===

SELECT open_mode, database_role, log_mode FROM v$database;

prompt === 3. INSTANCE STATUS ===

SELECT instance_name, status, database_status FROM v$instance;

prompt === 4. REDO LOG STATUS ===

SELECT group#, status, members, bytes/1048576 mb FROM v$log ORDER BY 1;

prompt === 5. TEMP TABLESPACE ===

SELECT tablespace_name, status FROM dba_tablespaces WHERE contents='TEMPORARY';

prompt === 6. CONTROLFILE STATUS ===

SELECT name, status FROM v$controlfile;

prompt === 7. SPFILE IN USE ===

SELECT value FROM v$parameter WHERE name='spfile';

prompt === 8. ARCHIVE DEST STATUS ===

SELECT dest_name, status, target FROM v$archive_dest WHERE status='VALID';

prompt === 9. INVALID OBJECTS COUNT ===

SELECT count(*) invalid_count FROM dba_objects WHERE status='INVALID';

prompt === 10. CURRENT SCN ===

SELECT current_scn FROM v$database;

EXIT;

EOF

# OS-level sanity

ps -ef | grep pmon | grep -i findr # ora_pmon_FINDR must be running

lsnrctl status | grep FINDR # status READY expected

# END OF RUNNER DOC

# Rev: 1.0 | Tested: 19.3.0.0.0 / OL7.9

Oracle Autonomous Database Internals: What Is Really Automated

2026-03-23T11:30:00.001+05:30

Oracle Autonomous Database Internals: What Is Really Automated

Beyond the Marketing - What ADB Actually Does vs What DBAs Still Own

23 March 2026

Chetan Yadav — Senior Oracle & Cloud DBA

⏱️ 13–14 min read

⏱️ Estimated Reading Time: 13–14 minutes

ADW • ATP • Auto-Indexing • Auto-Patching • Auto-Scaling • What DBAs Still Own

⚙️ Environment Referenced in This Article

Service: Oracle Autonomous Database on OCI (Shared & Dedicated Exadata Infrastructure)
Workload Types Tested: ADW, ATP, AJD • Oracle DB Version: 19c base + 23ai features on ADB
Workload: 2.8 TB OLTP + 6.1 TB analytics • Scale: 4–32 ECPU auto-scaling • Region: OCI ap-mumbai-1 primary, ap-hyderabad-1 DR

"The self-driving database." Oracle's marketing for Autonomous Database promises that the DBA is no longer needed — the database manages itself. Patches itself. Tunes itself. Scales itself. After running Oracle ADB in production for financial and analytics workloads across multiple OCI regions, I can tell you the reality is more nuanced and more interesting than the marketing suggests.

Oracle Autonomous Database genuinely automates things that used to consume enormous DBA time — patching, backup, storage management, and a meaningful subset of performance tuning. But it does not eliminate the need for database expertise. It changes what that expertise is applied to. The DBA who understands what ADB actually automates and what it does not will be dramatically more effective than one who takes the "self-driving" claim at face value.

This guide opens the hood on Oracle ADB internals: how auto-indexing actually works, what happens inside auto-patching, when auto-scaling kicks in, and which critical responsibilities remain firmly with the DBA and architect.

 Table of Contents

ADB Architecture: What Runs Under the Hood
Autonomous Data Warehouse (ADW) vs Autonomous Transaction Processing (ATP)
Auto-Indexing: How It Actually Works
Auto-Patching: Zero Downtime or Marketing?
Auto-Scaling: CPU and Storage Elasticity
Auto-Backup and Restore
Security: What Is Automatic and What Is Not
What DBAs Still Own on ADB
ADB Dedicated vs Shared: Architecture Differences
Real Production Lessons from ADB
FAQ
Related Reading from Real Production Systems

1. ADB Architecture: What Runs Under the Hood

Oracle Autonomous Database is Oracle Database Enterprise Edition running on Exadata infrastructure in OCI, with an automation layer built on top that handles operational tasks through machine learning, predefined policies, and Oracle's internal tooling.

It is not a different database engine. It is not a rewrite. The SQL engine, optimizer, PL/SQL runtime, RAC, Data Guard, RMAN — all the same Oracle database internals you know from on-premises. What changes is who manages the operational layer. On-premises, that is you. On ADB, Oracle's automation layer does it.

ADB Stack: Layer by Layer

Layer	Component	Managed By
Hardware	Exadata Bare Metal, NVMe, InfiniBand RDMA	Oracle (fully invisible to customer)
Storage	ASM, Exadata Smart Scan, Flash Cache	Oracle (automatic)
Database Engine	Oracle DB EE 19c/23ai, RAC, Data Guard	Oracle (automatic) + Customer (SQL/schema)
Automation Layer	Auto-index, Auto-patch, Auto-scale, Auto-backup	Oracle (ML-driven policies)
Application Layer	Schema design, SQL quality, connection logic	Customer (DBA / Architect)
OCI Services	VCN, IAM, Object Storage, FastConnect	Customer (Cloud Architect)

SQL — Verify ADB Instance Configuration

-- Check ADB database version and configuration
SELECT banner_full
FROM   v$version;

-- Check ECPU allocation and workload type
SELECT name,
       value
FROM   v$parameter
WHERE  name IN (
    'cpu_count',
    'db_name',
    'db_unique_name',
    'enable_automatic_maintenance_pdb',
    'optimizer_adaptive_statistics'
);

-- Check Data Guard configuration (always on in ADB)
SELECT name,
       db_unique_name,
       database_role,
       protection_mode,
       protection_level
FROM   v$database;

-- Check Exadata Smart Scan eligibility
SELECT name,
       value
FROM   v$sysstat
WHERE  name IN (
    'cell physical IO interconnect bytes',
    'cell physical IO bytes eligible for predicate offload',
    'cell physical IO bytes saved by storage index'
)
ORDER  BY name;

2. ADW vs ATP: Architecture Differences

Oracle offers two primary ADB workload types. The underlying database engine is identical — what differs is the default configuration Oracle applies and the optimizations pre-enabled for each workload pattern.

Feature	ADW (Analytics)	ATP (OLTP)
Default storage format	Hybrid Columnar Compression	Row format (OLTP optimized)
In-Memory Column Store	Auto-enabled, large allocation	Selective, smaller allocation
Parallel query	High DOP, auto-managed	Limited DOP to protect OLTP latency
Smart Scan offload	Aggressively used	Used selectively
Connection type	Dedicated connections	DRCP (connection pooling) default
Auto-indexing	B-tree + bitmap indexes	B-tree indexes only
Auto-partitioning	Yes — detects and creates	Limited
Primary use case	DW, reporting, ML, analytics	App backend, microservices, APIs

Choosing Between ADW and ATP:

The choice matters more than most teams realize. ADW with its columnar compression and Smart Scan offload can be 10–50x faster than ATP for large analytical scans — but ATP handles high-concurrency short OLTP transactions with lower latency. If your workload is mixed (OLTP + reporting), run ATP and use Active Data Guard read offload for the reporting queries, or use ADW with a separate ATP for transaction writes connected via Database Link.

3. Auto-Indexing: How It Actually Works

Auto-indexing is one of the most technically impressive features of Oracle Autonomous Database. It uses machine learning to monitor SQL workloads, identify queries that would benefit from indexes, create candidate indexes invisibly, validate them against real workload queries, and only make them visible if they provide a measurable improvement.

The Auto-Indexing Process Step by Step

Workload Capture: ADB continuously monitors SQL from the cursor cache and AWR, identifying full table scans, high-elapsed-time queries, and repeated access patterns on unindexed columns
Candidate Creation: The auto-indexing engine creates candidate indexes as invisible indexes — they exist in the data dictionary but the optimizer cannot use them yet
Validation: The engine runs the captured SQL statements using SQL plan baselines, forcing the optimizer to consider the invisible index and measuring actual performance improvement
Promotion: If the index improves performance by a meaningful threshold, it is made visible and added to SQL Plan Management baselines
Rejection: If the index does not improve performance or causes regression, it is marked as unusable and eventually dropped
Monitoring: Promoted indexes are continuously monitored; if workload changes and the index is no longer beneficial, it is demoted and dropped automatically

SQL — Monitor Auto-Indexing Activity

-- View auto-index activity report (last 7 days)
SELECT DBMS_AUTO_INDEX.REPORT_ACTIVITY(
    activity_start => SYSDATE - 7,
    activity_end   => SYSDATE,
    type           => 'TEXT',
    section        => 'ALL',
    level          => 'ALL'
) AS report
FROM dual;

-- Check all auto-created indexes and their status
SELECT index_name,
       table_name,
       table_owner,
       auto,
       visibility,
       status,
       last_analyzed,
       num_rows
FROM   dba_indexes
WHERE  auto = 'YES'
ORDER  BY last_analyzed DESC;

-- Check auto-index configuration
SELECT parameter_name,
       parameter_value
FROM   dba_auto_index_config;

-- View indexes created, rejected, or dropped by auto-indexing
SELECT index_name,
       table_name,
       index_type,
       creation_date,
       status,
       rejection_reason
FROM   dba_auto_indexes
ORDER  BY creation_date DESC
FETCH FIRST 30 ROWS ONLY;

-- Configure auto-indexing behaviour (ADMIN user required)
-- Options: 'ON' (default), 'OFF', 'REPORT ONLY'
EXEC DBMS_AUTO_INDEX.CONFIGURE(
    'AUTO_INDEX_MODE', 'ON'
);

Auto-Indexing Production Caution:

Auto-indexing is powerful but not infallible. In one ATP workload running a financial reporting batch, auto-indexing created 47 new indexes over 3 weeks as the batch query patterns changed. Storage consumption grew by 280 GB unexpectedly. The indexes were individually justified but collectively caused excessive index maintenance overhead during bulk inserts, slowing the nightly load by 40%.

Lesson: Monitor auto-index storage growth with dba_auto_indexes weekly. Set schema-level exclusions for bulk-load tables using DBMS_AUTO_INDEX.CONFIGURE('AUTO_INDEX_SCHEMA_EXCLUSION_LIST', 'BATCH_LOAD'). Auto-indexing optimizes for reads — you must protect write-heavy tables manually.

4. Auto-Patching: Zero Downtime or Marketing?

Oracle patches Autonomous Database automatically on a quarterly cadence aligned with the Oracle Critical Patch Update (CPU) schedule. The patching process uses a rolling method across the RAC nodes and Data Guard standby, designed to maintain availability throughout.

How ADB Auto-Patching Works

Oracle patches the Data Guard standby nodes first while the primary continues serving traffic
A planned switchover moves traffic to the patched standby (now acting as new primary)
The old primary nodes are patched
A switchover back occurs (optional — Oracle may leave the new primary in place)
Total connection interruption: typically under 30 seconds per patch cycle

What "Zero Downtime" Actually Means for ADB Patching:

Sessions experience a brief disconnect during the switchover step — typically 5–30 seconds. Applications using Oracle JDBC thin driver with oracle.jdbc.fanEnabled=true and connection pools with retry logic reconnect automatically and users see no interruption. Applications without proper retry logic will surface errors to users during this window. ADB patching is genuinely low-impact — but "zero downtime" depends on your application connection handling.

SQL — Check ADB Patch History and Schedule

-- Check current database patch level
SELECT patch_id,
       patch_uid,
       version,
       action,
       status,
       description,
       action_time
FROM   dba_registry_sqlpatch
ORDER  BY action_time DESC
FETCH FIRST 10 ROWS ONLY;

-- Check current DB version (includes patch level)
SELECT banner_full
FROM   v$version;

-- View recent maintenance window activity
SELECT window_name,
       window_next_time,
       window_active,
       enabled
FROM   dba_scheduler_windows
ORDER  BY window_next_time;

-- Application connection retry best practice (Java JDBC URL)
-- jdbc:oracle:thin:@(DESCRIPTION=
--   (RETRY_COUNT=20)(RETRY_DELAY=3)
--   (ADDRESS=(PROTOCOL=tcps)(PORT=1522)(HOST=adb.region.oraclecloud.com))
--   (CONNECT_DATA=(SERVICE_NAME=your_service_high))
--   (SECURITY=(SSL_SERVER_DN_MATCH=yes)))

5. Auto-Scaling: CPU and Storage Elasticity

ADB auto-scaling allows the database to temporarily use up to 3x its base ECPU allocation when demand spikes, without manual intervention. Storage auto-scales continuously — there is no pre-allocation and no storage ceiling to manage.

How CPU Auto-Scaling Works

Base ECPU: The number of ECPUs you provision and pay for at baseline rate
Scale-up trigger: When CPU utilisation exceeds ~80% for a sustained period
Maximum burst: Up to 3x base ECPU (e.g., 8 ECPU base → up to 24 ECPU burst)
Billing: Burst ECPUs billed at per-second rate only while in use
Scale-down: Automatic when load subsides — no manual action required

SQL — Monitor ADB CPU Utilisation and Auto-Scaling

-- Monitor current CPU usage
SELECT metric_name,
       value,
       metric_unit
FROM   v$con_sysmetric
WHERE  metric_name IN (
    'CPU Usage Per Sec',
    'CPU Usage Per Call',
    'Database CPU Time Ratio'
)
ORDER  BY metric_name;

-- Check ECPU allocation (current + max scaling limit)
SELECT name,
       value
FROM   v$parameter
WHERE  name IN ('cpu_count', 'parallel_max_servers');

-- Historical CPU utilisation (last 7 days from AWR)
SELECT TO_CHAR(begin_interval_time, 'YYYY-MM-DD HH24') AS hour,
       ROUND(AVG(value), 2)                             AS avg_cpu_pct
FROM   dba_hist_sysmetric_summary
WHERE  metric_name        = 'Database CPU Time Ratio'
AND    begin_interval_time > SYSDATE - 7
GROUP  BY TO_CHAR(begin_interval_time, 'YYYY-MM-DD HH24')
ORDER  BY hour;

-- Monitor active sessions and concurrency
SELECT status,
       COUNT(*) AS session_count
FROM   v$session
WHERE  type = 'USER'
GROUP  BY status
ORDER  BY session_count DESC;

6. Auto-Backup and Restore

ADB performs automatic daily backups to OCI Object Storage. Backups use incremental-forever methodology — a full backup followed by daily incrementals merged into a rolling backup set. Point-in-time recovery (PITR) is available to any second within the retention window.

Backup Feature	ADB Default	On-Premises Equivalent
Backup type	Automatic daily incremental	RMAN scheduled backup job
Retention	60 days (configurable)	DBA-defined
Storage	OCI Object Storage (included)	Tape / disk / cloud (DBA managed)
PITR granularity	Any second within retention	Depends on redo log archival
Restore initiation	OCI Console or REST API	RMAN restore command
Restore time (1 TB)	~45–90 minutes typical	Depends on storage bandwidth
Cross-region backup	Automatic (optional)	DBA-configured RMAN duplication

SQL — Monitor ADB Backup Status

-- Check RMAN backup history on ADB
SELECT session_key,
       session_stamp,
       input_type,
       status,
       TO_CHAR(start_time,  'YYYY-MM-DD HH24:MI') AS start_time,
       TO_CHAR(end_time,    'YYYY-MM-DD HH24:MI') AS end_time,
       input_bytes_display,
       output_bytes_display,
       compression_ratio
FROM   v$rman_backup_job_details
ORDER  BY start_time DESC
FETCH FIRST 10 ROWS ONLY;

-- Check oldest available recovery point
SELECT *
FROM   v$restore_point
ORDER  BY time DESC;

-- Verify archive log mode (always on in ADB)
SELECT log_mode,
       archiver
FROM   v$database;

7. Security: What Is Automatic and What Is Not

Security Features Fully Automated in ADB

AUTO Transparent Data Encryption (TDE): Always on, cannot be disabled, Oracle-managed keys by default
AUTO Network encryption: TLS 1.2+ enforced for all connections, no plain-text allowed
AUTO Unified Auditing: Default audit policy enabled automatically
AUTO Database Vault: Prevents privileged user access to application data by default on ADB
AUTO Key rotation: Automatic on a defined schedule unless customer-managed keys (BYOK) are used

Security Responsibilities That Remain With You

DBA VCN and Network Security Groups: You define which IP ranges can reach the ADB endpoint
DBA IAM Policies: Who in your OCI tenancy can start, stop, or delete the ADB instance
DBA Database user management: Creating users, granting privileges, managing roles
DBA Data classification: What data is sensitive, where it lives, GDPR/compliance mapping
DBA Customer-managed encryption keys (BYOK): If compliance requires your own keys, you manage the OCI Vault integration
DBA Application-level access control: Row-level security, VPD policies, column-level encryption for ultra-sensitive fields

8. What DBAs Still Own on ADB

This is the most important section of this guide. Oracle's marketing implies the DBA role disappears with ADB. The reality is the role changes — from operational firefighting to architectural decision-making. These responsibilities remain firmly with the DBA and architect.

Schema and Data Design

Table structure, normalization level, partition strategy
Data type selection — ADB cannot fix a VARCHAR2 column that should be a NUMBER
Referential integrity decisions — enforce in DB or application?
JSON vs relational vs duality view design choices

SQL and Application Quality

Application SQL efficiency — ADB auto-indexes help but cannot rewrite bad SQL
Bind variable usage — literal SQL still causes hard parse overhead on ADB
Bulk operation design — row-by-row PL/SQL loops are still slow on ADB
Connection pool configuration — pool sizing and retry logic remain application concerns

Cost Governance

Right-sizing ECPU allocation — over-provisioning wastes significant budget
Auto-scaling budget caps — without limits, burst billing can be surprising
Storage tier selection — Standard vs High Performance storage pricing differences
Cross-region backup costs — Object Storage egress charges for DR backups

Migration and Integration

Source data extraction, transformation, and loading logic
Cutover planning and rollback strategy
Application compatibility testing against ADB restrictions
Integration with non-Oracle systems (Kafka, S3, REST APIs)

9. ADB Dedicated vs Shared: Architecture Differences

Oracle offers two deployment models for ADB. The choice has significant implications for isolation, performance, customization, and cost.

Feature	ADB Shared	ADB Dedicated
Infrastructure	Shared Exadata fleet (multi-tenant)	Dedicated Exadata Cloud@Customer or OCI
Isolation	Logical (PDB isolation)	Physical (dedicated hardware)
Customization	Limited (Oracle controls most params)	Higher (DBA can set more parameters)
Patching control	Oracle-managed schedule	Customer-controlled patching window
Network	Public endpoint or private endpoint	Always private, on customer VCN
Compliance	Suitable for most enterprise needs	Required for FedRAMP, HIPAA BAA, PCI DSS
Cost model	Pay per ECPU + storage (elastic)	Reserved capacity (higher baseline cost)
Best for	Dev/test, departmental, new projects	Regulated industries, large enterprise OLTP

10. Real Production Lessons from ADB

Incident 1: Auto-Scaling Surprise Bill

A retail analytics team provisioned a 4-ECPU ADW instance for a proof of concept. During a Black Friday data load test, auto-scaling kicked in and the instance burst to 12 ECPUs for 6 hours. The month-end OCI bill was 4x the expected baseline.

Lesson: Always set OCI Budget Alerts on your ADB compartment and configure the isAutoScalingEnabled flag deliberately. For cost-sensitive environments, disable auto-scaling and size ECPU appropriately for peak load. For production, enable auto-scaling but set OCI Budget alerts at 120% of expected monthly cost.

Incident 2: Application Not Handling Patching Reconnect

A Node.js microservice using oracledb thin driver connected to ATP without connection pool retry logic. During the quarterly ADB patch switchover, sessions were dropped. The application surfaced 503 errors to users for 25 seconds before the operations team noticed and restarted the connection pool manually.

Lesson: Test your application connection handling against ADB switchover before go-live. Use oracle.jdbc.fanEnabled=true for Java, configure poolPingInterval for Node.js, and always implement exponential backoff retry logic for database connections in any cloud-native application.

Success: Auto-Indexing Eliminated a Manual DBA Cycle

On an ADW instance serving financial dashboards, auto-indexing identified and created 12 indexes over the first 3 weeks of production traffic — indexes that our team had not identified during pre-production testing because the production query pattern differed from our test workload. The slowest dashboard query dropped from 14 seconds to 0.8 seconds without any DBA intervention. Auto-indexing validation prevented 2 of these indexes from being promoted because they caused regression on other queries — exactly the safety mechanism that makes it trustworthy.

11. FAQ

Can I run custom Oracle features on ADB that I use on-premises?

Most features work. Oracle Spatial, Oracle Text, APEX, Oracle ML, partitioning, advanced compression, and JSON features are all available. Some features are restricted or not available: you cannot create external tables pointing to arbitrary file paths (must use Object Storage), you cannot directly access the OS, and some init.ora parameters are locked. ADB Dedicated gives more flexibility than ADB Shared for parameter customization. Always test your specific feature requirements in ADB Free tier before committing to production migration.

Does ADB eliminate the need for a DBA?

No — but it changes the DBA role significantly. Routine operational tasks (patching, backup, storage management, basic performance tuning) are genuinely automated. What remains: schema design, SQL quality governance, cost management, security policy, migration planning, application integration, and capacity planning. In practice, one DBA can manage significantly more ADB instances than on-premises databases because the operational overhead per database is much lower. The DBA role shifts from operational to architectural.

How does ADB handle high availability?

ADB Shared runs on Oracle RAC with Data Guard in Maximum Availability mode by default. This provides node-level failover (RAC) and site-level failover (Data Guard) transparently. The SLA is 99.995% availability for ADB Shared on OCI. For ADB Dedicated, the HA architecture depends on your Exadata Infrastructure configuration — you can configure multi-AD (Availability Domain) deployment for even higher isolation. Failover is transparent to properly configured applications using Oracle connection retry features.

Should I mention ADB experience on my resume?

Yes — and frame it around what you governed, not just what Oracle automated. Write: "Architected and governed Oracle ADB ADW and ATP deployments on OCI for analytics and OLTP workloads. Managed auto-indexing policy, ECPU cost governance, VCN security configuration, and ADB Dedicated deployment for PCI DSS compliance. Migrated 6.1 TB on-premises Oracle 19c warehouse to ADW with zero data loss using Oracle Data Pump and GoldenGate." Employers hiring for cloud DBA roles want to see architectural judgment, not just familiarity with the OCI console.

About the Author

Chetan Yadav

Chetan has designed and governed Oracle ADB deployments across OCI for financial, analytics, and OLTP workloads , including ADB Dedicated for PCI DSS compliance and ADB Shared for elastic analytics platforms. His writing focuses on what actually works in production and what the marketing materials leave out.

This blog focuses on real-world DBA problems, career growth, and practical learning , not theoretical documentation or vendor marketing.

Step-by-step installation of Oracle Database 19c (64-bit) on Red Hat Enterprise Linux 9.4

2026-03-16T15:20:00.001+05:30

Oracle Database 19c Installation Runner

Platform: RHEL 9.4 (64-bit)

Step-by-step installation of Oracle Database 19c (64-bit) on Red Hat Enterprise Linux 9.4.

1. Assumed the Installer is downloaded

File name:

LINUX.X64_193000_db_home.zip

Upload it to the server

/stage/oracle/LINUX.X64_193000_db_home.zip

2. Configure Hostname

hostname.

hostnamectl

3. Configure /etc/hosts

Edit hosts file.

vi /etc/hosts

4. Install Oracle Preinstall Package

Configure prerequisites

dnf install -y oracle-database-preinstall-19c

*Note :(this pre install steps will automatically create the require user, group and required lib and rpm)

5. Configure SELinux

Edit SELinux configuration.

vi /etc/selinux/config

Set:

SELINUX=permissive

Apply immediately:

setenforce 0

6. Disable Firewall

Stop firewall.

systemctl stop firewalld

systemctl disable firewalld

7. Create Oracle Directory Structure

Create Oracle installation directories using your custom path.

mkdir -p /Chetan/practice/u01/app/oracle/product/19.0.0/dbhome_1

mkdir -p /Chetan/practice/u02/oradata

Set ownership.

chown -R oracle:oinstall /Chetan

chmod -R 775 /Chetan

8. Configure Oracle Environment

su - oracle

Create scripts directory.

mkdir ~/scripts

Create environment script.

vi ~/scripts/setEnv.sh

Add:

export TMP=/tmp

export TMPDIR=$TMP

export ORACLE_HOSTNAME=rhel9-oracle.localdomain

export ORACLE_BASE=/Chetan/practice/u01/app/oracle

export ORACLE_HOME=$ORACLE_BASE/product/19.0.0/dbhome_1

export ORACLE_SID=cdb1

export PDB_NAME=pdb1

export DATA_DIR=/Chetan/practice/u02/oradata

export PATH=$ORACLE_HOME/bin:$PATH

export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib

Load environment automatically.

echo ". ~/scripts/setEnv.sh" >> ~/.bash_profile

Reload profile.

source ~/.bash_profile

9. Extract Oracle Software

Navigate to Oracle Home.

cd /Chetan/practice/u01/app/oracle/product/19.0.0/dbhome_1

Unzip software.

unzip -oq /stage/oracle/LINUX.X64_193000_db_home.zip

10 . Run Oracle Installer

Start installer.

./runInstaller

Select:

Install Database Software Only

Edition: Enterprise Edition

Oracle Base:

/Chetan/practice/u01/app/oracle

Oracle Home:

/Chetan/practice/u01/app/oracle/product/19.0.0/dbhome_1

________________________________________

11. Start Oracle Listener

Switch to oracle user.

Start listener.

lsnrctl start

Verify listener.

lsnrctl status

________________________________________

12. Create Database Using DBCA

Run Database Configuration Assistant.

dbca

Select:

Create Database

General Purpose Database

Create Container Database

Example configuration:

SID:

cdb1

PDB:

pdb1

Datafile location:

/Chetan/practice/u02/oradata

13. Verify Database

Connect to database.

sqlplus / as sysdba

Check database.

select name, open_mode from v$database;

Check PDB.

show pdbs;

Installation Completed

Oracle Database 19c is now successfully installed.

Oracle Home:

/Chetan/practice/u01/app/oracle/product/19.0.0/dbhome_1

Database files:

/Chetan/practice/u02/oradata

Oracle Database 23ai Architecture: AI-Native Internals for DBAs

2026-03-16T11:00:00.002+05:30

Oracle Database 23ai Architecture: AI-Native Internals for DBAs

What Actually Changed Inside the Engine — Beyond the Marketing

16 March 2026

Chetan Yadav — Senior Oracle & Cloud DBA

⏱️ 11–12 min read

⏱️ Estimated Reading Time: 11–12 minutes

AI Vector Search • Select AI • JSON Duality • True Cache • SQL Domains • Lock-Free Reservations

⚙️ Environment Used in This Article

Oracle Database: 23ai (23.4) Enterprise Edition • Platform: Oracle Linux 8.9 on OCI & on-premises x86
Workload: Mixed OLTP + AI/ML vector search workloads • DB Size: 4.2 TB
New Features Tested: AI Vector Search, Select AI, JSON Duality Views, True Cache, SQL Domains, Lock-Free Reservations, Boolean datatype, Schema Privileges

Oracle called it "23ai" for a reason. This is not a routine point release with incremental improvements. The AI suffix signals a deliberate architectural shift — Oracle has embedded AI capabilities directly into the database engine itself, not as an external add-on or middleware layer.

But for DBAs and architects the most important question is not "what did Oracle announce?" It is "what actually changed inside the engine, and what does that mean for how I design, tune, and operate my databases?" The marketing materials will tell you Oracle 23ai is revolutionary. This guide will tell you which features are genuinely production-ready, which ones still need maturity, and what the internal architecture changes mean for your workload.

I have tested Oracle 23ai extensively on both OCI and on-premises environments running real OLTP and vector workloads. This guide reflects what I found in practice, not what the release notes promise.

 Table of Contents

What “AI-Native” Actually Means Architecturally
AI Vector Search: VECTOR Datatype and Similarity Search
Select AI: Natural Language to SQL Inside the Database
JSON Relational Duality Views
True Cache: In-Memory Caching Without Application Changes
SQL and Developer Enhancements
Security Enhancements: Schema Privileges and Lock-Free Reservations
Core Engine Changes DBAs Need to Know
What Is Production-Ready and What Is Not
Migration and Upgrade Considerations
FAQ
Related Reading from Real Production Systems

1. What “AI-Native” Actually Means Architecturally

Previous Oracle releases added AI/ML capabilities as external integrations. You called Python scripts from PL/SQL, pushed data to OML (Oracle Machine Learning) services, or used Oracle Data Miner as a separate GUI tool. The database was the data store; the AI happened outside it.

Oracle 23ai changes this in a fundamental way. The new VECTOR datatype is a first-class database type stored and indexed natively in the database engine. Similarity search is executed inside the SQL engine using the same optimizer infrastructure that handles every other query. Select AI translates natural language directly to SQL using an LLM integration configured as an AI Profile — entirely inside a database session. There is no ETL to an external AI service and back.

The Three Architectural Shifts in 23ai

Shift	Before 23ai	In 23ai
Vector / Embedding Storage	BLOB or external vector DB (Pinecone, Weaviate)	Native VECTOR datatype, indexed in-engine
AI Inference	External API call from application layer	Select AI — LLM called from SQL session
Data Access Model	Relational OR document (separate systems)	JSON Duality Views — both simultaneously, same data

DBA Perspective:

From a DBA standpoint, the most operationally significant change in 23ai is not Select AI or Vector Search. It is Lock-Free Reservations and True Cache — two features that directly address the most painful OLTP scalability problems DBAs have dealt with for decades. The AI features get the headlines; these two features will have more immediate impact on production workload performance.

2. AI Vector Search: VECTOR Datatype and Similarity Search

Oracle AI Vector Search introduces a native VECTOR datatype that stores high-dimensional embedding vectors directly in Oracle Database tables. Combined with vector indexes (HNSW and IVF), this enables approximate nearest-neighbour (ANN) similarity searches entirely within SQL.

How It Works Internally

When you define a column as VECTOR, Oracle stores the embedding as a fixed or variable-length array of floating point numbers (FLOAT32, FLOAT64, or INT8 quantized). Vector indexes use Hierarchical Navigable Small World (HNSW) graphs or Inverted File (IVF) partitioning — the same algorithms used by dedicated vector databases like Pinecone and Weaviate, but executed inside Oracle's buffer cache and I/O subsystem.

SQL — Create Table with VECTOR Column and Vector Index

-- Create table with native VECTOR datatype
-- VECTOR(dimensions, format): 1536 dims = OpenAI text-embedding-ada-002
CREATE TABLE product_embeddings (
    product_id    NUMBER         PRIMARY KEY,
    product_name  VARCHAR2(400)  NOT NULL,
    description   CLOB,
    embedding     VECTOR(1536, FLOAT32)   -- 1536-dimension OpenAI embedding
);

-- Create HNSW vector index (best for high-recall similarity search)
CREATE VECTOR INDEX prod_emb_hnsw_idx
    ON product_embeddings (embedding)
    ORGANIZATION INMEMORY NEIGHBOR GRAPH
    DISTANCE     COSINE
    WITH TARGET ACCURACY 95;

-- Create IVF vector index (better for large datasets, lower memory)
CREATE VECTOR INDEX prod_emb_ivf_idx
    ON product_embeddings (embedding)
    ORGANIZATION NEIGHBOR PARTITIONS
    DISTANCE     COSINE
    WITH TARGET ACCURACY 90;

SQL — Similarity Search with VECTOR_DISTANCE and Hybrid Filter

-- Pure vector similarity search: top 5 most similar products
SELECT product_id,
       product_name,
       VECTOR_DISTANCE(embedding, :query_vector, COSINE)  AS similarity_score
FROM   product_embeddings
ORDER  BY similarity_score
FETCH FIRST 5 ROWS ONLY;

-- Hybrid search: combine vector similarity WITH relational filter
-- This is the key advantage over standalone vector databases
SELECT p.product_id,
       p.product_name,
       p.category,
       p.price,
       VECTOR_DISTANCE(e.embedding, :query_vector, COSINE)  AS similarity
FROM   product_embeddings  e
JOIN   products            p ON e.product_id = p.product_id
WHERE  p.category    = 'Electronics'
AND    p.price       < 500
AND    p.stock_qty   > 0
ORDER  BY similarity
FETCH APPROX FIRST 10 ROWS ONLY
    WITH TARGET ACCURACY 90;

-- Check vector index usage in execution plan
EXPLAIN PLAN FOR
    SELECT product_id,
           VECTOR_DISTANCE(embedding, :query_vector, COSINE) AS score
    FROM   product_embeddings
    ORDER  BY score
    FETCH FIRST 5 ROWS ONLY;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

Production Test Result — Hybrid Vector + Relational Search:

On a 4.2 TB database with 12 million product embeddings (1536 dimensions, FLOAT32), a hybrid query combining VECTOR_DISTANCE similarity with 3 relational filters (category, price range, stock) completed in 18 ms average using the HNSW index with 95% target accuracy. The equivalent workflow using a separate vector database + relational join via application layer took 340 ms due to the round-trip overhead. This is the genuine architectural advantage of in-database vector search.

3. Select AI: Natural Language to SQL Inside the Database

Select AI allows users to query the database using natural language. Oracle translates the question into SQL using a configured LLM (OpenAI, Cohere, Azure OpenAI, or OCI Generative AI) and executes the resulting query against the actual database. The translation happens inside the database session — not in the application layer.

How Select AI Works Internally

DBA creates an AI Profile defining the LLM provider, credentials, and which schema objects the LLM can see
User runs SELECT AI <natural language question> in a SQL session
Oracle sends the question plus schema metadata (table names, column names, comments) to the LLM
LLM returns a SQL statement
Oracle executes that SQL and returns results to the user
Optionally the generated SQL is logged for auditing and review

SQL — Configure Select AI Profile and Run Natural Language Query

-- Step 1: Create credential for LLM provider (OpenAI example)
BEGIN
    DBMS_CLOUD.CREATE_CREDENTIAL(
        credential_name => 'OPENAI_CRED',
        username        => 'openai',
        password        => 'sk-your-openai-api-key-here'
    );
END;
/

-- Step 2: Create AI Profile defining the LLM and accessible schema
BEGIN
    DBMS_CLOUD_AI.CREATE_PROFILE(
        profile_name => 'SALES_AI_PROFILE',
        attributes   =>
            '{ "provider"         : "openai",
               "credential_name"  : "OPENAI_CRED",
               "object_list"      : [{"owner": "SALES", "name": "ORDERS"},
                                     {"owner": "SALES", "name": "CUSTOMERS"},
                                     {"owner": "SALES", "name": "PRODUCTS"}],
               "model"            : "gpt-4" }'
    );
END;
/

-- Step 3: Set profile for the session
EXEC DBMS_CLOUD_AI.SET_PROFILE('SALES_AI_PROFILE');

-- Step 4: Query in natural language
SELECT AI what were the top 10 products by revenue last quarter;

-- See the SQL that was generated (narrate mode)
SELECT AI NARRATE what were the top 10 products by revenue last quarter;

-- Show only the generated SQL without executing
SELECT AI SHOWSQL what were the top 10 products by revenue last quarter;

Select AI Production Caution:

Select AI is powerful but has real risks in production. The LLM-generated SQL can produce full table scans, missing bind variables, or inefficient join orders on complex schemas. In one test, a natural language query about "monthly trends" generated a query with 4 full table scans on tables with 50M+ rows. Always configure the AI Profile with object_list restricted to only the tables users should access, enable SQL logging, and consider a query approval workflow before using Select AI for production reporting. It is best suited for internal analytics and data exploration — not for customer-facing applications yet.

4. JSON Relational Duality Views

JSON Relational Duality Views are one of the most architecturally significant features in 23ai. They allow the same data to be accessed simultaneously as relational tables (SQL) and as JSON documents (REST/MongoDB API) without any data duplication or synchronization overhead.

The data is stored once in normalized relational tables. The duality view is a virtual layer that presents the relational data as JSON documents for document-oriented access, and as rows for relational access. Any write through either interface updates the same underlying relational storage.

SQL — Create and Query a JSON Duality View

-- Underlying relational tables (unchanged)
CREATE TABLE orders (
    order_id     NUMBER         PRIMARY KEY,
    customer_id  NUMBER         NOT NULL,
    order_date   DATE           DEFAULT SYSDATE,
    status       VARCHAR2(20)
);

CREATE TABLE order_items (
    item_id      NUMBER         PRIMARY KEY,
    order_id     NUMBER         REFERENCES orders(order_id),
    product_id   NUMBER,
    quantity     NUMBER,
    unit_price   NUMBER(10,2)
);

-- Create JSON Duality View over the relational tables
CREATE OR REPLACE JSON RELATIONAL DUALITY VIEW orders_dv AS
    SELECT JSON {
        '_id'       : o.order_id,
        'orderDate' : o.order_date,
        'status'    : o.status,
        'items'     : [
            SELECT JSON {
                'itemId'    : i.item_id,
                'productId' : i.product_id,
                'quantity'  : i.quantity,
                'unitPrice' : i.unit_price
            }
            FROM order_items i WITH INSERT UPDATE DELETE
            WHERE i.order_id = o.order_id
        ]
    }
    FROM orders o WITH INSERT UPDATE DELETE;

-- Access as JSON document (MongoDB-style)
SELECT json_serialize(data PRETTY)
FROM   orders_dv
WHERE  json_value(data, '$.status') = 'PENDING';

-- Access via REST / SODA API: GET /ords/sales/orders_dv/
-- Access as relational SQL simultaneously:
SELECT o.order_id,
       oi.quantity,
       oi.unit_price
FROM   orders      o
JOIN   order_items oi ON o.order_id = oi.order_id
WHERE  o.status = 'PENDING';

5. True Cache: In-Memory Caching Without Application Changes

True Cache is a new 23ai feature that provides a read-only in-memory cache of frequently accessed data, automatically synchronized with the primary database. Unlike Oracle In-Memory Column Store (IMCS) which is a columnar analytic cache, True Cache operates at the block level — caching the same blocks the primary database serves, making it transparent to all existing SQL.

The key architectural advantage: no application changes required. True Cache sits between the application and the primary database. The application connects normally. Oracle routes qualifying read queries to the True Cache node automatically. There is no cache warming logic, no cache invalidation code, and no TTL configuration in the application.

True Cache vs Oracle In-Memory vs Oracle Database In-Memory

Feature	True Cache	Buffer Cache	In-Memory Col. Store
Format	Row (block-level)	Row (block-level)	Columnar
Consistency	Guaranteed (sync with primary)	Always consistent	Always consistent
Separate host	Yes — dedicated instance	No — same instance	No — same instance
App changes needed	None	None	None
Best for	Read offload, OLTP scale-out	General workload	Analytic scan queries
License	Included in EE	Included	Separate option

6. SQL and Developer Enhancements

Oracle 23ai includes a significant number of SQL engine enhancements that reduce boilerplate code and simplify application development.

SQL Domains NEW

SQL Domains allow you to define reusable data types with built-in constraints, default values, and display formats that can be applied to any column across any table.

SQL — SQL Domains, Boolean Datatype, IF EXISTS, Table Value Constructor

-- SQL DOMAINS: reusable column type with built-in rules
CREATE DOMAIN email_domain AS VARCHAR2(254)
    CONSTRAINT email_chk CHECK (VALUE LIKE '%@%.%')
    DISPLAY    LOWER(VALUE)
    ORDER      LOWER(VALUE);

CREATE DOMAIN status_domain AS VARCHAR2(20)
    CONSTRAINT status_chk CHECK (VALUE IN
        ('PENDING','ACTIVE','SUSPENDED','CLOSED'));

-- Apply domain to a column
CREATE TABLE customers (
    customer_id  NUMBER          PRIMARY KEY,
    email        email_domain    NOT NULL,
    status       status_domain   DEFAULT 'PENDING'
);

-- BOOLEAN DATATYPE: native TRUE/FALSE (no more NUMBER(1) workaround)
CREATE TABLE feature_flags (
    flag_name    VARCHAR2(100)   PRIMARY KEY,
    is_enabled   BOOLEAN         DEFAULT FALSE,
    is_beta      BOOLEAN         DEFAULT TRUE
);

INSERT INTO feature_flags VALUES ('AI_SEARCH', TRUE,  FALSE);
INSERT INTO feature_flags VALUES ('DARK_MODE', FALSE, TRUE);

SELECT flag_name,
       is_enabled,
       is_beta
FROM   feature_flags
WHERE  is_enabled = TRUE;

-- IF [NOT] EXISTS: DDL without errors on missing/existing objects
DROP TABLE IF EXISTS temp_staging;          -- no error if not exists
CREATE TABLE IF NOT EXISTS audit_log (      -- no error if already exists
    log_id    NUMBER GENERATED ALWAYS AS IDENTITY,
    log_time  TIMESTAMP DEFAULT SYSTIMESTAMP,
    message   VARCHAR2(4000)
);

-- TABLE VALUE CONSTRUCTOR: inline values without DUAL
SELECT *
FROM   (VALUES (1, 'Alice', 'Admin'),
               (2, 'Bob',   'User'),
               (3, 'Carol', 'DBA'))
       AS team_members (id, name, role);

-- ANNOTATIONS: metadata on schema objects, queryable from data dictionary
CREATE TABLE orders (
    order_id   NUMBER    ANNOTATIONS (display_name 'Order ID',
                                      description  'Unique order identifier'),
    amount     NUMBER    ANNOTATIONS (display_name 'Amount',
                                      format       'CURRENCY',
                                      precision    2)
) ANNOTATIONS (module 'Sales', owner 'sales_team');

-- Query annotations from data dictionary
SELECT column_name,
       annotation_name,
       annotation_value
FROM   user_annotations_usage
WHERE  object_name = 'ORDERS'
ORDER  BY column_name, annotation_name;

7. Security Enhancements: Schema Privileges and Lock-Free Reservations

Schema-Level Privileges NEW

Before 23ai, granting a user access to all objects in a schema required granting privileges on each object individually — or granting broad system privileges. In 23ai, you can grant a privilege on an entire schema in one command. New objects added to the schema automatically inherit the privilege.

SQL — Schema Privileges and Lock-Free Reservations

-- SCHEMA PRIVILEGES: grant on entire schema (new in 23ai)
-- All tables, views, procedures in SALES schema — current AND future
GRANT SELECT ANY TABLE ON SCHEMA sales TO reporting_user;
GRANT INSERT, UPDATE    ON SCHEMA sales TO app_user;
GRANT EXECUTE           ON SCHEMA sales TO etl_user;

-- Verify schema privilege grants
SELECT grantee,
       privilege,
       schema_name
FROM   dba_schema_privs
WHERE  schema_name = 'SALES'
ORDER  BY grantee, privilege;

-- LOCK-FREE RESERVATIONS: reserve numeric values without row-level locks
-- Classic problem: inventory deduction causes massive lock contention
-- Old approach (causes row lock on every UPDATE):
-- UPDATE inventory SET qty = qty - :deduct WHERE product_id = :pid;

-- 23ai approach: reserve first, deduct asynchronously
-- Step 1: Define reservation on the column
ALTER TABLE inventory
    ADD CONSTRAINT inv_qty_reserve
    CHECK (qty >= 0) DEFERRABLE INITIALLY DEFERRED;

-- Create reservation column (Oracle manages this internally)
-- Applications use DBMS_RESERVATION package
BEGIN
    DBMS_RESERVED_WORDS.RESERVE(
        table_name  => 'INVENTORY',
        column_name => 'QTY',
        amount      => :deduct_amount,
        row_key     => :product_id
    );
END;
/

-- Result: multiple sessions can reserve simultaneously
-- without blocking each other on the same row
-- Oracle reconciles reservations asynchronously

Lock-Free Reservations — Production Impact:

In an e-commerce inventory system with 50,000 concurrent order sessions all updating the same high-demand product rows, traditional row-level locking produced enq: TX - row lock contention as the top wait event and capped throughput at 800 TPS. After implementing Lock-Free Reservations on the inventory quantity column, the same workload processed at 4,200 TPS with lock contention dropping to near zero. This is the single biggest OLTP scalability improvement in 23ai for write-heavy workloads.

8. Core Engine Changes DBAs Need to Know

Multivalue Indexes on JSON Arrays NEW

Before 23ai, indexing individual elements of a JSON array required a function-based index on each element. 23ai introduces multivalue indexes that index all elements of a JSON array in a single index structure.

SQL — Multivalue Index, Real-Time Statistics, Automatic Indexing

-- MULTIVALUE INDEX: index all elements of a JSON array
CREATE TABLE orders_json (
    order_id  NUMBER PRIMARY KEY,
    order_doc JSON
);

-- Single index covers ALL tag values in the array
CREATE MULTIVALUE INDEX ord_tags_idx
    ON orders_json o (o.order_doc.tags[*].value.string());

-- This query now uses the multivalue index:
SELECT order_id
FROM   orders_json
WHERE  'PRIORITY' MEMBER OF (order_doc.tags[*].value.string());

-- REAL-TIME STATISTICS: statistics updated during DML (19c+, enhanced 23ai)
-- Check if real-time stats are enabled
SELECT name,
       value
FROM   v$parameter
WHERE  name IN ('optimizer_real_time_statistics',
                'statistics_level');

-- Monitor statistics staleness
SELECT table_name,
       last_analyzed,
       num_rows,
       stale_stats
FROM   user_tab_statistics
WHERE  stale_stats = 'YES'
ORDER  BY last_analyzed;

-- AUTOMATIC INDEXING: check auto index recommendations (19c+)
SELECT index_name,
       table_name,
       creation_date,
       status,
       index_type
FROM   dba_auto_indexes
ORDER  BY creation_date DESC
FETCH FIRST 20 ROWS ONLY;

-- Review auto index activity report
SELECT DBMS_AUTO_INDEX.REPORT_ACTIVITY(
    activity_start => SYSDATE - 7,
    activity_end   => SYSDATE,
    type           => 'TEXT',
    section        => 'ALL',
    level          => 'ALL'
) AS report
FROM dual;

Key Init.ora / SPFILE Parameters for 23ai

Parameter	Recommended Value	Purpose
`vector_memory_size`	4G – 16G	Memory pool for HNSW vector indexes
`optimizer_real_time_statistics`	TRUE	Update stats during DML operations
`true_cache_enabled`	TRUE	Enable True Cache feature
`json_duality_strict_on_drop`	FALSE	Allow drop of underlying tables with active duality views
`dg_broker_start`	TRUE	Auto-start Data Guard broker (unchanged from 19c)
`enable_automatic_maintenance_pdb`	INHERIT	PDB-level control of auto tasks

9. What Is Production-Ready and What Is Not

Production-Ready in 23ai (tested and stable):

SQL Domains — stable, well-integrated with data dictionary
Boolean datatype — straightforward, no operational concerns
IF [NOT] EXISTS DDL — safe to use immediately
Schema-Level Privileges — significant DBA time saver, stable
JSON Duality Views — stable for new applications, test thoroughly before migrating existing
Annotations — metadata only, zero risk
Real-Time Statistics enhancements — proven since 19c

Use with Caution (evaluate carefully for your workload):

AI Vector Search — production-ready for new workloads; performance tuning of HNSW vs IVF still requires testing per dataset
Lock-Free Reservations — powerful but requires application design changes; test under load before production rollout
True Cache — early release; validate cache consistency behaviour under failover scenarios
Multivalue Indexes — test index size growth carefully on large JSON arrays

Not Yet Recommended for Production:

Wait Select AI for customer-facing or regulated workloads — LLM-generated SQL is non-deterministic and cannot be pre-approved by query review. Use for internal analytics only with full SQL logging enabled.

Wait True Cache for primary DR role — True Cache failover behaviour under primary outage needs more production validation at scale. Do not replace Active Data Guard with True Cache for HA purposes yet.

10. Migration and Upgrade Considerations

Upgrading to Oracle 23ai from 19c or 21c requires the same disciplined approach as any major version upgrade.

SQL — Pre-Upgrade Checks and Compatibility Verification

-- Run Oracle Pre-Upgrade Utility before upgrading
-- Download from MOS Note 884522.1
-- java -jar preupgrade.jar TERMINAL TEXT

-- Check current compatibility setting
SELECT name,
       value
FROM   v$parameter
WHERE  name = 'compatible';

-- After upgrade: verify compatible parameter before enabling 23ai features
-- Do NOT raise compatible until you have validated the upgrade
-- Once raised, you cannot downgrade
ALTER SYSTEM SET compatible = '23.0.0' SCOPE=SPFILE;
-- Requires restart; only do this after full validation

-- Check for deprecated features used in your database
SELECT name,
       sql_text,
       last_active_time
FROM   v$sql
WHERE  sql_text LIKE '%CONNECT BY%'     -- check for CONNECT BY usage
OR     sql_text LIKE '%ROWNUM%'         -- evaluate vs FETCH FIRST
ORDER  BY last_active_time DESC
FETCH FIRST 50 ROWS ONLY;

-- Verify new BOOLEAN columns do not conflict with existing NUMBER(1) patterns
SELECT table_name,
       column_name,
       data_type,
       data_length
FROM   user_tab_columns
WHERE  data_type   = 'NUMBER'
AND    data_length = 1
ORDER  BY table_name, column_name;

Upgrade Path Recommendation

Oracle 23ai is the long-term release (like 19c was). Oracle 19c goes to Premier Support end in April 2024 and Extended Support ends 2027. For new projects: start on 23ai. For existing 19c production systems: plan migration for 2026–2027, using Data Guard rolling upgrade methodology to minimize downtime. Do not skip directly from versions older than 19c — upgrade to 19c first, then to 23ai.

11. FAQ

Does Oracle 23ai replace the need for a separate vector database?

For most enterprise use cases, yes. If your application already uses Oracle Database and you need vector similarity search, there is no compelling reason to introduce a separate vector database like Pinecone or Weaviate. The key advantage of Oracle AI Vector Search is the hybrid query capability — combining vector similarity with relational filters in a single SQL statement, using Oracle's proven ACID transaction model and security infrastructure. A separate vector database requires data duplication, synchronization logic, and an additional operational component. The exception is extreme-scale pure vector workloads (billions of vectors) where dedicated vector databases may still have an edge.

Is Oracle 23ai available on-premises or only on OCI?

Oracle 23ai is available both on OCI (as Oracle Autonomous Database and base database service) and as an on-premises release. The on-premises version is Oracle Database 23ai Free (for development) and Oracle Database 23ai Enterprise Edition for production. All features described in this guide are available on-premises except those explicitly tied to OCI services (such as OCI Generative AI as the Select AI provider — though OpenAI and Azure OpenAI work on-premises too).

Does the VECTOR datatype work with Oracle RAC and Data Guard?

Yes. The VECTOR datatype is fully supported with Oracle RAC and Data Guard. HNSW vector indexes are stored in a dedicated memory pool (vector_memory_size) on each RAC node and are rebuilt from the base table data on startup. Data Guard replicates VECTOR column data normally through redo log shipping. One important consideration: HNSW indexes require rebuilding after a Data Guard failover on the new primary — plan for this in your RTO calculations if vector search is a critical path operation.

What is the difference between Oracle 23ai and Oracle Database 23c?

Oracle Database 23c was the development preview release available to early adopters. Oracle Database 23ai is the production-ready General Availability release with the same feature set plus additional AI-focused enhancements, stability fixes, and the official Oracle support commitment. Oracle renamed the release to 23ai to emphasise the AI-native positioning. If you tested with 23c Free, upgrade to 23ai for any production deployment — 23c Free was not intended for production use.

About the Author

Chetan Yadav

Chetan has tested Oracle 23ai features extensively in both OCI and on-premises environments, evaluating AI Vector Search, Select AI, JSON Duality Views, and Lock-Free Reservations against real OLTP and analytics workloads. His writing focuses on what actually works in production — not what the release notes promise.

This blog focuses on real-world DBA problems, career growth, and practical learning — not theoretical documentation or vendor marketing.

Oracle Data Guard Protection Modes: Zero Data Loss Design Strategy

2026-03-12T13:05:00.003+05:30

Oracle Data Guard Protection Modes: Zero Data Loss Design Strategy

Production HA/DR Architecture for DBAs and Architects

12 March 2026

Chetan Yadav — Senior Oracle & Cloud DBA

⏱️ 12–13 min read

⏱️ Estimated Reading Time: 12–13 minutes

Maximum Protection • Maximum Availability • Maximum Performance — Choose Wisely

⚙️ Production Environment Referenced in This Article

Oracle Database: 19.18.0.0.0 & 23ai Enterprise Edition • Data Guard Broker: Enabled with Fast-Start Failover
Primary: 2-Node RAC, 6 TB OLTP • Standby: Physical Standby, separate data center (120 km)
Network: Dedicated 10 GbE WAN link • RTO Target: < 30 seconds • RPO Target: Zero data loss
Application: Core banking transaction processing system

2:14 AM. A storage array at the primary data center suffered a catastrophic controller failure. The entire primary RAC cluster went offline. No warning. No graceful shutdown. Just gone.

Within 23 seconds, Oracle Data Guard Fast-Start Failover had detected the outage, confirmed quorum with the observer, and automatically activated the physical standby database. The application connection pool reconnected. Transactions resumed. The on-call team received the alert after the failover had already completed.

That outcome — 23 seconds, zero data loss, no manual intervention — was not luck. It was the result of choosing the right Data Guard protection mode, designing the redo transport correctly, and validating failover under load before the incident happened. Most organizations running Data Guard never validate their failover until disaster strikes. By then it is too late to discover the configuration was wrong.

This guide explains Oracle Data Guard protection modes in depth: what each mode actually guarantees, how redo transport works under the hood, when to use each mode, and the production design decisions that determine whether your standby database saves you or fails you at the worst possible moment.

 Table of Contents

Data Guard Architecture: How It Actually Works
The Three Protection Modes Explained
Redo Transport Deep Dive: SYNC vs ASYNC
Standby Database Types: Physical vs Logical vs Snapshot
Fast-Start Failover: Automatic DR Activation
Active Data Guard: Read-Only Standby While Applying Redo
Data Guard Broker: Centralized Configuration Management
Real Production Failover: What Actually Happens
Protection Mode Decision Framework
FAQ
Related Reading from Real Production Systems

1. Data Guard Architecture: How It Actually Works

Oracle Data Guard maintains one or more synchronized copies of a primary database called standby databases. When the primary fails, a standby can take over as the new primary — either automatically via Fast-Start Failover or manually via a DBA-initiated failover command.

The core mechanism is redo log shipping. Every change made to the primary database is recorded in redo logs. Data Guard ships those redo records to the standby in real time, where they are applied to keep the standby synchronized.

Key Data Guard Components

Component	Location	Role
LGWR / DMON	Primary	Captures redo and initiates shipping to standby
NSA / NSS Process	Primary	Network Server process — sends redo over the network
RFS Process	Standby	Remote File Server — receives redo from primary
MRP Process	Standby	Managed Recovery Process — applies redo to standby
LSP Process	Standby (logical)	LogMiner Server Process — applies SQL for logical standby
DMON Process	Both	Data Guard Monitor — manages broker configuration
Observer	Third site	Monitors primary for Fast-Start Failover quorum

SQL — Verify Data Guard Configuration Status

-- Check Data Guard status on primary
SELECT name,
       db_unique_name,
       database_role,
       protection_mode,
       protection_level,
       switchover_status,
       dataguard_broker
FROM   v$database;

-- Check redo transport status to all standbys
SELECT dest_id,
       dest_name,
       status,
       target,
       archiver,
       schedule,
       destination,
       applied_scn,
       error
FROM   v$archive_dest
WHERE  status != 'INACTIVE'
ORDER  BY dest_id;

-- Check standby apply lag
SELECT name,
       value,
       datum_time
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag', 'apply finish time')
ORDER  BY name;

2. The Three Protection Modes Explained

Oracle Data Guard offers three protection modes. Each makes a different trade-off between data loss guarantee, performance impact, and availability. Choosing the wrong mode for your workload is one of the most common — and most dangerous — Data Guard mistakes.

Maximum Protection

Every redo record must be written to at least one standby redo log on the standby database before the primary acknowledges the transaction commit. If the standby becomes unreachable, the primary database shuts itself down rather than risk any data divergence.

Transport: SYNC — synchronous redo shipping
Affirm: AFFIRM — standby must confirm disk write
RPO: Zero — absolutely no data loss under any failure scenario
RTO: Fast — standby is fully synchronized at all times
Risk: Primary shuts down if standby is unreachable — availability depends on standby health
Use case: Regulatory compliance, core banking, financial settlement systems

Production Reality — Maximum Protection:

A core banking client ran Maximum Protection mode. During a routine standby server reboot for OS patching, the primary database shut itself down — taking the entire production system offline for 18 minutes. The team had forgotten that Maximum Protection means the primary cannot run without the standby. Always maintain a second standby or use Maximum Availability instead for most production workloads.

Maximum Availability

The default recommended mode for most production systems. Like Maximum Protection, it uses synchronous redo shipping. However, if the standby becomes unreachable, the primary automatically falls back to asynchronous mode and continues running. When the standby reconnects, it resynchronizes and the primary returns to synchronous mode automatically.

Transport: SYNC — synchronous when standby is available
Affirm: AFFIRM — confirms disk write on standby
RPO: Zero under normal conditions; seconds of exposure during fallback
RTO: Fast — standby synchronized within seconds of primary failure
Risk: Brief data loss window during the fallback period
Use case: Enterprise OLTP, e-commerce, healthcare systems

Maximum Performance

The default mode when Data Guard is first configured. Redo is shipped asynchronously — the primary does not wait for the standby to confirm receipt before acknowledging the commit. This provides the best primary performance but at the cost of a potential data loss window.

Transport: ASYNC — asynchronous redo shipping
Affirm: NOAFFIRM — no standby disk write confirmation required
RPO: Seconds to minutes depending on network latency and redo volume
RTO: Fast but standby may lag behind primary
Risk: Data loss equal to the apply lag at time of failure
Use case: Reporting standbys, development/test environments, geographically distant DR sites

SQL — Change Protection Mode (via Data Guard Broker)

-- Connect to DGMGRL as SYSDG or SYSDBA
-- dgmgrl sys/password@primary

-- Check current protection mode
SHOW CONFIGURATION;
SHOW DATABASE VERBOSE primary_db;

-- Change to Maximum Availability (recommended for most production)
EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

-- Change to Maximum Protection (zero data loss, primary shuts down without standby)
EDIT CONFIGURATION SET PROTECTION MODE AS MAXPROTECTION;

-- Change to Maximum Performance (async, best performance)
EDIT CONFIGURATION SET PROTECTION MODE AS MAXPERFORMANCE;

-- Verify after change
SHOW CONFIGURATION;

3. Redo Transport Deep Dive: SYNC vs ASYNC

The protection mode you choose determines the redo transport mechanism. Understanding the difference between SYNC and ASYNC transport is essential for making the right design choice.

Synchronous Transport (SYNC)

With synchronous transport, the primary database Log Writer (LGWR) process sends the redo record to the standby at the same time it writes to the local online redo log. The commit does not complete until both the local write and the standby acknowledgment have been received. This introduces latency equal to the round-trip time between primary and standby.

Network Latency Rule for SYNC Transport

For synchronous redo transport, the round-trip network latency between primary and standby should be under 5 ms for OLTP workloads. Beyond 5 ms, commit latency becomes noticeable to applications. Beyond 20 ms, SYNC transport typically causes unacceptable performance degradation. In our production environment with a 120 km dark fiber link, round-trip latency is 1.8 ms — well within acceptable range for Maximum Availability mode.

Asynchronous Transport (ASYNC)

With asynchronous transport, the primary LGWR writes to the local redo log and acknowledges the commit immediately. A separate background process (NSA — Network Server Async) ships redo to the standby independently. The standby typically lags behind the primary by the amount of redo generated during the network transfer time.

SQL — Configure Redo Transport (LOG_ARCHIVE_DEST)

-- Maximum Availability: SYNC transport with AFFIRM
ALTER SYSTEM SET log_archive_dest_2 =
    'SERVICE=standby_db
      SYNC
      AFFIRM
      NET_TIMEOUT=30
      VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
      DB_UNIQUE_NAME=standby_db'
SCOPE=BOTH SID='*';

-- Maximum Performance: ASYNC transport with NOAFFIRM
ALTER SYSTEM SET log_archive_dest_2 =
    'SERVICE=standby_db
      ASYNC
      NOAFFIRM
      NET_TIMEOUT=30
      VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
      DB_UNIQUE_NAME=standby_db'
SCOPE=BOTH SID='*';

-- Verify redo transport configuration
SELECT dest_id,
       dest_name,
       target,
       archiver,
       net_timeout,
       affirm,
       async_blocks,
       status
FROM   v$archive_dest
WHERE  dest_id = 2;

Standby Redo Logs (SRL) — Critical Requirement

Standby Redo Logs (SRLs) are required for real-time apply and for synchronous transport. They must be the same size as the primary online redo logs and there must be at least one more SRL group per thread than the number of online redo log groups on the primary.

SQL — Add Standby Redo Logs on Standby Database

-- Check existing online redo log sizes on primary
SELECT group#,
       members,
       bytes/1024/1024  AS size_mb,
       status
FROM   v$log
ORDER  BY group#;

-- Add standby redo logs on standby (same size, one extra group per thread)
-- For a 2-node RAC primary with 3 redo groups per thread:
-- Add 4 SRL groups per thread (3 + 1 = 4)
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 11 ('+DATA/stdby/srl_t1_g11.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 12 ('+DATA/stdby/srl_t1_g12.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 13 ('+DATA/stdby/srl_t1_g13.log') SIZE 200M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1
    GROUP 14 ('+DATA/stdby/srl_t1_g14.log') SIZE 200M;

-- Verify SRL configuration
SELECT group#,
       thread#,
       sequence#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

4. Standby Database Types: Physical vs Logical vs Snapshot

Type	Apply Method	Open for Reads?	Best Use Case
Physical Standby	Block-for-block redo apply (MRP)	Yes (Active Data Guard, extra license)	Primary DR target, zero data loss
Logical Standby	SQL Apply via LogMiner (LSP)	Yes (read/write, some restrictions)	Reporting, DDL testing, heterogeneous environments
Snapshot Standby	Redo buffered but not applied	Yes (full read/write)	Testing, QA, patch validation against production data

DGMGRL — Convert Physical Standby to Snapshot Standby

-- Convert to snapshot standby (opens for read/write, buffers redo)
CONVERT DATABASE standby_db TO SNAPSHOT STANDBY;

-- Verify conversion
SHOW DATABASE standby_db;

-- Convert back to physical standby (discards all changes, resumes apply)
CONVERT DATABASE standby_db TO PHYSICAL STANDBY;

5. Fast-Start Failover: Automatic DR Activation

Fast-Start Failover (FSFO) enables Oracle Data Guard to automatically fail over to the standby database without any DBA intervention when the primary becomes unavailable. This is what enabled the 23-second failover described in the introduction.

FSFO Requirements

Data Guard Broker must be enabled and configured
Observer process running on a third independent host
Protection mode must be Maximum Availability or Maximum Protection
Standby Redo Logs must be configured on the standby
Flashback Database recommended for reinstating the old primary

DGMGRL — Configure Fast-Start Failover

-- Enable Fast-Start Failover
ENABLE FAST_START FAILOVER;

-- Set failover threshold (seconds primary must be unreachable before failover)
EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold = 30;

-- Set lag limit (max apply lag allowed when FSFO is enabled)
EDIT CONFIGURATION SET PROPERTY FastStartFailoverLagLimit = 30;

-- Start the observer (run on third independent host)
-- dgmgrl sys/password@primary
START OBSERVER;

-- Verify FSFO configuration
SHOW FAST_START FAILOVER;
SHOW CONFIGURATION VERBOSE;

-- Simulate failover for testing (without data loss)
-- Run from observer host
FAILOVER TO standby_db;

Production FSFO Design Tip:

Always run the FSFO observer on a third independent host — not on the primary server and not on the standby server. If both the primary and the observer are on the same network segment and that segment fails, the standby may not receive quorum to activate FSFO. In our production setup, the observer runs on a small VM in a separate availability zone with network access to both primary and standby. Test FSFO every quarter by deliberately shutting down the primary during a low-traffic window.

6. Active Data Guard: Read-Only Standby While Applying Redo

Active Data Guard (ADG) allows the physical standby database to be open in read-only mode while redo apply continues in the background. This means the standby can serve reporting queries, offload read traffic from the primary, and still be ready to fail over at any moment.

Licensing Note

Active Data Guard requires the Oracle Active Data Guard option, which is a separately licensed Enterprise Edition add-on. A physical standby open in read-only mode without redo apply is available without ADG license. Real-time redo apply while open read-only requires the ADG license. Always verify licensing before enabling ADG in production.

SQL — Enable Active Data Guard (Real-Time Apply + Read-Only)

-- On standby database: open read-only with real-time apply
ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
    USING CURRENT LOGFILE DISCONNECT FROM SESSION;

-- Verify ADG status
SELECT open_mode,
       database_role,
       db_unique_name
FROM   v$database;

-- Monitor apply lag on ADG standby
SELECT name,
       value,
       unit,
       time_computed
FROM   v$dataguard_stats
WHERE  name IN ('transport lag',
                'apply lag',
                'apply finish time',
                'estimated startup time')
ORDER  BY name;

-- Check active sessions using standby for reads
SELECT COUNT(*)         AS read_sessions,
       module,
       action
FROM   gv$session
WHERE  status = 'ACTIVE'
AND    type   = 'USER'
GROUP  BY module, action
ORDER  BY read_sessions DESC
FETCH FIRST 10 ROWS ONLY;

7. Data Guard Broker: Centralized Configuration Management

Data Guard Broker provides a unified interface for managing the entire Data Guard configuration. Without Broker, you manage each database individually through LOG_ARCHIVE_DEST parameters and manual commands. With Broker, you manage the entire configuration through a single DGMGRL command-line interface.

SQL & DGMGRL — Data Guard Broker Setup and Health Check

-- Enable Data Guard Broker on both primary and standby
ALTER SYSTEM SET dg_broker_start = TRUE SCOPE=BOTH SID='*';

-- Connect to broker (run on primary or standby)
-- dgmgrl /

-- Create broker configuration
CREATE CONFIGURATION dg_config
    AS PRIMARY DATABASE IS primary_db
    CONNECT IDENTIFIER IS primary_db;

-- Add standby database to configuration
ADD DATABASE standby_db
    AS CONNECT IDENTIFIER IS standby_db
    MAINTAINED AS PHYSICAL;

-- Enable the configuration
ENABLE CONFIGURATION;

-- Full health check
SHOW CONFIGURATION;
SHOW DATABASE VERBOSE primary_db;
SHOW DATABASE VERBOSE standby_db;

-- Validate configuration (checks for issues proactively)
VALIDATE DATABASE primary_db;
VALIDATE DATABASE standby_db;

DGMGRL — Switchover (Planned Role Transition)

-- Switchover: planned, zero data loss, reversible
-- Use for maintenance, patching, or DR testing

-- Verify configuration is ready for switchover
VALIDATE DATABASE primary_db;
SHOW CONFIGURATION;

-- Initiate switchover to standby
SWITCHOVER TO standby_db;

-- After switchover: verify new primary is active
SHOW CONFIGURATION;
SHOW DATABASE VERBOSE standby_db;   -- now primary
SHOW DATABASE VERBOSE primary_db;   -- now standby

-- Switchover back when maintenance is complete
SWITCHOVER TO primary_db;

8. Real Production Failover: What Actually Happens

These are real Data Guard incidents from production environments and the lessons they produced.

Incident 1: Protection Mode Mismatch Caused Silent Data Loss

A financial services client had Data Guard configured but in Maximum Performance mode (the default). They believed they had zero data loss protection. During a primary storage failure, the standby was 47 seconds behind the primary due to ASYNC transport lag. 47 seconds of financial transactions were permanently lost.

Lesson: Always verify protection mode AND transport mode with SELECT protection_mode, protection_level FROM v$database. The protection_level column shows the actual effective mode — it differs from protection_mode when the standby has fallen back to async.

Incident 2: Standby Redo Logs Not Configured — Real-Time Apply Silently Disabled

A team set up Data Guard correctly — or so they thought. Failover testing revealed the standby was 8 hours behind the primary. Investigation showed Standby Redo Logs had never been created. Without SRLs, real-time apply cannot function and the standby only catches up during log archive shipping, leaving a massive gap.

Lesson: Always verify SRLs exist and are active: SELECT * FROM v$standby_log. If this view is empty, real-time apply is not running.

Success: 23-Second Automatic Failover (The Introduction Story)

Configuration that made it work: Maximum Availability mode, SYNC/AFFIRM transport on 1.8 ms latency link, Standby Redo Logs sized identically to primary, FSFO enabled with threshold of 15 seconds, observer on independent host, Flashback Database enabled on both primary and standby, and quarterly failover testing under full production load.

Key lesson: Fast-Start Failover only works reliably when every component is validated together under real load — not just configured and assumed to work.

SQL — Data Guard Health Check Queries

-- 1. Verify effective protection mode (must match intended mode)
SELECT name,
       db_unique_name,
       database_role,
       protection_mode,    -- configured mode
       protection_level    -- actual effective mode (may differ)
FROM   v$database;

-- 2. Check transport lag and apply lag
SELECT name,
       value,
       datum_time
FROM   v$dataguard_stats
WHERE  name IN ('transport lag', 'apply lag')
ORDER  BY name;

-- 3. Verify standby redo logs exist and are active
SELECT group#,
       thread#,
       sequence#,
       bytes/1024/1024  AS size_mb,
       archived,
       status
FROM   v$standby_log
ORDER  BY thread#, group#;

-- 4. Check MRP (apply) process is running on standby
SELECT process,
       status,
       thread#,
       sequence#,
       block#,
       blocks
FROM   v$managed_standby
WHERE  process LIKE 'MRP%'
OR     process LIKE 'RFS%'
ORDER  BY process;

9. Protection Mode Decision Framework

Use this framework to choose the right protection mode for your workload.

Choose Maximum Protection if ALL of these are true:

Regulatory zero data loss is a hard legal requirement (banking, finance, government)
You have a second standby or can tolerate primary shutdown if standby fails
Network latency between primary and standby is under 2 ms
Your application can tolerate slightly higher commit latency

Choose Maximum Availability if ANY of these are true:

You need near-zero data loss but cannot accept primary shutdown risk
Network latency is under 5 ms and workload is standard OLTP
You want Fast-Start Failover with automatic activation
This is your primary DR configuration for an enterprise system

Choose Maximum Performance if ANY of these are true:

This standby is for reporting or dev/test only — not primary DR
The standby is geographically distant (WAN latency > 10 ms)
Some data loss is acceptable and primary performance is the priority
You are running a second standby in addition to a sync standby

10. FAQ

What is the difference between Switchover and Failover?

Switchover is a planned, graceful role transition. Both primary and standby participate cooperatively. There is zero data loss and the operation is fully reversible. Use switchover for planned maintenance, patching, or DR testing.

Failover is an unplanned activation of the standby when the primary is unavailable. Data loss depends on the protection mode in effect at the time. The old primary must be reinstated (using Flashback Database) before it can rejoin as a standby. Fast-Start Failover automates this process.

Does Data Guard protect against logical corruption?

No. Data Guard replicates every redo record including those caused by user errors like accidental DROP TABLE or DELETE without WHERE. The corruption is applied to the standby within seconds. For protection against logical corruption, use Flashback Database (which can rewind both primary and standby to a point before the error) or maintain a time-delayed standby using the DELAY parameter in LOG_ARCHIVE_DEST.

Can Data Guard work with Oracle RAC on the primary?

Yes. RAC primary with a single-instance physical standby is a very common and fully supported architecture. The standby receives redo from all RAC threads and applies them in order. The standby can also be a RAC database for maximum availability on both sides. This RAC + Data Guard combination is called MAA (Maximum Availability Architecture) — Oracle's reference architecture for mission-critical systems.

How often should I test failover?

At minimum, quarterly — and ideally monthly for critical systems. Test under realistic load, not during off-peak hours with zero activity. A failover that works at 2 AM with no users connected may fail at 2 PM under full load due to session cleanup issues, long-running transactions, or application reconnection pool exhaustion. Document RTO measurements from every test and track them over time.

Should I mention Data Guard on my resume?

Absolutely — with specifics. Instead of "Oracle Data Guard experience," write: "Designed and maintained Oracle Data Guard Maximum Availability configuration with Fast-Start Failover for a 6 TB core banking database. Achieved RTO of 23 seconds and RPO of zero through SYNC/AFFIRM transport on dedicated 10 GbE WAN link. Conducted quarterly failover validation under production load." Metrics and architecture decisions demonstrate real expertise.

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on experience managing production databases across on-premises, hybrid, and cloud environments. He specializes in high availability architecture, performance tuning, disaster recovery, and database migrations.

Throughout his career, Chetan has designed and implemented Oracle Data Guard configurations for mission-critical systems in finance, healthcare, and e-commerce sectors. He has architected zero data loss DR solutions with sub-30-second RTO targets and validated them through real failover testing under production load.

This blog focuses on real-world DBA problems, career growth, and practical learning — not theoretical documentation or vendor marketing.

Oracle RAC Internals Explained: Cache Fusion and Cluster Design Lessons

2026-03-09T23:33:00.008+05:30

Oracle RAC Internals Explained: Cache Fusion and Cluster Design Lessons

Real Production High Availability Architecture and Clustering Deep Dive

 March 09, 2026

 Chetan Yadav — Senior Oracle & Cloud DBA

⏱️ 12–13 min read

⏱️ Estimated Reading Time: 12–13 minutes

Oracle RAC internals: Cache Fusion, Cluster Interconnect, Split-Brain, and Real Production Failures

⚙️ Test Environment

Oracle Database: 19.18.0.0.0 Enterprise Edition • Cluster: 4-Node Oracle RAC on Oracle Linux 8.7
Storage: Oracle ASM, 12 TB shared (Normal Redundancy) • DB Size: 8.2 TB (6.8 TB data + 1.4 TB indexes)
Workload: Mixed OLTP/Batch • Peak Load: 3,200 concurrent sessions, 2,400 TPS
Interconnect: Dual 10GbE bonded private network • Application: Financial transaction processing system

3:47 AM. Pager alert: "RAC Node 2 evicted — cluster performance degraded." I logged into the surviving node running Oracle Database 19.18.0.0.0. The cluster had automatically failed over, but performance had collapsed. What should have been 2,400 transactions per second was now limping at 900 TPS.

I checked interconnect statistics immediately. The gc cr block receive time averaged 247 milliseconds — it should be under 1 millisecond. This wasn't a failed-node problem; this was network infrastructure failure. The private interconnect switch had undergone a firmware upgrade during the maintenance window. The new firmware version had a packet forwarding bug causing random 200ms+ delays in Cache Fusion block transfers. Applications were technically connected, but every cross-node block request was timing out and retrying. We initiated emergency failover to the DR site while network engineering rolled back the switch firmware.

Oracle RAC is not just "multiple databases sharing storage." It's a distributed cache coherency system where every node maintains its own buffer cache, but all nodes must coordinate which version of each data block is current. Cache Fusion is the mechanism that makes this work — transferring blocks between nodes over the private interconnect instead of forcing disk writes. Understanding this is the difference between an operational RAC cluster and a ticking time bomb.

This guide covers real Oracle RAC internals: how Cache Fusion actually works, why interconnect design matters more than CPU, what causes split-brain scenarios, and the production lessons learned from managing RAC clusters that can't afford downtime.

 Table of Contents

RAC Architecture Fundamentals: Beyond the Marketing
Cache Fusion Explained: How Blocks Move Between Nodes
Global Cache Services (GCS) and Global Enqueue Services (GES)
Cluster Interconnect: The Most Critical Component
Split-Brain Scenarios and Voting Disk Protection
RAC Performance Tuning: What Actually Matters
Real Production Failures and Lessons Learned
When RAC Makes Sense (And When It Doesn't)
FAQ
Related Reading from Real Production Systems

1. RAC Architecture Fundamentals: Beyond the Marketing

Oracle RAC is sold as "high availability and scalability." Reality is more nuanced.

What RAC Actually Provides

Capability	Reality	Common Misconception
High Availability	Survives single node failure	"Zero downtime" — not true during network failures
Scalability	Read scaling works well	"Linear scaling" — write workloads don't scale linearly
Load Balancing	Distributes connections	"Automatic query routing" — application must handle
Maintenance	Rolling patches possible	"No downtime patches" — some still require outage

Core RAC Components

Every RAC cluster requires:

Shared Storage: ASM or certified cluster filesystem — all nodes access the same datafiles
Private Interconnect: Dedicated network for Cache Fusion messages (1 GB minimum, 10 GB+ recommended)
Voting Disks: Quorum mechanism to prevent split-brain (typically 3 or 5)
OCR (Oracle Cluster Registry): Cluster configuration database
Clusterware: Grid Infrastructure managing node membership and resources

SQL — Verify RAC Configuration

-- Check cluster database status
-- Verify RAC instances
SELECT inst_id,
       instance_name,
       host_name,
       status
FROM   gv$instance
ORDER  BY inst_id;

-- Check cluster interconnect configuration
SELECT inst_id,
       name,
       ip_address
FROM   gv$cluster_interconnects
ORDER  BY inst_id;

Oracle Licensing Note

The queries in this article use dynamic performance views (v$ and gv$ views) which are available in all Oracle Database editions without additional licensing. When analyzing historical performance data, AWR and ASH queries require the Oracle Diagnostics Pack license. For unlicensed environments, use Statspack (free) or real-time v$ views as shown above.

Single Instance vs RAC: Architectural Differences

Single Instance:

One SGA, one buffer cache
No coordination overhead
Simple lock management
Straightforward troubleshooting

RAC Cluster:

Multiple SGAs — one per node
Cache Fusion coordination required
Global lock management via GES
Complex distributed troubleshooting

2. Cache Fusion Explained: How Blocks Move Between Nodes

Cache Fusion is Oracle's distributed shared cache architecture used in Oracle Real Application Clusters (RAC). It was fully introduced with Oracle RAC in Oracle 9i, replacing the disk-based block pinging architecture used in earlier Oracle Parallel Server (OPS) environments.

Instead of forcing modified blocks to be written to disk before another instance reads them, RAC transfers blocks directly between instance buffer caches over the private interconnect. This memory-to-memory block transfer dramatically reduces latency compared with disk-based synchronization.

The Problem Cache Fusion Solves

Without Cache Fusion (Oracle Parallel Server 8i architecture):

Node 1 modifies block 1234567 in its buffer cache (8 KB block size)
Node 2 requests the same block for a SELECT query
Node 1 must write the dirty block to shared storage via LGWR and DBWR
Node 2 reads the block from disk via db file sequential read wait event
Result: Forced disk I/O averaging 8–15 ms latency (ping-pong effect)
Scalability ceiling: 2–3 nodes maximum due to I/O contention

With Cache Fusion (Oracle 19.18.0.0.0 RAC):

Node 1 holds dirty block 1234567 in buffer cache (current mode)
Node 2 requests the block via Global Cache Services message
GCS coordinates transfer — Node 1 identified as master for this resource
Node 1 ships the block directly over the private interconnect (10 GbE)
Transfer completes in 0.5–2.0 milliseconds (10x faster than disk)
Node 2 receives the block in its buffer cache without disk I/O
Result: Memory-to-memory transfer; disk write deferred until checkpoint
Scalability: Proven deployments up to 16+ nodes in production

Cache Fusion Block Transfer Modes

Current Mode Block Transfer (gc current): When a session requests the most recent version of a block for UPDATE or DELETE operations, Oracle transfers the current mode block. In our 19.18.0.0.0 production RAC environment with 10 GbE interconnect, current mode transfers average 1.2 ms during peak load. If the block is dirty, the owning instance retains a past image (PI) for instance crash recovery purposes.

Consistent Read Mode Block Transfer (gc cr): For SELECT queries requiring read consistency, Oracle may construct consistent read (CR) versions of blocks using undo data. In our testing on Oracle 19.18.0.0.0, CR block transfers show slightly higher latency (1.5–2.0 ms average) because they may require block reconstruction from multiple undo records before transfer. The gc cr block receive time metric in v$system_event directly measures this latency.

Cache Fusion Wait Events in Oracle 19.18.0.0.0

Wait Event	Description	Typical Latency	Production Impact
`gc current block 2-way`	Current block transfer between 2 instances	0.5–2.0 ms (10 GbE) 3–8 ms (1 GbE)	Most common; acceptable if under 2 ms average
`gc current block 3-way`	Block transfer requiring 3-instance coordination	1.5–4.0 ms (10 GbE)	Higher cost; occurs when block has past images on multiple nodes
`gc cr block 2-way`	Consistent read block constructed and transferred	1.0–2.5 ms	Read-heavy workloads; check undo contention if high
`gc current block busy`	Waiting for in-flight block transfer to complete	Variable	Hot block contention; redesign needed if persistent
`gc buffer busy acquire`	Multiple sessions contending for the same buffer	Variable	Severe: indicates same block being modified by multiple nodes simultaneously

SQL — Calculate Real-Time Cache Fusion Efficiency (Oracle 19c)

-- Cache Fusion latency analysis per instance
-- Run this during a performance investigation
SELECT inst_id,
       ROUND(
           (SELECT SUM(time_waited_micro)
            FROM   gv$system_event
            WHERE  event    LIKE 'gc cr block%way'
            AND    inst_id  = s.inst_id)
           /
           NULLIF(
               (SELECT SUM(total_waits)
                FROM   gv$system_event
                WHERE  event   LIKE 'gc cr block%way'
                AND    inst_id = s.inst_id),
           0) / 1000, 2)  AS avg_gc_cr_latency_ms,
       ROUND(
           (SELECT SUM(time_waited_micro)
            FROM   gv$system_event
            WHERE  event   LIKE 'gc current block%way'
            AND    inst_id = s.inst_id)
           /
           NULLIF(
               (SELECT SUM(total_waits)
                FROM   gv$system_event
                WHERE  event   LIKE 'gc current block%way'
                AND    inst_id = s.inst_id),
           0) / 1000, 2)  AS avg_gc_current_latency_ms
FROM   gv$instance s
ORDER  BY inst_id;

SQL — Identify Hot Blocks Causing Excessive Cache Fusion Transfers

-- Identify hot blocks causing excessive transfers
SELECT o.object_name,
       o.object_type,
       c.file#,
       c.block#,
       c.class#,
       c.status,
       COUNT(*)  AS contention_count
FROM   gv$bh       c
JOIN   dba_objects o ON c.objd = o.data_object_id
WHERE  c.status IN ('xcur', 'scur', 'cr', 'read')
AND    c.forced_reads > 10
GROUP  BY o.object_name,
          o.object_type,
          c.file#,
          c.block#,
          c.class#,
          c.status
HAVING COUNT(*) > 5
ORDER  BY contention_count DESC
FETCH FIRST 20 ROWS ONLY;

Real Production Example — Our 19.18 RAC Cluster:

During peak batch processing at 11 PM, we observed gc current block 2-way latency spike to 12 ms (baseline 1.2 ms). Analysis revealed the batch job was performing mass updates on a single table with a right-growing index (order_id sequence). All four RAC instances were contending for the rightmost leaf block of the index.

Solution: We partitioned the index by range and implemented four separate sequences with CACHE 1000 and ORDER settings. Post-change, gc current latency returned to baseline 1.3 ms and batch completion time reduced from 4.2 hours to 2.8 hours.

SQL — Monitor Cache Fusion Wait Events

-- Cache Fusion wait events across all instances
SELECT inst_id,
       event,
       total_waits,
       time_waited,
       ROUND(average_wait, 3)  AS avg_wait_ms
FROM   gv$system_event
WHERE  event LIKE 'gc%'
AND    total_waits > 0
ORDER  BY time_waited DESC;

-- Interconnect transfer rates per instance
SELECT inst_id,
       name,
       value
FROM   gv$sysstat
WHERE  name IN (
    'gcs messages sent',
    'ges messages sent',
    'global cache blocks received',
    'global cache blocks served'
)
ORDER  BY inst_id, name;

3. Global Cache Services (GCS) and Global Enqueue Services (GES)

GCS and GES are the coordination layers that make RAC work.

Global Cache Services (GCS)

Responsibilities:

Tracks which node holds which blocks
Maintains block ownership information
Coordinates block transfers between nodes
Manages cache coherency across the cluster

Global Enqueue Services (GES)

Responsibilities:

Manages global enqueues across the RAC cluster
Coordinates locking for shared database resources
Ensures consistent lock state across all instances
Maintains global enqueue structures for cluster coordination

SQL — GCS/GES Resource Distribution

-- Blocked global enqueues across cluster
SELECT inst_id,
       resource_name,
       current_mode,
       blocked
FROM   gv$ges_enqueue
WHERE  blocked = 1;

-- GCS latch statistics per instance
SELECT inst_id,
       name,
       gets,
       misses,
       sleeps
FROM   gv$latch
WHERE  name LIKE '%cache%'
ORDER  BY gets DESC;

Resource Mastering

Each resource (block, lock) has a master node responsible for coordinating access.

Master node responsibilities:

Tracks current owner of the resource
Grants access to requesting nodes
Maintains resource state information

Remastering occurs when:

A node joins or leaves the cluster
Resource access patterns change significantly
Manual remastering is triggered by DBA

4. Cluster Interconnect: The Most Critical Component

The interconnect is the most important part of RAC. If the interconnect fails, the cluster fails.

Interconnect Requirements

Metric	Minimum	Recommended	Why It Matters
Bandwidth	1 Gbps	10+ Gbps	Cache Fusion throughput
Latency	< 5 ms	< 1 ms	Block transfer speed
Packet Loss	< 1%	< 0.1%	Message reliability
Redundancy	Single path	Bonded NICs	Failover capability

Common Interconnect Problems

Risk Shared switches: Interconnect traffic mixed with public traffic
Risk Insufficient bandwidth: 1 Gbps not enough for high-transaction workloads
Risk High latency: Geographic distance between nodes (>1 ms)
Risk Single point of failure: One switch, one cable

SQL — Diagnose Interconnect Issues

-- Interconnect latency check across all nodes
SELECT inst_id,
       name,
       value
FROM   gv$sysstat
WHERE  name LIKE '%gc cr block receive time%'
OR     name LIKE '%gc current block receive time%'
ORDER  BY inst_id;

-- Calculate average interconnect latency per node
SELECT inst_id,
       ROUND(
           (SELECT value
            FROM   gv$sysstat
            WHERE  name    = 'gc cr block receive time'
            AND    inst_id = s.inst_id)
           /
           NULLIF(
               (SELECT value
                FROM   gv$sysstat
                WHERE  name    = 'gc cr blocks received'
                AND    inst_id = s.inst_id),
           0), 2)  AS avg_cr_latency_ms
FROM   gv$instance s
ORDER  BY inst_id;

Interconnect Design Best Practices

Best Dedicated network: Separate from public and backup networks
Best 10 Gbps minimum: For all production workloads
Best Low-latency switches: Purpose-built for interconnect
Best NIC bonding: Redundant paths for automatic failover
Best Jumbo frames: MTU 9000 for better throughput

5. Split-Brain Scenarios and Voting Disk Protection

Split-brain is the nightmare scenario where a cluster partitions and both sides believe they are primary.

What is Split-Brain?

Consider a 3-node RAC cluster running normally. If a network partition occurs (interconnect fails), Node 1 can no longer reach Nodes 2 and 3. Both sides believe the other side has failed. Both sides attempt to become primary. If both sides write to shared storage simultaneously the result is data corruption.

How Voting Disks Prevent Split-Brain

Voting disks implement a quorum mechanism:

Typically 3 or 5 voting disks are configured
A node must access a majority of voting disks to survive
With 3 voting disks, a node needs access to at least 2
With 5 voting disks, a node needs access to at least 3
The losing side evicts itself automatically — no manual intervention required

Bash — Check Voting Disk and Cluster Status

# Check voting disk configuration
crsctl query css votedisk

# Verify OCR configuration
ocrcheck

# Check overall cluster status across all nodes
crsctl check cluster -all

Node Eviction Process

When a node is evicted the following sequence occurs:

Cluster detects node unresponsiveness (missed heartbeats)
Voting disk quorum check fails for that node
Clusterware initiates an immediate node reboot
The instance crashes (immediate termination — no graceful shutdown)
Surviving nodes perform instance recovery from redo logs
Applications reconnect automatically to surviving nodes

6. RAC Performance Tuning: What Actually Matters

RAC tuning is different from single-instance tuning. The metrics that matter most are cluster-specific.

Key RAC-Specific Metrics

Metric	Good Value	Problem Threshold	Action
GC CR block receive time	< 1 ms	> 5 ms	Check interconnect hardware
GC current block busy	< 1% of waits	> 5% of waits	Reduce hot blocks
Blocks received (per node)	Balanced across nodes	Skewed to one node	Fix application routing
Cache transfers	< 10% of reads	> 30% of reads	Partition data or workload

SQL — Comprehensive RAC Health Check

-- RAC performance report: CR and Current block latency per node
SELECT inst_id,
       'CR Block Receive Time (ms)'  AS metric,
       ROUND(
           (SELECT value
            FROM   gv$sysstat
            WHERE  name    = 'gc cr block receive time'
            AND    inst_id = i.inst_id)
           /
           NULLIF(
               (SELECT value
                FROM   gv$sysstat
                WHERE  name    = 'gc cr blocks received'
                AND    inst_id = i.inst_id),
           0), 2)  AS value
FROM   gv$instance i

UNION ALL

SELECT inst_id,
       'Current Block Receive Time (ms)',
       ROUND(
           (SELECT value
            FROM   gv$sysstat
            WHERE  name    = 'gc current block receive time'
            AND    inst_id = i.inst_id)
           /
           NULLIF(
               (SELECT value
                FROM   gv$sysstat
                WHERE  name    = 'gc current blocks received'
                AND    inst_id = i.inst_id),
           0), 2)
FROM   gv$instance i

ORDER  BY inst_id, metric;

Common RAC Performance Problems

1. Hot Blocks
A single block being accessed by multiple nodes simultaneously causes excessive Cache Fusion traffic. Solution: partition data, use sequences wisely, avoid right-growing indexes.

2. Unbalanced Load
One node handling 80% of the workload while others are underutilized. Solution: fix application-level connection distribution and service definitions.

3. Interconnect Saturation
Cache Fusion messages exceeding available bandwidth causes latency to increase dramatically. Solution: upgrade interconnect to 10 GbE or 25 GbE; reduce unnecessary block transfers through workload partitioning.

7. Real Production Failures and Lessons Learned

These are actual RAC incidents from production environments.

Incident 1: Switch Firmware Causes Mass Eviction

Network team upgraded switch firmware during the maintenance window. The new firmware had a bug causing random packet drops. The cluster detected node unresponsiveness, and all 4 nodes evicted themselves simultaneously — complete cluster failure.

Lesson: Never trust network changes without extended interconnect testing. Always run ping and traceroute across the private interconnect for at least 30 minutes post-change before closing the maintenance window.

Incident 2: Storage Latency Masquerading as a RAC Issue

AWR showed high gc cr block receive time. Initial assumption was an interconnect problem. Deep investigation revealed storage latency of 50 ms — nodes were waiting for disk I/O, not Cache Fusion.

Lesson: Always check storage I/O latency before blaming RAC or the interconnect. Check v$filestat and storage-level metrics first.

Incident 3: Application Design Killing RAC Performance

The application used a single global sequence for order IDs. Every insert required global coordination across all nodes. This caused enq: SQ contention cluster-wide. Throughput was capped at 200 TPS against a target of 2,000+ TPS.

Lesson: RAC exposes bad application design immediately. Partition sequences per node, or use local sequences with offsets to eliminate global coordination overhead.

8. When RAC Makes Sense (And When It Doesn't)

RAC is not a universal solution. It has specific use cases where it excels and others where it makes things worse.

Good Use Cases for RAC

Good Read-heavy workloads: Reporting, analytics, read scaling
Good High availability requirement: Cannot tolerate planned downtime for patches
Good Partitioned workloads: Each node handles a different data subset
Good Connection scaling: Need to support 10,000+ concurrent connections

Bad Use Cases for RAC

Avoid Write-intensive OLTP: Cache Fusion overhead degrades write performance
Avoid Single global sequences: Become cluster-wide bottlenecks immediately
Avoid Budget-constrained environments: RAC requires expensive hardware and licensing
Avoid Teams without RAC expertise: Troubleshooting requires deep knowledge

RAC Alternatives to Consider

Requirement	RAC Solution	Alternative Solution
High Availability	RAC cluster	Data Guard with fast failover
Read Scaling	RAC nodes	Active Data Guard read replicas
Zero Downtime Patching	RAC rolling patch	Data Guard rolling upgrade
Connection Pooling	RAC load balancing	Application-level connection pool

9. FAQ

Does RAC provide disaster recovery?

No. RAC provides high availability within a single data center, not disaster recovery across data centers. All RAC nodes access the same shared storage — if that storage fails or the data center fails, the entire RAC cluster fails. For disaster recovery you need Data Guard in addition to RAC. A common architecture is: primary site runs RAC for HA, standby site runs Data Guard for DR.

Can I run RAC over a WAN?

Technically possible with Oracle Extended RAC, but not recommended for most use cases. Cache Fusion requires sub-millisecond latency. WAN latency (typically 20–100 ms) causes severe performance degradation. Extended RAC is designed for metro-area clusters (<100 km) with dark fiber connections. For true geographic distribution, use Data Guard instead.

Does RAC double my database performance?

No. Adding a second RAC node does not double throughput. Read-heavy workloads can scale near-linearly (1.8x with 2 nodes). Write-heavy workloads see minimal scaling (1.2–1.4x with 2 nodes) due to Cache Fusion coordination overhead. Some workloads actually perform worse in RAC due to global contention. RAC is about availability and read scaling, not write performance multiplication.

Should I mention RAC experience on my resume?

Absolutely — but be specific. Don't just write "Oracle RAC experience." Write: "Managed 4-node Oracle 19c RAC cluster serving 50,000 TPS OLTP workload. Troubleshot Cache Fusion performance issues, optimized interconnect configuration, and reduced gc cr block receive time from 8 ms to 1.2 ms through network tuning." Specific metrics and outcomes matter. RAC expertise is valuable because it's complex and few DBAs understand it deeply.

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 15+ years of hands-on experience managing production databases across on-premises, hybrid, and cloud environments. He specializes in high availability architecture, performance tuning, disaster recovery, and database migrations.

Throughout his career, Chetan has designed and implemented Oracle RAC clusters for mission-critical systems in finance, healthcare, and e-commerce sectors. He has architected high-availability solutions serving millions of transactions daily and has troubleshot complex Cache Fusion performance issues under production pressure.

This blog focuses on real-world DBA problems, career growth, and practical learning — not theoretical documentation or vendor marketing.

Oracle Performance Engineering Guide: AWR, ASH and SQL Monitor in 19c and 23ai

2026-03-02T13:00:00.006+05:30

Oracle Performance Engineering Guide: AWR, ASH and SQL Monitor in 19c and 23ai

Master the essential tools for diagnosing and resolving real-world performance issues

Date: Tuesday, March 10, 2026

Author: Chetan Yadav

Read Time: 20-24 minutes

Estimated Reading Time: 20-24 minutes

Real-World Performance Diagnostics - From Baseline Metrics to SQL Execution Plans

Production Environment Context

It's 3 AM on a Tuesday. The monitoring dashboard lights up red. Response times have jumped from 200ms to 5+ seconds. Users are reporting timeouts on critical batch jobs. Your manager's Slack message is already waiting: "Database issue?" You log into the database, check CPU utilization (45%), memory (78% used), disk I/O latency (120ms). Everything looks elevated but not catastrophically bad. Where do you even start investigating?

This is where AWR (Automatic Workload Repository), ASH (Active Session History), and SQL Monitor become your diagnostic lifeline. Over the past 15+ years managing large-scale Oracle databases in production, I have debugged thousands of performance incidents—from runaway SQL queries consuming 800GB of I/O in 10 minutes, to massive lock contention blocking 400+ sessions, to redo log I/O stalls freezing the entire database. These three tools have never failed me. They transform performance troubleshooting from educated guessing into data-driven root cause analysis.

In this guide, you will learn the exact methodology I use in production: how to leverage AWR, ASH, and SQL Monitor to identify root causes in under 15 minutes, pinpoint the exact problematic SQL statements, analyze their execution plans, and implement fixes. Whether you're managing a 3-node RAC cluster running Oracle 19c or a cloud-native 23ai environment, the diagnostic principles remain constant.

Let's dig into real production scenarios and techniques.

Table of Contents

Understanding Oracle Performance Diagnostics: The AWR Foundation
Active Session History (ASH): Real-Time Visibility into Database Activity
SQL Monitor: Drill Down into Individual SQL Statement Execution
Reading the Top 5 Timed Events: Where to Focus Your Efforts
Practical Workflow: From Problem Detection to Root Cause Analysis
Advanced Tuning Strategies: Wait Events, Lock Analysis, and I/O Optimization
Common Pitfalls and Anti-Patterns in Performance Tuning
Automation and Best Practices for Ongoing Performance Management
FAQ: Real Questions from Production DBAs
Related Reading from Real Production Systems

1. Understanding Oracle Performance Diagnostics: The AWR Foundation

The Automatic Workload Repository (AWR) is the backbone of Oracle performance diagnostics. Every hour, Oracle automatically captures a snapshot of database activity—CPU usage, I/O operations, SQL execution patterns, wait events, and memory consumption. These snapshots are stored in the SYSAUX tablespace for up to 8 days by default. In production, you should increase this to at least 30 days.

What Gets Captured in AWR Snapshots?

System Metrics: CPU utilization, physical I/O, wait event statistics, library cache activity
SQL Performance Data: Top SQL by CPU, disk reads, and elapsed time
Wait Events: Database locks, latches, I/O waits, log file synchronization
Memory Allocation: SGA usage, buffer cache hit ratios, shared pool statistics
Redo and Archive Logs: Log generation rates, checkpoint activity

The default snapshot interval is 60 minutes. For high-transaction databases or during troubleshooting windows, you might want to tighten this to 15 or 30 minutes.

Licensing Note: AWR, ASH, and SQL Monitor are part of the Oracle Diagnostics Pack (licensed separately from Oracle Database). If you do not have Diagnostics Pack licensed, use Statspack (free legacy tool) or dynamic performance views (V$SYSSTAT, V$SESSION, V$SQLAREA) which are included in the base database license.

Check AWR Snapshot Settings

SQL - Check Current AWR Settings

-- Check current AWR settings
SQL> SELECT dbid, db_name, wr_retention, wr_interval, topnsql
     FROM dba_hist_wr_control;

-- Output example:
-- DBID        DB_NAME    WR_RETENTION  WR_INTERVAL  TOPNSQL
-- 1234567890  PROD_DB    10080         60           30

Modify Snapshot Interval

SQL - Adjust AWR Snapshot Interval (Oracle 19c)

-- Change snapshot interval to 15 minutes, retention to 30 days
SQL> BEGIN
  DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
    retention => 43200,  
    interval  => 15      
  );
END;
/

-- Verify changes applied
SQL> SELECT dbid, wr_retention, wr_interval 
     FROM dba_hist_wr_control;

-- Note: For high-volume systems, 15-minute snapshots 
-- equal approximately 100GB per month
-- Monitor v$sysaux_occupants to track AWR usage

Important: Do not disable AWR to save storage. Even minimal AWR overhead (1-2% CPU) is worth the diagnostic value. Storage is cheap; downtime is expensive.

Best Practice: Create AWR baselines for baseline periods (off-peak hours, stable performance windows) so you can compare against known-good performance later.

2. Active Session History (ASH): Real-Time Visibility into Database Activity

If AWR is your historical lens, ASH (Active Session History) is your real-time microscope. ASH captures sessions that are actively consuming database time—CPU, I/O waits, locks—approximately every second. By default, the last 1 hour of ASH data is kept in memory (in V$ACTIVE_SESSION_HISTORY). Older data is written to disk and merged into AWR snapshots.

Critical Detail: ASH uses circular buffer sampling. Not every session is captured every second. Only one sample per 10 milliseconds of active session time is recorded. In a 3,000-session database, this means roughly 300 samples per second. If a session runs for only 50 milliseconds, it might not appear in ASH at all. This is why SQL Monitor (which captures actual execution) is essential for short-lived queries.

When you have a performance problem happening right now, ASH is your first diagnostic tool. AWR report generation can take 5-10 minutes on large databases. ASH gives you answers in seconds and does not require waiting for the next snapshot.

When to Use ASH Reports

Scenario	Time Window	Why ASH
Ongoing, real-time slowdown	Last 5-60 minutes	Immediate visibility; no delay
Batch job hangs suddenly	Last 10 minutes	Pinpoint exact hang condition
Session-level blocking locks	Last 5-15 minutes	See blocking session ID and wait chain
Spike in disk I/O	Last 2-5 minutes	Isolate which SQL is reading

SQL - Generate ASH Report from Command Line

-- Connect as SYSDBA
sqlplus / as sysdba

-- Generate ASH report for last 30 minutes (HTML format)
SQL> @$ORACLE_HOME/rdbms/admin/ashrpt.sql

-- When prompted:
-- Enter report type: HTML
-- Enter begin time: -30 (for last 30 minutes, relative)
-- Press Enter for end time (defaults to now)

The ASH report will provide:

Top Wait Events: What sessions are waiting for (CPU, I/O, locks)
Top SQL: Which SQL statements are consuming the most time
Top Sessions: Which user or application is causing the load
Activity Timeline: When the problem started and peaked

3. SQL Monitor: Drill Down into Individual SQL Statement Execution

SQL Monitor is your surgical instrument. While AWR and ASH tell you what is slow, SQL Monitor shows you why—down to the execution plan step, the number of rows processed, buffer gets, physical reads, and wait events per operation.

Starting in Oracle 19c, any SQL statement that executes for more than 5 seconds is automatically monitored and retained for 24 hours. In Oracle 23ai, the monitoring threshold is now configurable, and AI-powered recommendations are automatically generated for problematic statements.

Key Advantage: SQL Monitor captures actual execution statistics, not estimated values. If a query runs for 45 seconds but the execution plan shows "Estimated Rows=100, Actual Rows=10,000,000," that is immediate proof of a cardinality estimation problem—your first action should be gathering statistics, not rewriting SQL.

Key Advantages of SQL Monitor

Per-Operation Breakdown: See CPU, I/O, and rows for each step in the execution plan
Actual vs. Estimated Rows: Detect cardinality mismatches—a root cause of many bad plans
Parallel Execution Insights: For parallel query statements, see load balancing and skew
Buffer Gets and Reads: See logical and physical I/O at the operation level
Real-Time Monitoring: Monitor a running query while it is still executing

SQL - Generate SQL Monitor Report for a SQL Statement

-- Find SQL_ID of the statement (from AWR or ASH)
-- Example: Let us say SQL_ID is '8h4kpnf0zqr2a'

SET LONG 20000 LONGCHUNKSIZE 20000 PAGESIZE 0 
SET LINESIZE 1000 FEEDBACK OFF VERIFY OFF TRIMSPOOL ON
SET HEAD OFF ECHO OFF

-- Generate report to screen
SQL> SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR(
       sql_id     => '8h4kpnf0zqr2a',
       type       => 'HTML',
       report_level => 'ALL'
     ) FROM DUAL;

-- Or save to file
SQL> SPOOL /tmp/sql_monitor_report.html
SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR(
  sql_id => '8h4kpnf0zqr2a',
  type   => 'HTML'
) FROM DUAL;
SQL> SPOOL OFF

In Oracle 23ai, the DBMS_SQLDIAG.REPORT_SQL function is even more powerful—it captures optimizer statistics, schema metadata, and configuration parameters alongside the execution plan.

4. Reading the Top 5 Timed Events: Where to Focus Your Efforts

This is the critical insight: Most performance issues fall into a handful of categories. AWR highlights them as "Top 5 Timed Events"—the wait events consuming the most database time.

The Most Common Top 5 Events (and What They Mean)

Wait Event	What It Means	Root Cause	Diagnostic Query
CPU time	Actual CPU consumption (non-idle)	Inefficient SQL, missing or bad indexes, poor execution plans, high recursive SQL	`SELECT * FROM v$sqlarea WHERE executions > 1000 ORDER BY cpu_time DESC;`
db file sequential read	Single-block I/O (typically index reads)	Too many index seeks, unselective indexes, high clustering factor	`SELECT name FROM v$event_name WHERE name LIKE '%sequential%';`
db file scattered read	Multi-block I/O (full table or index scans)	Full table scans, missing partition pruning, undersized indexes	`SELECT * FROM dba_hist_event_name WHERE event_name LIKE '%scattered%';`
log file sync	Waiting for redo log write to disk (commit and LGWR synchronization)	Undersized redo logs, slow disk I/O, high commit frequency, inadequate redo log groups	`SELECT group#, thread#, bytes/1024/1024 MB FROM v$logfile;`
enq: TX - row lock contention	Row-level locking (transaction enqueue)	Concurrent DML on same rows, missing indexes on foreign key columns, ITL exhaustion	`SELECT blocking_session, sid FROM v$session WHERE blocking_session IS NOT NULL;`

Pro Tip: The Top 5 Timed Events tells you where 60-75% of database time is spent. Focus there first. A 20% improvement on the first event equals 12-15% overall database speedup. Optimizing event number 8 will not move the needle.

5. Practical Workflow: From Problem Detection to Root Cause Analysis

The 4-Step Performance Troubleshooting Framework

Here is the systematic approach I use in every production incident:

Step 1: Confirm the Problem and Set the Time Window

When did the problem start? (exact time from user or monitoring tool)
Is it still happening now?
What changed? (new job, code release, data growth)
Identify AWR snapshots for the affected period

SQL - Find AWR Snapshots for a Time Window

-- Real production scenario: Problem reported at 03:15 AM
-- Find snapshots bracketing the incident window

SQL> SELECT snap_id, 
     TO_CHAR(begin_interval_time, 'DD-MON-YYYY HH24:MI') begin_time,
     TO_CHAR(end_interval_time, 'DD-MON-YYYY HH24:MI') end_time,
     ROUND((end_interval_time - begin_interval_time)*24*60, 2) 
          duration_min
     FROM dba_hist_snapshot
     WHERE begin_interval_time >= TRUNC(SYSDATE) - 1
     AND begin_interval_time <= SYSDATE
     ORDER BY snap_id DESC;

-- Output example (3-node RAC):
-- SNAP_ID  BEGIN_TIME             END_TIME               DURATION_MIN
-- 3156     10-MAR-26 03:00:00    10-MAR-26 04:00:00    60.02
-- 3155     10-MAR-26 02:00:00    10-MAR-26 03:00:00    59.98
-- 3154     10-MAR-26 01:00:00    10-MAR-26 02:00:00    60.01

Step 2: Generate AWR Report and Review Top 5 Timed Events

SQL - Generate AWR Report (Specific Snapshot Range)

-- Connect as SYSDBA to any RAC instance
sqlplus / as sysdba

-- For single-instance database:
SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql

-- When prompted by awrrpt.sql:
-- Report type: Enter 'html' (default is 'text')
-- Begin snap ID: 3154  (start of problem window)
-- End snap ID: 3156   (end of problem window)

-- For RAC databases, generate cluster-wide report:
SQL> @$ORACLE_HOME/rdbms/admin/awrgrpt.sql

-- Note: AWR report generation locks in several DBA_HIST tables
-- On 8.5TB or larger databases, this can consume 20-40GB 
-- of temporary space and take 10-15 minutes.
-- Run during low-activity windows.

What to Look For in the AWR Report:

"Top 5 Timed Events" (Section 1) - Where your database spent most time
"Load Profile" - Transactions per second, logical reads per second, physical reads per second
"Top 20 Foreground Events by Total Wait Time" - Full wait event breakdown
"Top SQL by Elapsed Time" - Which statements consumed most time
"Instance Activity Stats" - Buffer cache hit ratio, parse ratio, redo allocation
"Cache Size Advisory" - Whether increasing SGA would help

Step 3: Identify the Culprit SQL

AWR reports include a "Top SQL" section. Look for:

Top SQL by Elapsed Time: Most total time spent
Top SQL by CPU Time: Most CPU consumed (CPU problem)
Top SQL by Physical Reads: Most disk I/O (I/O problem)

Grab the SQL_ID from the report. Then generate a SQL Monitor report for that statement.

Step 4: Drill Into SQL Monitor for the Detailed Execution Plan

SQL Monitor will show you:

Which operation in the plan is slow
Actual rows versus estimated rows (cardinality mismatch?)
Buffer gets and reads per operation
For parallel statements: work distribution and skew

If you see "estimated rows = 1,000 but actual rows = 1,000,000," that is a cardinality problem. The optimizer made a bad decision based on stale statistics. Solution: use ANALYZE TABLE with COMPUTE STATISTICS or GATHER_TABLE_STATS.

6. Advanced Tuning Strategies: Wait Events, Lock Analysis, and I/O Optimization

Diagnosing Specific Wait Events

The Top 5 Timed Events tells you what is slow. Use V$ views to understand why.

For "db file sequential read" (Index I/O Problem)

SQL - Analyze Index Performance

-- Find the most used tables
SQL> SELECT owner, table_name, num_rows
     FROM dba_tables
     WHERE owner NOT IN ('SYS', 'SYSTEM')
     ORDER BY num_rows DESC;

-- Check existing indexes on the table
SQL> SELECT index_name, column_name, column_position
     FROM dba_ind_columns
     WHERE table_name = 'YOUR_TABLE'
     ORDER BY index_name, column_position;

-- Look for missing indexes in slow SQL
-- If your WHERE clause is on columns A and B:
-- CREATE INDEX idx_name ON table_name(A, B);

-- Verify index is being used
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR
     ('sql_id', 0, 'ALLSTATS'));

For "enq: TX - row lock contention" (Locking Problem)

Row lock contention in RAC is particularly complex due to cross-instance deadlock detection. Distinguish between:

Row-level locks: Two sessions updating the same row (wait event: "enq: TX")
ITL exhaustion: Transaction list too small (default 2-4 entries per block), causes "buffer busy waits"
Global locks (RAC): Cross-instance locks (wait event: "global lock")

SQL - Comprehensive Lock Analysis (Single Instance and RAC)

-- Step 1: Find blocking sessions
SQL> SELECT blocking_session, blocking_inst_id, sid, serial#, 
            username, sql_id, event, seconds_in_wait
     FROM v$session
     WHERE blocking_session IS NOT NULL
     ORDER BY blocking_session;

-- Step 2: Check for ITL exhaustion (common cause)
SQL> SELECT table_name, pct_free, ini_trans, max_trans
     FROM dba_tables
     WHERE table_name = 'ORDERS';

-- Step 3: If ini_trans is low, increase it 
-- (requires table rebuild)
-- ALTER TABLE orders MOVE PCTFREE 20 INITRANS 10;
-- ALTER TABLE orders ENABLE ROW MOVEMENT;

For "log file sync" (Redo and Commit Problem)

SQL - Check Redo Log Performance

-- Check redo log file sizes
SQL> SELECT group#, member, bytes/1024/1024 AS size_mb
     FROM v$logfile
     ORDER BY group#;

-- If logs are small (less than 500MB), increase them
SQL> ALTER DATABASE ADD LOGFILE GROUP 4 
     ('/path/to/redo04.log') SIZE 1000M;

-- Monitor redo generation rate
SQL> SELECT inst_id, stat_name, value
     FROM gv$sysstat
     WHERE stat_name IN ('redo size', 
     'redo log space requests');

7. Common Pitfalls and Anti-Patterns in Performance Tuning

Anti-Pattern 1: Tuning by Hunches, Not Data

Wrong: "I think we need more memory. Let us increase SGA_TARGET."

Right: Check the AWR report. Is the buffer cache hit ratio low (less than 95%)? Are you seeing "free buffer waits" in the top events? Only then increase memory.

Anti-Pattern 2: Not Checking Cardinality Before Rewriting SQL

Wrong: Spend 2 weeks rewriting a query that is using a bad execution plan due to stale statistics.

Right: Check "actual rows" versus "estimated rows" in SQL Monitor first. If they differ by orders of magnitude, gather statistics before rewriting.

Anti-Pattern 3: Creating Indexes Without Testing

Wrong: Add an index to production without testing its impact on inserts, updates, and maintenance windows.

Right: Test on a production-like environment first. Verify the index actually improves query performance and does not slow down DML.

Anti-Pattern 4: Ignoring Baseline Performance

Wrong: Claim a query is slow without knowing what "normal" looks like.

Right: Create AWR baselines during stable periods. Compare "slow" periods to baselines to quantify degradation.

Anti-Pattern 5: Ignoring Interconnect Latency (RAC Databases)

Wrong: Assume high "global cache cr request" wait events are always application problems.

Right: For RAC, check interconnect latency: SELECT wait_count, time_waited FROM v$event_name WHERE name = 'gc cr request'; If time_waited divided by wait_count is greater than 5 milliseconds per request, investigate network connectivity.

8. Automation and Best Practices for Ongoing Performance Management

Set Up Automated Baseline Comparisons

SQL - Create and Compare AWR Baselines

-- Create a baseline for a known-good period 
-- (example: 8 AM - 10 AM off-peak)
SQL> BEGIN
  DBMS_WORKLOAD_REPOSITORY.create_baseline(
    start_snap_id => 12340,  -- Snapshot at 8:00 AM
    end_snap_id   => 12341,  -- Snapshot at 9:00 AM
    baseline_name => 'BASELINE_OFFPEAK'
  );
END;
/

-- Later, when something goes slow, compare against baseline
SQL> SELECT DBMS_WORKLOAD_REPOSITORY.compare_baseline_awr(
       db_name       => 'PROD_DB',
       baseline_name => 'BASELINE_OFFPEAK',
       snap_id1      => 12340,
       snap_id2      => 12350
     ) FROM DUAL;

Monitor AWR Regularly (Monthly)

Set up a cron job to generate AWR reports weekly
Watch for trending: Is CPU increasing? Disk I/O? Memory pressure?
Act early. Do not wait for a crisis.

Document Your Findings

Keep a log of performance issues: time, root cause, fix applied, result. Over time, you will see patterns. If row lock contention is your issue number 2 three times this year, that is a signal to redesign that batch process.

9. FAQ: Real Questions from Production DBAs

Q: How do I explain performance tuning to non-technical managers?

Tell them this: "Our database is doing 1,000 things per second, but 60% of the time is wasted on inefficient index lookups. By creating the right indexes and fixing the SQL, we can cut that to 20% waste. That is like getting a 3x speedup for free." Show them the AWR "Top 5 Timed Events" as proof.

Q: When should I enable extended statistics or histograms?

If a query has a cardinality mismatch (actual rows not equal to estimated rows by 10x or more), check the SQL Monitor. If the columns involved are correlated or have non-uniform distribution, enable column group statistics: DBMS_STATS.CREATE_EXTENDED_STATS(table_name, '(col1,col2)');

Q: Can I use SQL Tuning Advisor on every slow query?

SQL Tuning Advisor is good for complex queries where you do not know what is wrong. But it is not a substitute for human judgment. Always review its recommendations. It might suggest index creation when the real issue is a join order problem. Use it as a starting point, not gospel.

Q: How often should I gather statistics?

For OLTP databases: nightly or weekly. For data warehouses: after major loads. For stable databases: monthly. Oracle 19c and later has auto-statistics gathering by default during maintenance windows. Check if it is working: SELECT * FROM dba_scheduler_jobs WHERE job_name LIKE '%GATHER_STATS%';

Q: Is it okay to use DBMS_STATS.GATHER_TABLE_STATS for very large tables?

Yes, if you use sampling. For a 1TB table, sampling 10% is usually accurate enough: DBMS_STATS.GATHER_TABLE_STATS(ownname=>'SCHEMA', tabname=>'LARGE_TABLE', estimate_percent=>10);

Licensing Compliance and Free Alternatives

Important Note: AWR, ASH, and SQL Monitor are licensed features within Oracle Diagnostics Pack and require separate licensing from the base Oracle Database.

If You Have Diagnostics Pack Licensed:

AWR, ASH, SQL Monitor, SQL Tuning Advisor - all available
No additional configuration required
Fully supported on Oracle 19c and 23ai

If You Do Not Have Diagnostics Pack:

Statspack (Free): Legacy tool, similar to AWR but without licensing restrictions. Use: @$ORACLE_HOME/rdbms/admin/spcreate.sql
Dynamic Performance Views (Free): Included with base database. Use V$SYSSTAT, V$SESSION, V$SQLAREA, V$SESSION_WAIT for real-time diagnostics
Execution Plans (Free): Use DBMS_XPLAN.DISPLAY_CURSOR() or EXPLAIN PLAN FOR to analyze bad plans
Oracle 23ai Automatic Optimizer Stats (Caution): Separate license, verify before enabling

About the Author

Chetan Yadav

Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 14+ years of hands-on experience

Chetan is a Senior Database Administrator with 14+ years of real-world expertise in Oracle, PostgreSQL, MySQL, and cloud database systems. He specializes in performance engineering, infrastructure scaling, and database reliability—not theoretical documentation, but battle-tested solutions from production environments.

Over his career, Chetan has debugged thousands of performance issues, migrated petabyte-scale databases to the cloud, built high-availability clusters, and mentored junior DBAs. He believes that performance tuning is an art backed by science—and that every DBA should understand the tools, not just memorize the commands.

Through the LevelUp Careers Initiative, Chetan is committed to elevating the DBA profession by sharing real-world knowledge, career guidance, and practical strategies that actually work in production. This blog focuses on real-world DBA problems, career growth, and practical learning—not theoretical documentation.

2026-02-23T11:22:00.000+05:30

Top 10 Wait Events Query – Universal Database Performance Tuning

⏱️ Reading Time: 10–12 minutes

Top-10 Wait Events Query (Universal Database Performance Tuning)

It’s a peak business hour. Users complain the application is “slow,” dashboards look normal, CPU is not maxed out, and storage graphs look fine. Someone asks the classic question:

“The database is up… so why is everything waiting?”

This is the exact moment where strong DBAs look at wait events instead of guessing. Understanding the top-10 wait events is not just a tuning skill —it’s a career-defining mindset.

Why This Matters (Production + Career)
The Production-Ready Top-10 Wait Events Query
Understanding the Output
Critical Concepts Every DBA Should Know
Common Issues and How to Fix Them
Automation and Monitoring
Interview Questions You'll Face
Your 7-Day Action Plan
Frequently Asked Questions
About the Author

1. Why This Matters (Production + Career)

In production systems, performance problems rarely start with CPU. They start with waiting: waiting on I/O, locks, network, or internal database resources.

Ignoring wait events leads to: - Random tuning attempts - Index sprawl - Unnecessary hardware upgrades - Long incident resolution times

Career Perspective:
DBAs who cannot explain wait events: - Struggle in performance-tuning interviews - Fail to justify tuning decisions - Get stuck executing commands without understanding impact

By the end of this article, you’ll be able to identify the real bottleneck in any database —Oracle, PostgreSQL, MySQL, or SQL Server.

2. The Production-Ready Top-10 Wait Events Query

📌 Who should use this:

Freshers learning performance analysis
DBAs handling slow application incidents
Engineers preparing for DBA interviews

⚠️ Who should NOT use this yet:

Pure lab environments without real load

Generic Wait-Based Analysis Pattern

While syntax differs across databases, the logic is universal: order wait events by total wait time.

-- Conceptual Query Pattern (Pseudo-SQL)
SELECT
    wait_event,
    total_wait_time,
    wait_count
FROM
    system_wait_statistics
ORDER BY
    total_wait_time DESC
FETCH FIRST 10 ROWS ONLY;

In production, teams adjust this based on: - Database engine - Time window - Workload type

3. Understanding the Output

Metric	What It Shows	Red Flag
Wait Event Name	What sessions are waiting on	Same event dominating top list
Total Wait Time	Cumulative impact	Growing faster than workload
Wait Count	Frequency of waits	High count + low work done

In interviews, you’re expected to explain what action you take next, not just name the wait.

4. Critical Concepts Every DBA Should Know

Concept 1: Waits vs Work

The Production Mistake: Teams panic when they see waits, without checking if useful work is progressing.

Interview Insight: Senior DBAs explain waits relative to throughput.

Concept 2: Symptoms vs Root Cause

The Production Mistake: Tuning the database when the issue is application locking.

Decision Framework: Fix contention before optimizing queries.

Concept 3: Dominant Wait Pattern

The Production Mistake: Treating many small waits as separate issues.

Interview Insight: Look for one dominant wait driving the slowdown.

5. Common Issues and How to Fix Them

Issue: High I/O Waits

Symptom: Slow queries, idle CPU

Root Cause: Storage latency or poor indexing

Fix: Validate I/O latency, then query access paths

Real Production Note: Under pressure, teams add indexes blindly instead of validating storage first.

6. Automation and Monitoring

⚠️ Production Safety Rule: Never automate wait-based alerts without observing trends for several days.

Automate only after understanding: - Normal baseline - Peak behavior - False positives

7. Interview Questions You'll Face

Q: How do you identify the main bottleneck in a slow database?
What they’re testing: Analytical thinking

Q: Why is CPU low but response time high?
What they’re testing: Understanding waits vs execution

These questions test thinking and decision-making, not memorization.

8. Your 7-Day Action Plan

Days 1–2: Study wait categories and meanings
Days 3–4: Capture wait stats from a test system
Days 5–7: Correlate waits with workload changes

Career Milestone: You can confidently explain performance issues in interviews.

9. Frequently Asked Questions

Is this asked in interviews?

Yes, almost every performance-tuning round includes wait analysis.

Can I mention this on my resume?

Yes, if you can explain decisions, not just queries.

10. About the Author

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 14+ years of experience handling real production incidents.

This blog focuses on real-world DBA problems, career growth, and practical learning—not theoretical documentation.

LinkedIn | YouTube

GitHub Actions for DBAs: Automating Oracle Database Scripts and Deployments

2026-02-23T03:00:00.003+05:30

GitHub Actions for DBAs: Automating Oracle Database Scripts and Deployments

CI/CD Pipelines for Database Professionals - Real Production Workflows

📅 February 23, 2026

👤 Chetan Yadav - Senior Oracle & Cloud DBA

⏱️ 13-14 min read

⏱️ Estimated Reading Time: 13–14 minutes

🔄 From Manual SQL Scripts to Automated CI/CD - GitHub Actions for Database Teams

The schema deployment failed at 2 AM. Again. The junior DBA forgot to run the prerequisite script before the main DDL. The application team was furious. Rollback took three hours because we had to manually trace which changes had been applied.

That's when I realized: developers have been using CI/CD for years. Why are DBAs still running scripts manually?

GitHub Actions isn't just for application developers. DBAs can automate schema deployments, backup validation, monitoring scripts, and database testing using the same CI/CD principles—with workflows triggered automatically on git push, pull request, or schedule.

This guide covers production-tested GitHub Actions workflows for Oracle DBAs. If you're tired of manual script execution, inconsistent deployments, and "it worked on my machine" problems, these patterns will transform your database operations.

📚 Table of Contents

Why DBAs Need GitHub Actions: The CI/CD Case for Databases
Getting Started: Repository Structure for Database Scripts
Your First Workflow: Automated Schema Deployment
Advanced Workflow: Multi-Environment Deployments (Dev, QA, Prod)
Automated Database Testing with GitHub Actions
Scheduled Workflows: Backup Validation and Health Checks
Secrets Management: Handling Database Credentials Securely
Real Production Example: Complete CI/CD Pipeline
FAQ
Related Reading from Real Production Systems

1. Why DBAs Need GitHub Actions: The CI/CD Case for Databases

Application developers have been using CI/CD for years. Every code push triggers automated testing, deployment, and monitoring. Meanwhile, DBAs are still manually running SQL scripts at 3 AM.

The Problem with Manual Database Deployments

Problem	Manual Process	GitHub Actions Solution
Inconsistent deployments	Different DBAs run scripts differently	Same workflow executes every time
No testing before production	Hope it works in prod	Auto-test in dev/QA first
Missing deployment steps	Forgot to run dependency script	Workflow enforces order
No audit trail	Who deployed what, when?	Every run logged with git commit
Manual rollback	Figure out what changed manually	Revert git commit, auto-rollback

What GitHub Actions Gives DBAs

✅ Consistency: Same deployment process every time, no human error
✅ Testing: Validate scripts in dev before prod deployment
✅ Audit trail: Complete history of who changed what, when
✅ Rollback capability: Git revert = automatic database rollback
✅ Scheduled automation: Run backup checks, health checks on schedule
✅ Multi-environment: Dev, QA, Prod deployments from same codebase

2. Getting Started: Repository Structure for Database Scripts

Before writing GitHub Actions workflows, organize your database scripts in a git repository with clear structure.

Repository Structure - Recommended Layout

oracle-database-scripts/
├── .github/
│   └── workflows/
│       ├── deploy-dev.yml           # Auto-deploy to dev on push
│       ├── deploy-qa.yml            # Deploy to QA on PR approval
│       ├── deploy-prod.yml          # Deploy to prod on tag
│       ├── backup-validation.yml    # Scheduled backup checks
│       └── health-check.yml         # Daily database health
├── schemas/
│   ├── ddl/
│   │   ├── 001_create_tables.sql
│   │   ├── 002_create_indexes.sql
│   │   └── 003_create_sequences.sql
│   ├── procedures/
│   │   ├── pkg_employee_mgmt.sql
│   │   └── pkg_salary_calc.sql
│   └── rollback/
│       ├── 001_rollback_tables.sql
│       └── 002_rollback_indexes.sql
├── tests/
│   ├── test_schema.sql              # Schema validation tests
│   ├── test_procedures.sql          # Procedure unit tests
│   └── test_data_integrity.sql      # Data integrity checks
├── scripts/
│   ├── deploy.sh                    # Deployment orchestration
│   ├── rollback.sh                  # Rollback orchestration
│   └── validate.sh                  # Post-deployment validation
├── config/
│   ├── dev.env                      # Dev environment config
│   ├── qa.env                       # QA environment config
│   └── prod.env                     # Prod environment config
└── README.md                        # Documentation

Key Principles for Database Git Repos

Numbered scripts: Use sequence numbers (001_, 002_) to enforce execution order
Idempotent scripts: Scripts should be safe to run multiple times (CREATE OR REPLACE, IF NOT EXISTS)
Rollback scripts: Every deployment script has corresponding rollback
Environment configs: Separate connection details for dev/QA/prod
Test scripts: Automated tests validate deployment success

3. Your First Workflow: Automated Schema Deployment

Let's start with a simple workflow: automatically deploy schema changes to dev environment when you push to the main branch.

YAML - .github/workflows/deploy-dev.yml

name: Deploy to Dev

on:
  push:
    branches:
      - main
    paths:
      - 'schemas/**'
      - 'scripts/**'

jobs:
  deploy-dev:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Install Oracle Instant Client
        run: |
          wget https://download.oracle.com/otn_software/linux/instantclient/instantclient-basic-linux.x64-21.1.0.0.0.zip
          unzip instantclient-basic-linux.x64-21.1.0.0.0.zip
          sudo mv instantclient_21_1 /opt/oracle/
          echo "/opt/oracle/instantclient_21_1" | sudo tee -a /etc/ld.so.conf.d/oracle.conf
          sudo ldconfig
      
      - name: Install SQLcl
        run: |
          wget https://download.oracle.com/otn_software/java/sqldeveloper/sqlcl-latest.zip
          unzip sqlcl-latest.zip
          sudo mv sqlcl /opt/
          echo "export PATH=\$PATH:/opt/sqlcl/bin" >> $GITHUB_ENV
      
      - name: Deploy DDL Scripts
        env:
          ORACLE_USER: ${{ secrets.DEV_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.DEV_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.DEV_DB_CONNECT }}
        run: |
          echo "Deploying schema changes to DEV..."
          
          # Run DDL scripts in order
          for script in schemas/ddl/*.sql; do
            echo "Executing $script"
            sql ${ORACLE_USER}/${ORACLE_PASSWORD}@${ORACLE_CONNECT_STRING} @$script
            
            if [ $? -ne 0 ]; then
              echo "ERROR: Script $script failed"
              exit 1
            fi
          done
          
          echo "Schema deployment completed successfully"
      
      - name: Run Tests
        env:
          ORACLE_USER: ${{ secrets.DEV_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.DEV_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.DEV_DB_CONNECT }}
        run: |
          echo "Running post-deployment tests..."
          
          for test in tests/*.sql; do
            echo "Running $test"
            sql ${ORACLE_USER}/${ORACLE_PASSWORD}@${ORACLE_CONNECT_STRING} @$test
          done
      
      - name: Notify on Slack
        if: always()
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
          text: |
            Dev Deployment: ${{ job.status }}
            Commit: ${{ github.sha }}
            Author: ${{ github.actor }}
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}

What This Workflow Does

Triggers on push to main: Any commit to main branch automatically deploys to dev
Only runs if database files changed: paths: schemas/**, scripts/**
Installs Oracle client: Sets up environment to connect to Oracle database
Executes scripts in order: Runs DDL scripts sequentially
Fails fast: If any script fails, workflow stops immediately
Runs tests: Validates deployment with automated tests
Sends notifications: Alerts team on Slack

4. Advanced Workflow: Multi-Environment Deployments (Dev, QA, Prod)

Production deployments need approval gates and different deployment strategies. Here's a multi-environment workflow.

YAML - .github/workflows/deploy-prod.yml

name: Deploy to Production

on:
  push:
    tags:
      - 'v*'  # Trigger on version tags like v1.0.0

jobs:
  deploy-qa:
    name: Deploy to QA (Pre-Production)
    runs-on: ubuntu-latest
    environment: qa
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Setup Oracle Client
        run: |
          # Install Oracle Instant Client
          wget https://download.oracle.com/otn_software/linux/instantclient/instantclient-basic-linux.x64-21.1.0.0.0.zip
          unzip instantclient-basic-linux.x64-21.1.0.0.0.zip
          sudo mv instantclient_21_1 /opt/oracle/
          echo "/opt/oracle/instantclient_21_1" | sudo tee -a /etc/ld.so.conf.d/oracle.conf
          sudo ldconfig
      
      - name: Deploy to QA
        env:
          ORACLE_USER: ${{ secrets.QA_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.QA_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.QA_DB_CONNECT }}
        run: |
          echo "Deploying to QA environment..."
          bash scripts/deploy.sh qa
      
      - name: Run Full Test Suite
        env:
          ORACLE_USER: ${{ secrets.QA_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.QA_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.QA_DB_CONNECT }}
        run: |
          echo "Running comprehensive tests in QA..."
          bash scripts/validate.sh qa

  deploy-production:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: deploy-qa  # Only run if QA deployment succeeds
    environment: 
      name: production
      url: https://database.company.com
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Setup Oracle Client
        run: |
          wget https://download.oracle.com/otn_software/linux/instantclient/instantclient-basic-linux.x64-21.1.0.0.0.zip
          unzip instantclient-basic-linux.x64-21.1.0.0.0.zip
          sudo mv instantclient_21_1 /opt/oracle/
          echo "/opt/oracle/instantclient_21_1" | sudo tee -a /etc/ld.so.conf.d/oracle.conf
          sudo ldconfig
      
      - name: Create Backup Before Deployment
        env:
          ORACLE_USER: ${{ secrets.PROD_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.PROD_DB_CONNECT }}
        run: |
          echo "Creating pre-deployment backup..."
          bash scripts/backup-before-deploy.sh
      
      - name: Deploy to Production
        env:
          ORACLE_USER: ${{ secrets.PROD_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.PROD_DB_CONNECT }}
        run: |
          echo "Deploying to PRODUCTION environment..."
          bash scripts/deploy.sh production
      
      - name: Validate Production Deployment
        env:
          ORACLE_USER: ${{ secrets.PROD_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.PROD_DB_CONNECT }}
        run: |
          echo "Validating production deployment..."
          bash scripts/validate.sh production
      
      - name: Notify Success
        if: success()
        uses: 8398a7/action-slack@v3
        with:
          status: success
          text: |
            ✅ Production Deployment Successful
            Tag: ${{ github.ref }}
            Commit: ${{ github.sha }}
            Deployed by: ${{ github.actor }}
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}
      
      - name: Rollback on Failure
        if: failure()
        env:
          ORACLE_USER: ${{ secrets.PROD_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.PROD_DB_CONNECT }}
        run: |
          echo "Deployment failed - initiating rollback..."
          bash scripts/rollback.sh production
      
      - name: Notify Failure
        if: failure()
        uses: 8398a7/action-slack@v3
        with:
          status: failure
          text: |
            ❌ Production Deployment Failed - Rollback Initiated
            Tag: ${{ github.ref }}
            Commit: ${{ github.sha }}
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}

Key Features of Production Workflow

✅ Tag-based deployment: Only deploys when you create git tag (v1.0.0)
✅ QA gate: Must pass QA before prod deployment starts
✅ Environment protection: GitHub environments can require manual approval
✅ Pre-deployment backup: Creates backup before changing production
✅ Automatic rollback: If deployment fails, rollback script runs automatically
✅ Notifications: Slack alerts for success and failure

5. Automated Database Testing with GitHub Actions

Testing database changes before production is critical. Here's how to automate database testing.

SQL - tests/test_schema.sql

-- Test: Verify all required tables exist
SET SERVEROUTPUT ON

DECLARE
    v_count NUMBER;
    v_test_passed BOOLEAN := TRUE;
    TYPE table_list IS TABLE OF VARCHAR2(30);
    required_tables table_list := table_list('EMPLOYEES', 'DEPARTMENTS', 'SALARY_HISTORY');
BEGIN
    DBMS_OUTPUT.PUT_LINE('Running schema validation tests...');
    
    FOR i IN 1..required_tables.COUNT LOOP
        SELECT COUNT(*) INTO v_count
        FROM user_tables
        WHERE table_name = required_tables(i);
        
        IF v_count = 0 THEN
            DBMS_OUTPUT.PUT_LINE('FAIL: Table ' || required_tables(i) || ' does not exist');
            v_test_passed := FALSE;
        ELSE
            DBMS_OUTPUT.PUT_LINE('PASS: Table ' || required_tables(i) || ' exists');
        END IF;
    END LOOP;
    
    IF NOT v_test_passed THEN
        RAISE_APPLICATION_ERROR(-20001, 'Schema validation failed');
    END IF;
    
    DBMS_OUTPUT.PUT_LINE('All schema tests passed');
END;
/

-- Test: Verify required indexes exist
DECLARE
    v_count NUMBER;
BEGIN
    SELECT COUNT(*) INTO v_count
    FROM user_indexes
    WHERE index_name IN ('IDX_EMP_DEPT', 'IDX_EMP_SALARY');
    
    IF v_count < 2 THEN
        RAISE_APPLICATION_ERROR(-20002, 'Required indexes missing');
    END IF;
    
    DBMS_OUTPUT.PUT_LINE('Index validation passed');
END;
/

YAML - .github/workflows/test-pr.yml (PR Testing)

name: Test Pull Request

on:
  pull_request:
    branches:
      - main
    paths:
      - 'schemas/**'
      - 'tests/**'

jobs:
  test-changes:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout PR code
        uses: actions/checkout@v3
      
      - name: Setup Oracle Client
        run: |
          wget https://download.oracle.com/otn_software/linux/instantclient/instantclient-basic-linux.x64-21.1.0.0.0.zip
          unzip instantclient-basic-linux.x64-21.1.0.0.0.zip
          sudo mv instantclient_21_1 /opt/oracle/
          echo "/opt/oracle/instantclient_21_1" | sudo tee -a /etc/ld.so.conf.d/oracle.conf
          sudo ldconfig
      
      - name: SQL Lint Check
        run: |
          # Install SQLFluff for SQL linting
          pip install sqlfluff
          sqlfluff lint schemas/ --dialect oracle
      
      - name: Deploy to Test Environment
        env:
          ORACLE_USER: ${{ secrets.TEST_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.TEST_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.TEST_DB_CONNECT }}
        run: |
          echo "Deploying changes to isolated test database..."
          bash scripts/deploy.sh test
      
      - name: Run All Tests
        env:
          ORACLE_USER: ${{ secrets.TEST_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.TEST_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.TEST_DB_CONNECT }}
        run: |
          echo "Running test suite..."
          for test in tests/*.sql; do
            echo "Executing $test"
            sql ${ORACLE_USER}/${ORACLE_PASSWORD}@${ORACLE_CONNECT_STRING} @$test
            
            if [ $? -ne 0 ]; then
              echo "Test failed: $test"
              exit 1
            fi
          done
      
      - name: Generate Test Report
        run: |
          echo "## Test Results" >> $GITHUB_STEP_SUMMARY
          echo "✅ All schema tests passed" >> $GITHUB_STEP_SUMMARY
          echo "✅ All index validations passed" >> $GITHUB_STEP_SUMMARY
          echo "✅ All procedure tests passed" >> $GITHUB_STEP_SUMMARY
      
      - name: Comment on PR
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: '✅ All database tests passed! Ready for review.'
            })

6. Scheduled Workflows: Backup Validation and Health Checks

GitHub Actions can run on schedule (cron) for routine database maintenance tasks.

YAML - .github/workflows/backup-validation.yml

name: Daily Backup Validation

on:
  schedule:
    - cron: '0 8 * * *'  # Run daily at 8 AM UTC
  workflow_dispatch:  # Allow manual trigger

jobs:
  validate-backups:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Setup Oracle Client
        run: |
          wget https://download.oracle.com/otn_software/linux/instantclient/instantclient-basic-linux.x64-21.1.0.0.0.zip
          unzip instantclient-basic-linux.x64-21.1.0.0.0.zip
          sudo mv instantclient_21_1 /opt/oracle/
          echo "/opt/oracle/instantclient_21_1" | sudo tee -a /etc/ld.so.conf.d/oracle.conf
          sudo ldconfig
      
      - name: Check Last Backup Status
        env:
          ORACLE_USER: ${{ secrets.PROD_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.PROD_DB_CONNECT }}
        run: |
          echo "Checking RMAN backup status..."
          
          sql ${ORACLE_USER}/${ORACLE_PASSWORD}@${ORACLE_CONNECT_STRING} < SYSDATE - 1;
          
          EXIT;
          EOF
      
      - name: Validate Backup Size
        env:
          ORACLE_USER: ${{ secrets.PROD_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.PROD_DB_CONNECT }}
        run: |
          echo "Checking backup sizes..."
          
          sql ${ORACLE_USER}/${ORACLE_PASSWORD}@${ORACLE_CONNECT_STRING} < SYSDATE - 1
          GROUP BY completion_time
          ORDER BY completion_time DESC;
          
          EXIT;
          EOF
      
      - name: Send Alert if Backup Failed
        if: failure()
        uses: 8398a7/action-slack@v3
        with:
          status: failure
          text: |
            ⚠️ Backup Validation Failed
            Please check backup status immediately
          webhook_url: ${{ secrets.SLACK_WEBHOOK }}

YAML - .github/workflows/health-check.yml

name: Database Health Check

on:
  schedule:
    - cron: '0 */6 * * *'  # Every 6 hours
  workflow_dispatch:

jobs:
  health-check:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Setup Oracle Client
        run: |
          wget https://download.oracle.com/otn_software/linux/instantclient/instantclient-basic-linux.x64-21.1.0.0.0.zip
          unzip instantclient-basic-linux.x64-21.1.0.0.0.zip
          sudo mv instantclient_21_1 /opt/oracle/
          echo "/opt/oracle/instantclient_21_1" | sudo tee -a /etc/ld.so.conf.d/oracle.conf
          sudo ldconfig
      
      - name: Check Tablespace Usage
        env:
          ORACLE_USER: ${{ secrets.PROD_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.PROD_DB_CONNECT }}
        run: |
          echo "Checking tablespace usage..."
          
          RESULT=$(sql -S ${ORACLE_USER}/${ORACLE_PASSWORD}@${ORACLE_CONNECT_STRING} < 85" | bc -l) )); then
            echo "WARNING: Tablespace usage above 85%"
            exit 1
          fi
      
      - name: Check Invalid Objects
        env:
          ORACLE_USER: ${{ secrets.PROD_DB_USER }}
          ORACLE_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}
          ORACLE_CONNECT_STRING: ${{ secrets.PROD_DB_CONNECT }}
        run: |
          echo "Checking for invalid objects..."
          
          COUNT=$(sql -S ${ORACLE_USER}/${ORACLE_PASSWORD}@${ORACLE_CONNECT_STRING} <> $GITHUB_STEP_SUMMARY
          echo "- Tablespace usage: ✅ Normal" >> $GITHUB_STEP_SUMMARY
          echo "- Invalid objects: ✅ Within threshold" >> $GITHUB_STEP_SUMMARY
          echo "- Backup status: ✅ Up to date" >> $GITHUB_STEP_SUMMARY

7. Secrets Management: Handling Database Credentials Securely

Never hardcode database credentials in workflows. GitHub provides secure secrets management.

Setting Up Secrets

Go to your GitHub repository
Navigate to Settings → Secrets and variables → Actions
Click "New repository secret"
Add secrets for each environment

Required Secrets for Database Workflows

Secret Name	Description	Example Value
DEV_DB_USER	Dev database username	app_user_dev
DEV_DB_PASSWORD	Dev database password	secure_password_123
DEV_DB_CONNECT	Dev connection string	dev-db.company.com:1521/DEVDB
PROD_DB_USER	Prod database username	app_user_prod
PROD_DB_PASSWORD	Prod database password	prod_secure_password_456
PROD_DB_CONNECT	Prod connection string	prod-db.company.com:1521/PRODDB
SLACK_WEBHOOK	Slack notification webhook	https://hooks.slack.com/...

Best Practices for Secrets

✅ Separate secrets per environment: Different credentials for dev/QA/prod
✅ Use service accounts: Don't use personal DBA credentials
✅ Least privilege: Grant only necessary permissions
✅ Rotate regularly: Change passwords quarterly
❌ Never log secrets: Avoid printing credentials in logs
❌ Never commit secrets: Use git-secrets to prevent accidental commits

8. Real Production Example: Complete CI/CD Pipeline

Here's a complete deployment script used in production for Oracle schema deployments.

Bash - scripts/deploy.sh

#!/bin/bash
# deploy.sh - Production deployment orchestration script
# Usage: ./deploy.sh 

set -e  # Exit on error

ENVIRONMENT=$1

if [ -z "$ENVIRONMENT" ]; then
    echo "ERROR: Environment not specified"
    echo "Usage: ./deploy.sh "
    exit 1
fi

# Load environment configuration
source config/${ENVIRONMENT}.env

# Logging
LOG_FILE="deploy_${ENVIRONMENT}_$(date +%Y%m%d_%H%M%S).log"
exec > >(tee -a ${LOG_FILE})
exec 2>&1

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1"
}

log "========================================="
log "Starting deployment to ${ENVIRONMENT}"
log "========================================="

# Pre-deployment checks
log "Running pre-deployment validation..."

sqlplus -S ${ORACLE_USER}/${ORACLE_PASSWORD}@${ORACLE_CONNECT_STRING} < USER,
        compile_all => FALSE
    );
END;
/
EXIT;
EOF

# Verify deployment
log "Running post-deployment validation..."

INVALID_COUNT=$(sqlplus -S ${ORACLE_USER}/${ORACLE_PASSWORD}@${ORACLE_CONNECT_STRING} <

9. FAQ

Do I need to be a developer to use GitHub Actions?

No. GitHub Actions uses YAML configuration files which are simpler than most programming languages. If you can write SQL scripts and bash scripts (which most DBAs can), you can write GitHub Actions workflows. Start with simple workflows (auto-deploy on push) and gradually add complexity. The examples in this guide are copy-paste ready—customize connection strings and you're good to go. Most DBAs master GitHub Actions basics in 1-2 weeks.

Is GitHub Actions free for database automation?

Yes, for public repositories. For private repositories, GitHub provides 2,000 free minutes per month (more than enough for most database teams). A typical deployment workflow runs 5-10 minutes, so 2,000 minutes = 200-400 deployments per month. If you exceed this, paid plans start at $4/month for 3,000 minutes. Compared to the cost of manual deployment errors, it's negligible. Enterprise GitHub includes unlimited minutes.

How do I handle production approvals with GitHub Actions?

Use GitHub Environments with protection rules. In your workflow, specify `environment: production` and configure that environment in repository settings to require: (1) Manual approval from specific reviewers, (2) Wait timer (e.g., 30 minutes before deployment), (3) Branch restrictions (only deploy from main/release branches). This gives you approval gates like enterprise deployment tools, but free and integrated with git.

Should I mention GitHub Actions experience on my DBA resume?

Absolutely. Write: "Implemented CI/CD pipelines for Oracle database deployments using GitHub Actions, automating schema changes, backup validation, and health checks across dev/QA/production environments." DevOps skills for DBAs are highly valued. Many organizations are moving toward "Database DevOps" and GitHub Actions experience shows you understand modern deployment practices. Even if you only automated dev deployments, it's valuable experience worth highlighting.

10. Related Reading from Real Production Systems

About the Author

Chetan Yadav

Chetan Yadav is a Senior Oracle, PostgreSQL, MySQL, and Cloud DBA with 14+ years of hands-on experience managing production databases across on-premises, hybrid, and cloud environments. He specializes in high availability architecture, performance tuning, disaster recovery, and database automation.

Throughout his career, Chetan has implemented CI/CD pipelines for database teams in finance, healthcare, and e-commerce sectors. He has automated hundreds of database deployments using GitHub Actions, reducing deployment time by 80% and eliminating human error in production releases.

Chetan is passionate about mentoring early-career DBAs and sharing real-world production lessons that aren't found in documentation. His writing focuses on practical decision-making, career growth, and bridging the gap between traditional DBA practices and modern DevOps.

This blog focuses on real-world DBA problems, career growth, and practical learning — not theoretical documentation or vendor marketing.

Oracle to PostgreSQL SQL Conversion Guide: Real-World Examples for DBAs

2026-02-19T12:00:00.001+05:30

Oracle to PostgreSQL SQL Conversion Guide: Real-World Examples for DBAs

Complete Syntax Mapping, Function Conversion, and PL/SQL to PL/pgSQL Migration

📅 February 06, 2026

👤 Chetan Yadav - Senior Oracle & PostgreSQL DBA

⏱️ 22-24 min read

⏱️ Estimated Reading Time: 22–24 minutes

🔄 Oracle → PostgreSQL - Real Production SQL Conversions with Before/After Examples

We had 847 stored procedures written in Oracle PL/SQL. The CTO announced we were moving to PostgreSQL to cut licensing costs by $200,000 annually. The migration deadline was three months away.

I spent the first week manually converting procedures. At that pace, I'd finish in 18 months. That's when I realized: most Oracle-to-PostgreSQL conversions follow predictable patterns. Once you know these patterns, conversion becomes systematic, not guesswork.

Oracle to PostgreSQL migration isn't about rewriting everything from scratch. 70-80% of SQL works with minor syntax adjustments. The remaining 20-30% requires understanding key differences in how each database handles data types, functions, and procedural logic.

This guide covers real production SQL conversions from Oracle to PostgreSQL. If you're an Oracle DBA planning a PostgreSQL migration, these are the patterns, gotchas, and solutions that actually work.

📚 Table of Contents

Core SQL Syntax Differences: What Changes, What Stays
Data Type Conversion Matrix: Oracle to PostgreSQL Mapping
Built-in Function Conversions with Real Examples
Sequence and Identity Column Migration
PL/SQL to PL/pgSQL: Procedural Code Conversion
Trigger Conversion: Oracle to PostgreSQL Patterns
Date and Timestamp Handling Differences
Transaction Control and Error Handling
FAQ
Related Reading from Real Production Systems

1. Core SQL Syntax Differences: What Changes, What Stays

Good news: Standard SQL (SELECT, INSERT, UPDATE, DELETE) works almost identically in Oracle and PostgreSQL. Here's what actually changes.

String Concatenation

SQL - Oracle Version

-- Oracle: Use || or CONCAT function
SELECT first_name || ' ' || last_name AS full_name
FROM employees;

SELECT CONCAT(first_name, ' ', last_name) AS full_name
FROM employees;

SQL - PostgreSQL Version

-- PostgreSQL: || works, CONCAT works, but CONCAT handles NULLs differently
SELECT first_name || ' ' || last_name AS full_name
FROM employees;

-- Better in PostgreSQL: CONCAT automatically handles NULLs
SELECT CONCAT(first_name, ' ', last_name) AS full_name
FROM employees;

-- PostgreSQL also has concat_ws (concat with separator)
SELECT concat_ws(' ', first_name, middle_name, last_name) AS full_name
FROM employees;

DUAL Table (Oracle-Specific)

SQL - Oracle Version

-- Oracle: SELECT from DUAL for expressions
SELECT SYSDATE FROM DUAL;
SELECT 'Hello World' FROM DUAL;
SELECT 2 + 2 FROM DUAL;

SQL - PostgreSQL Version

-- PostgreSQL: No FROM clause needed for expressions
SELECT CURRENT_TIMESTAMP;
SELECT 'Hello World';
SELECT 2 + 2;

-- Or create a DUAL view for Oracle compatibility
CREATE VIEW dual AS SELECT 1 AS dummy;
SELECT CURRENT_TIMESTAMP FROM dual;

Outer Join Syntax

SQL - Oracle Old Style (Don't Use in PostgreSQL)

-- Oracle: Old (+) outer join syntax
SELECT e.employee_id, e.first_name, d.department_name
FROM employees e, departments d
WHERE e.department_id = d.department_id(+);

SQL - PostgreSQL Version (ANSI SQL)

-- PostgreSQL: Use ANSI SQL LEFT JOIN (also works in Oracle 9i+)
SELECT e.employee_id, e.first_name, d.department_name
FROM employees e
LEFT JOIN departments d ON e.department_id = d.department_id;

Top N Queries

SQL - Oracle Version

-- Oracle: Use ROWNUM or FETCH FIRST (12c+)
SELECT * FROM employees
WHERE ROWNUM <= 10;

-- Oracle 12c+ ANSI SQL
SELECT * FROM employees
ORDER BY salary DESC
FETCH FIRST 10 ROWS ONLY;

SQL - PostgreSQL Version

-- PostgreSQL: Use LIMIT
SELECT * FROM employees
ORDER BY salary DESC
LIMIT 10;

-- PostgreSQL also supports ANSI SQL FETCH FIRST
SELECT * FROM employees
ORDER BY salary DESC
FETCH FIRST 10 ROWS ONLY;

2. Data Type Conversion Matrix: Oracle to PostgreSQL Mapping

Data type mismatches cause the most migration pain. Here's the definitive mapping.

Oracle Data Type	PostgreSQL Equivalent	Notes
VARCHAR2(n)	VARCHAR(n) or TEXT	PostgreSQL TEXT has no length limit
NUMBER	NUMERIC or DECIMAL	Exact equivalent
NUMBER(p,s)	NUMERIC(p,s)	Same precision/scale
INTEGER	INTEGER or INT	Same 32-bit integer
DATE	TIMESTAMP(0)	Oracle DATE includes time
TIMESTAMP	TIMESTAMP	Direct mapping
CLOB	TEXT	TEXT unlimited in PostgreSQL
BLOB	BYTEA	Binary data storage
RAW(n)	BYTEA	Small binary data
LONG	TEXT	Oracle deprecated LONG

Critical Data Type Differences

⚠️ Oracle DATE vs PostgreSQL TIMESTAMP

Oracle DATE: Stores date AND time (year, month, day, hour, minute, second)
PostgreSQL DATE: Stores only date (year, month, day)
Solution: Convert Oracle DATE to PostgreSQL TIMESTAMP(0)

SQL - Table Definition Conversion

-- Oracle table definition
CREATE TABLE employees (
    employee_id NUMBER PRIMARY KEY,
    first_name VARCHAR2(50),
    last_name VARCHAR2(50),
    email VARCHAR2(100),
    hire_date DATE,
    salary NUMBER(10,2),
    department_id NUMBER,
    notes CLOB
);

-- PostgreSQL equivalent
CREATE TABLE employees (
    employee_id INTEGER PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50),
    email VARCHAR(100),
    hire_date TIMESTAMP(0),  -- Changed from DATE
    salary NUMERIC(10,2),    -- Changed from NUMBER
    department_id INTEGER,   -- Changed from NUMBER
    notes TEXT              -- Changed from CLOB
);

3. Built-in Function Conversions with Real Examples

Oracle and PostgreSQL have different function names for common operations. Here are the most frequently used conversions.

String Functions

Oracle Function	PostgreSQL Equivalent	Example
NVL(val, default)	COALESCE(val, default)	COALESCE(middle_name, '')
NVL2(val, if_not_null, if_null)	CASE or COALESCE	CASE WHEN val IS NOT NULL THEN...
DECODE	CASE WHEN	CASE status WHEN 'A' THEN 'Active'...
SUBSTR(str, pos, len)	SUBSTRING(str FROM pos FOR len)	SUBSTRING(name FROM 1 FOR 10)
INSTR(str, substr)	POSITION(substr IN str)	POSITION('@' IN email)
LENGTH(str)	LENGTH(str) or CHAR_LENGTH(str)	LENGTH(description)

NVL to COALESCE Conversion

SQL - Oracle Version

-- Oracle: NVL for NULL handling
SELECT 
    employee_id,
    first_name,
    NVL(middle_name, '') AS middle_name,
    NVL(commission_pct, 0) AS commission,
    NVL2(manager_id, 'Has Manager', 'No Manager') AS manager_status
FROM employees;

SQL - PostgreSQL Version

-- PostgreSQL: COALESCE for NULL handling
SELECT 
    employee_id,
    first_name,
    COALESCE(middle_name, '') AS middle_name,
    COALESCE(commission_pct, 0) AS commission,
    CASE WHEN manager_id IS NOT NULL 
         THEN 'Has Manager' 
         ELSE 'No Manager' 
    END AS manager_status
FROM employees;

DECODE to CASE Conversion

SQL - Oracle DECODE

-- Oracle: DECODE for conditional logic
SELECT 
    employee_id,
    first_name,
    DECODE(department_id,
        10, 'Accounting',
        20, 'Research',
        30, 'Sales',
        40, 'Operations',
        'Unknown') AS department_name
FROM employees;

SQL - PostgreSQL CASE

-- PostgreSQL: CASE WHEN for conditional logic
SELECT 
    employee_id,
    first_name,
    CASE department_id
        WHEN 10 THEN 'Accounting'
        WHEN 20 THEN 'Research'
        WHEN 30 THEN 'Sales'
        WHEN 40 THEN 'Operations'
        ELSE 'Unknown'
    END AS department_name
FROM employees;

Date Functions

Oracle Function	PostgreSQL Equivalent	Example
SYSDATE	CURRENT_TIMESTAMP or NOW()	CURRENT_TIMESTAMP
TRUNC(date)	DATE_TRUNC('day', timestamp)	DATE_TRUNC('day', hire_date)
ADD_MONTHS(date, n)	date + INTERVAL 'n months'	hire_date + INTERVAL '3 months'
MONTHS_BETWEEN	AGE or date subtraction	AGE(end_date, start_date)
TO_CHAR(date, fmt)	TO_CHAR(timestamp, fmt)	TO_CHAR(hire_date, 'YYYY-MM-DD')
TO_DATE(str, fmt)	TO_TIMESTAMP(str, fmt)	TO_TIMESTAMP('2026-01-15', 'YYYY-MM-DD')

SQL - Oracle Date Operations

-- Oracle: Date arithmetic and functions
SELECT 
    employee_id,
    hire_date,
    SYSDATE AS today,
    TRUNC(SYSDATE) AS today_start,
    ADD_MONTHS(hire_date, 3) AS probation_end,
    MONTHS_BETWEEN(SYSDATE, hire_date) AS months_employed,
    TO_CHAR(hire_date, 'YYYY-MM-DD') AS hire_date_formatted
FROM employees;

SQL - PostgreSQL Date Operations

-- PostgreSQL: Date arithmetic and functions
SELECT 
    employee_id,
    hire_date,
    CURRENT_TIMESTAMP AS today,
    DATE_TRUNC('day', CURRENT_TIMESTAMP) AS today_start,
    hire_date + INTERVAL '3 months' AS probation_end,
    EXTRACT(YEAR FROM AGE(CURRENT_TIMESTAMP, hire_date)) * 12 + 
        EXTRACT(MONTH FROM AGE(CURRENT_TIMESTAMP, hire_date)) AS months_employed,
    TO_CHAR(hire_date, 'YYYY-MM-DD') AS hire_date_formatted
FROM employees;

4. Sequence and Identity Column Migration

Oracle uses sequences with triggers for auto-increment. PostgreSQL offers both sequences and SERIAL/IDENTITY columns.

Oracle Sequence + Trigger Pattern

SQL - Oracle Sequence and Trigger

-- Oracle: Create sequence
CREATE SEQUENCE emp_seq
    START WITH 1
    INCREMENT BY 1
    NOCACHE
    NOCYCLE;

-- Oracle: Create trigger to auto-populate ID
CREATE OR REPLACE TRIGGER emp_bir
BEFORE INSERT ON employees
FOR EACH ROW
BEGIN
    IF :NEW.employee_id IS NULL THEN
        :NEW.employee_id := emp_seq.NEXTVAL;
    END IF;
END;
/

-- Insert without specifying ID
INSERT INTO employees (first_name, last_name)
VALUES ('John', 'Doe');

PostgreSQL SERIAL Column (Recommended)

SQL - PostgreSQL SERIAL Auto-Increment

-- PostgreSQL: Use SERIAL (creates sequence automatically)
CREATE TABLE employees (
    employee_id SERIAL PRIMARY KEY,  -- Automatic sequence + NOT NULL
    first_name VARCHAR(50),
    last_name VARCHAR(50)
);

-- Insert without specifying ID (automatically generated)
INSERT INTO employees (first_name, last_name)
VALUES ('John', 'Doe');

-- PostgreSQL 10+: Use IDENTITY (SQL standard)
CREATE TABLE employees (
    employee_id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50)
);

Manual Sequence Control

SQL - PostgreSQL Manual Sequence

-- PostgreSQL: Create sequence explicitly (Oracle-style)
CREATE SEQUENCE emp_seq
    START WITH 1
    INCREMENT BY 1
    NO MAXVALUE
    NO CYCLE
    CACHE 1;

-- Use DEFAULT with NEXTVAL
CREATE TABLE employees (
    employee_id INTEGER DEFAULT nextval('emp_seq') PRIMARY KEY,
    first_name VARCHAR(50),
    last_name VARCHAR(50)
);

-- Or call NEXTVAL explicitly in INSERT
INSERT INTO employees (employee_id, first_name, last_name)
VALUES (nextval('emp_seq'), 'John', 'Doe');

5. PL/SQL to PL/pgSQL: Procedural Code Conversion

This is where most migration time goes. PL/SQL and PL/pgSQL are similar but have critical differences.

Basic Stored Procedure Conversion

PL/SQL - Oracle Stored Procedure

-- Oracle: PL/SQL stored procedure
CREATE OR REPLACE PROCEDURE update_employee_salary(
    p_employee_id IN NUMBER,
    p_new_salary IN NUMBER
)
IS
    v_old_salary NUMBER;
    v_count NUMBER;
BEGIN
    -- Check if employee exists
    SELECT COUNT(*) INTO v_count
    FROM employees
    WHERE employee_id = p_employee_id;
    
    IF v_count = 0 THEN
        RAISE_APPLICATION_ERROR(-20001, 'Employee not found');
    END IF;
    
    -- Get current salary
    SELECT salary INTO v_old_salary
    FROM employees
    WHERE employee_id = p_employee_id;
    
    -- Update salary
    UPDATE employees
    SET salary = p_new_salary,
        last_updated = SYSDATE
    WHERE employee_id = p_employee_id;
    
    -- Log change
    INSERT INTO salary_history (employee_id, old_salary, new_salary, changed_date)
    VALUES (p_employee_id, v_old_salary, p_new_salary, SYSDATE);
    
    COMMIT;
    
    DBMS_OUTPUT.PUT_LINE('Salary updated successfully');
EXCEPTION
    WHEN OTHERS THEN
        ROLLBACK;
        RAISE;
END;
/

PL/pgSQL - PostgreSQL Stored Procedure

-- PostgreSQL: PL/pgSQL stored procedure
CREATE OR REPLACE FUNCTION update_employee_salary(
    p_employee_id INTEGER,
    p_new_salary NUMERIC
)
RETURNS VOID AS $$
DECLARE
    v_old_salary NUMERIC;
    v_count INTEGER;
BEGIN
    -- Check if employee exists
    SELECT COUNT(*) INTO v_count
    FROM employees
    WHERE employee_id = p_employee_id;
    
    IF v_count = 0 THEN
        RAISE EXCEPTION 'Employee not found';  -- Changed
    END IF;
    
    -- Get current salary
    SELECT salary INTO v_old_salary
    FROM employees
    WHERE employee_id = p_employee_id;
    
    -- Update salary
    UPDATE employees
    SET salary = p_new_salary,
        last_updated = CURRENT_TIMESTAMP  -- Changed from SYSDATE
    WHERE employee_id = p_employee_id;
    
    -- Log change
    INSERT INTO salary_history (employee_id, old_salary, new_salary, changed_date)
    VALUES (p_employee_id, v_old_salary, p_new_salary, CURRENT_TIMESTAMP);
    
    -- No COMMIT needed (auto-commit in PostgreSQL functions)
    
    RAISE NOTICE 'Salary updated successfully';  -- Changed from DBMS_OUTPUT
EXCEPTION
    WHEN OTHERS THEN
        -- ROLLBACK happens automatically
        RAISE;
END;
$$ LANGUAGE plpgsql;

Key PL/SQL to PL/pgSQL Differences

Feature	Oracle PL/SQL	PostgreSQL PL/pgSQL
Block terminator	END; followed by /	END; with $$ delimiters
Parameter modes	IN, OUT, IN OUT	IN, OUT, INOUT
Print output	DBMS_OUTPUT.PUT_LINE	RAISE NOTICE
Raise error	RAISE_APPLICATION_ERROR	RAISE EXCEPTION
Transaction control	COMMIT/ROLLBACK in procedure	Auto-commit (no manual control)
Packages	CREATE PACKAGE	Use SCHEMA (no packages)

6. Trigger Conversion: Oracle to PostgreSQL Patterns

Oracle and PostgreSQL triggers have different syntax and execution models.

PL/SQL - Oracle Trigger

-- Oracle: Row-level BEFORE INSERT trigger
CREATE OR REPLACE TRIGGER employees_audit_trg
BEFORE INSERT OR UPDATE ON employees
FOR EACH ROW
BEGIN
    :NEW.last_updated := SYSDATE;
    :NEW.last_updated_by := USER;
    
    IF INSERTING THEN
        INSERT INTO audit_log (table_name, operation, record_id, changed_date)
        VALUES ('EMPLOYEES', 'INSERT', :NEW.employee_id, SYSDATE);
    ELSIF UPDATING THEN
        INSERT INTO audit_log (table_name, operation, record_id, changed_date)
        VALUES ('EMPLOYEES', 'UPDATE', :NEW.employee_id, SYSDATE);
    END IF;
END;
/

PL/pgSQL - PostgreSQL Trigger

-- PostgreSQL: Trigger function (separate from trigger definition)
CREATE OR REPLACE FUNCTION employees_audit_func()
RETURNS TRIGGER AS $$
BEGIN
    NEW.last_updated := CURRENT_TIMESTAMP;
    NEW.last_updated_by := CURRENT_USER;
    
    IF TG_OP = 'INSERT' THEN
        INSERT INTO audit_log (table_name, operation, record_id, changed_date)
        VALUES ('employees', 'INSERT', NEW.employee_id, CURRENT_TIMESTAMP);
    ELSIF TG_OP = 'UPDATE' THEN
        INSERT INTO audit_log (table_name, operation, record_id, changed_date)
        VALUES ('employees', 'UPDATE', NEW.employee_id, CURRENT_TIMESTAMP);
    END IF;
    
    RETURN NEW;  -- Must return NEW or OLD
END;
$$ LANGUAGE plpgsql;

-- Create trigger (links function to table)
CREATE TRIGGER employees_audit_trg
BEFORE INSERT OR UPDATE ON employees
FOR EACH ROW
EXECUTE FUNCTION employees_audit_func();

Critical Trigger Differences

❌ Oracle: Trigger logic inline with CREATE TRIGGER
✅ PostgreSQL: Trigger function separate, then CREATE TRIGGER links it
❌ Oracle: Use :NEW and :OLD
✅ PostgreSQL: Use NEW and OLD (no colon)
❌ Oracle: Use INSERTING, UPDATING, DELETING
✅ PostgreSQL: Use TG_OP = 'INSERT' / 'UPDATE' / 'DELETE'
✅ PostgreSQL: Must RETURN NEW, OLD, or NULL

7. Date and Timestamp Handling Differences

Date handling is one of the biggest sources of bugs in Oracle to PostgreSQL migrations.

Date Arithmetic

SQL - Oracle Date Arithmetic

-- Oracle: Add days directly to dates
SELECT 
    hire_date,
    hire_date + 7 AS one_week_later,
    hire_date - 7 AS one_week_earlier,
    hire_date + 1/24 AS one_hour_later,
    SYSDATE - hire_date AS days_employed
FROM employees;

SQL - PostgreSQL Date Arithmetic

-- PostgreSQL: Use INTERVAL for date arithmetic
SELECT 
    hire_date,
    hire_date + INTERVAL '7 days' AS one_week_later,
    hire_date - INTERVAL '7 days' AS one_week_earlier,
    hire_date + INTERVAL '1 hour' AS one_hour_later,
    CURRENT_TIMESTAMP - hire_date AS time_employed  -- Returns INTERVAL
FROM employees;

-- To get days as number:
SELECT 
    EXTRACT(DAY FROM CURRENT_TIMESTAMP - hire_date) AS days_employed
FROM employees;

Date Formatting

SQL - Oracle Date Formatting

-- Oracle: TO_CHAR for formatting
SELECT 
    TO_CHAR(hire_date, 'YYYY-MM-DD') AS iso_date,
    TO_CHAR(hire_date, 'DD-MON-YYYY') AS oracle_format,
    TO_CHAR(hire_date, 'HH24:MI:SS') AS time_only
FROM employees;

SQL - PostgreSQL Date Formatting

-- PostgreSQL: TO_CHAR works similarly (some format differences)
SELECT 
    TO_CHAR(hire_date, 'YYYY-MM-DD') AS iso_date,
    TO_CHAR(hire_date, 'DD-Mon-YYYY') AS postgres_format,  -- 'Mon' not 'MON'
    TO_CHAR(hire_date, 'HH24:MI:SS') AS time_only
FROM employees;

8. Transaction Control and Error Handling

PostgreSQL handles transactions differently than Oracle, especially in stored procedures.

Transaction Control Differences

Feature	Oracle	PostgreSQL
COMMIT in procedures	Allowed	Not allowed in functions
ROLLBACK in procedures	Allowed	Not allowed in functions
Autonomous transactions	PRAGMA AUTONOMOUS_TRANSACTION	Use dblink or separate connection
Savepoints	Supported	Supported (same syntax)

⚠️ Critical Difference: No COMMIT/ROLLBACK in PostgreSQL Functions

PostgreSQL functions run within the calling transaction. They cannot COMMIT or ROLLBACK independently. If you need transaction control, use stored procedures (PostgreSQL 11+) or handle transactions at the application level.

SQL - PostgreSQL 11+ Stored Procedure with Transaction Control

-- PostgreSQL 11+: Use PROCEDURE (not FUNCTION) for transaction control
CREATE OR REPLACE PROCEDURE batch_process_orders()
LANGUAGE plpgsql
AS $$
DECLARE
    r RECORD;
BEGIN
    FOR r IN SELECT order_id FROM orders WHERE status = 'PENDING' LOOP
        BEGIN
            -- Process order
            UPDATE orders SET status = 'PROCESSING' WHERE order_id = r.order_id;
            
            -- Some complex processing...
            
            -- Commit each order individually
            COMMIT;
        EXCEPTION
            WHEN OTHERS THEN
                -- Rollback this order, continue with next
                ROLLBACK;
                RAISE NOTICE 'Failed to process order %', r.order_id;
        END;
    END LOOP;
END;
$$;

-- Call procedure
CALL batch_process_orders();

9. FAQ

Can I use automated tools to convert Oracle to PostgreSQL?

Yes, but with caution. Tools like ora2pg, AWS Schema Conversion Tool, and pgloader can convert 70-80% of basic SQL automatically. However, they struggle with complex PL/SQL procedures, packages, and Oracle-specific features. Best approach: use tools for initial conversion, then manually review and test everything. Expect to spend 30-40% of migration time fixing tool-generated code. The value is getting 80% done quickly, not getting a perfect conversion.

What's the hardest part of Oracle to PostgreSQL migration?

Complex PL/SQL packages and Oracle-specific features like: (1) DBMS packages (DBMS_JOB, DBMS_SCHEDULER, DBMS_OUTPUT), (2) Database links, (3) Materialized views with refresh groups, (4) Advanced queuing, (5) Flashback queries. These require architectural changes, not just SQL conversion. For example, Oracle database links might become PostgreSQL Foreign Data Wrappers (FDW) or application-level API calls. Budget extra time for these.

Should I mention Oracle to PostgreSQL conversion experience on my resume?

Absolutely. Write: "Converted 800+ Oracle PL/SQL procedures to PostgreSQL PL/pgSQL, including complex triggers, functions, and data type migrations. Expertise in ora2pg tool, SQL syntax differences, and performance optimization post-migration." Even if you used automated tools heavily, understanding the conversion patterns and troubleshooting migration issues is valuable experience. PostgreSQL adoption is growing rapidly—this skill is in high demand.

How do I handle Oracle packages in PostgreSQL?

PostgreSQL doesn't have packages. Solutions: (1) Use schemas to group related functions (one schema = one Oracle package), (2) Use naming conventions (hr_get_employee, hr_update_salary), (3) Consider table-based "packages" where you store package state in tables. For DBMS packages: DBMS_OUTPUT → RAISE NOTICE, DBMS_RANDOM → gen_random_uuid(), DBMS_SCHEDULER → pg_cron extension. Oracle packages provide namespace organization—PostgreSQL schemas provide similar capability.

10. Related Reading from Real Production Systems

About the Author

Chetan Yadav

Throughout his career, Chetan has led multiple successful Oracle to PostgreSQL migrations for enterprises in finance, healthcare, and e-commerce sectors. He has converted thousands of Oracle PL/SQL procedures to PostgreSQL PL/pgSQL and optimized migrated databases for production workloads.

Chetan is passionate about mentoring early-career DBAs and sharing real-world production lessons that aren't found in documentation. His writing focuses on practical decision-making, career growth, and the operational realities of database administration.

This blog focuses on real-world DBA problems, career growth, and practical learning — not theoretical documentation or vendor marketing.

Automating Backup and Restore in Oracle 19c and 23ai: Complete DBA Guide

2026-02-16T14:10:00.001+05:30

Automating Backup and Restore in Oracle 19c and 23ai: Complete DBA Guide

Production-Tested RMAN Automation Scripts and Recovery Strategies

📅 February 05, 2026

👤 Chetan Yadav - Senior Oracle & Cloud DBA

⏱️ 18-20 min read

⏱️ Estimated Reading Time: 18–20 minutes

💾 Oracle RMAN Automation - From Manual Backups to Fully Automated Recovery

At 3 AM on a Tuesday, our production Oracle 19c database crashed. Corrupted datafile. The application team was screaming. The CTO was on the call. Everyone looked at me.

I typed one command: ./restore_prod.sh PRODDB 2026-02-04_23:00. Twenty-three minutes later, the database was back online with zero data loss. The automated backup and restore framework I'd built six months earlier just saved our jobs.

Manual backup and restore processes are where Oracle DBAs lose the most time. Automating RMAN backups isn't about convenience—it's about reliability, consistency, and being able to restore in minutes instead of hours when production is down.

This guide covers production-tested automation frameworks for Oracle 19c and 23ai. If you're still running manual RMAN scripts or struggling with backup consistency, these patterns will save you hours every week and make disaster recovery predictable.

📚 Table of Contents

Why Automate? The Cost of Manual Backup Management
RMAN Fundamentals: 19c vs 23ai Differences That Matter
Building the Automation Framework: Architecture and Design
Full Database Backup Automation Script
Incremental Backup Strategy with Automated Scheduling
Automated Restore and Recovery Procedures
Monitoring, Alerting, and Backup Validation
Oracle 23ai New Features: Automated Recovery Enhancements
FAQ
Related Reading from Real Production Systems

1. Why Automate? The Cost of Manual Backup Management

Let's quantify what manual backup management actually costs your organization in time, risk, and recovery capability.

The Hidden Costs of Manual Backups

Manual Process	Time per Week	Annual Cost (@ $80k salary)	Risk Factor
Running nightly backups	2.5 hours	$4,800	Forgotten backups
Validating backup success	3 hours	$5,760	Undetected failures
Managing backup retention	1.5 hours	$2,880	Storage overruns
Testing restore procedures	4 hours/month	$2,304	Untested restores
Total Annual Cost	-	$15,744	High

Reality check: This doesn't include the cost of a failed restore during an outage (average: $5,600 per minute of downtime for enterprise applications).

What Full Automation Gives You

✅ Consistency: Same backup process every time, no human error
✅ Validation: Automatic backup verification and alerting on failures
✅ Recovery confidence: Tested restore procedures, not theoretical ones
✅ Audit compliance: Automated logging for SOC2, HIPAA, PCI-DSS
✅ Time savings: 10+ hours per week back for actual DBA work

2. RMAN Fundamentals: 19c vs 23ai Differences That Matter

Oracle 23ai introduces several backup and recovery enhancements that change automation strategies.

Feature	Oracle 19c	Oracle 23ai	Impact
Fast Recovery Area	Manual FRA management	Automated FRA expansion	Reduces storage monitoring
Backup Optimization	Standard optimization	AI-driven deduplication	30-40% smaller backups
Restore Preview	Manual estimation	Predictive RTO calculation	Accurate recovery planning
Incremental Merge	Manual BACKUP INCREMENTAL	Automated incremental forever	Faster backups
Cross-Platform Backup	Limited support	Cloud-native backup API	Multi-cloud backup support

Oracle 23ai Key Enhancements

1. Automated Backup Validation:

Built-in backup integrity checks during backup creation
Automatic corruption detection without separate VALIDATE command
Reduces backup window by 15-20%

2. Predictive Recovery Analytics:

RMAN estimates RTO before you start recovery
Machine learning predicts recovery time based on historical data
Helps prioritize which recovery method (backup restore vs flashback)

3. Cloud Integration:

Native backup to AWS S3, Azure Blob, GCP Cloud Storage
No third-party tools needed (Oracle 19c requires OSB or ZDLRA)
Automatic encryption for cloud backups

3. Building the Automation Framework: Architecture and Design

A production-grade backup automation framework needs more than just RMAN scripts. Here's the architecture that works.

Framework Components

Backup Orchestrator: Master script that coordinates all backup operations
RMAN Script Library: Reusable RMAN command files for different backup scenarios
Logging and Alerting: Centralized logging with automatic failure alerts
Validation Engine: Post-backup verification and integrity checks
Retention Manager: Automated obsolete backup deletion
Recovery Tester: Periodic automated restore tests to dev/test environments

Directory Structure

Bash - Directory Structure for Backup Automation

/oracle/backup/
├── bin/
│   ├── backup_orchestrator.sh      # Main automation script
│   ├── restore_orchestrator.sh     # Recovery automation script
│   └── backup_validator.sh         # Post-backup validation
├── rman/
│   ├── full_backup.rman           # Full backup RMAN script
│   ├── incremental_backup.rman    # Incremental backup script
│   ├── archivelog_backup.rman     # Archive log backup
│   └── restore_database.rman      # Database restore script
├── logs/
│   ├── backup_YYYYMMDD.log
│   └── restore_YYYYMMDD.log
├── config/
│   ├── databases.conf             # Database list and parameters
│   └── retention.conf             # Retention policy settings
└── sql/
    ├── pre_backup_checks.sql
    └── post_restore_validation.sql

4. Full Database Backup Automation Script

This is the production-tested full backup script we use for Oracle 19c and 23ai databases.

Bash - Full Backup Orchestrator Script

#!/bin/bash
# backup_orchestrator.sh - Full database backup automation
# Compatible with Oracle 19c and 23ai

# Configuration
export ORACLE_SID=$1
export BACKUP_BASE="/oracle/backup"
export LOG_DIR="${BACKUP_BASE}/logs"
export RMAN_DIR="${BACKUP_BASE}/rman"
export BACKUP_DEST="/backup/oracle/${ORACLE_SID}"
DATE_STAMP=$(date +%Y%m%d_%H%M%S)
LOG_FILE="${LOG_DIR}/backup_${ORACLE_SID}_${DATE_STAMP}.log"

# Source Oracle environment
. /home/oracle/.bash_profile

# Logging function
log_message() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a ${LOG_FILE}
}

# Error handling
error_exit() {
    log_message "ERROR: $1"
    # Send alert (integrate with your alerting system)
    echo "BACKUP FAILED: ${ORACLE_SID}" | mail -s "Oracle Backup Failure" dba-team@company.com
    exit 1
}

# Main backup function
main() {
    log_message "Starting full backup for ${ORACLE_SID}"
    
    # Pre-backup checks
    log_message "Running pre-backup validation..."
    sqlplus -s / as sysdba @${BACKUP_BASE}/sql/pre_backup_checks.sql >> ${LOG_FILE} 2>&1
    if [ $? -ne 0 ]; then
        error_exit "Pre-backup checks failed"
    fi
    
    # Check Fast Recovery Area space
    log_message "Checking FRA space..."
    FRA_USED=$(sqlplus -s / as sysdba < 85" | bc -l) )); then
        error_exit "FRA usage at ${FRA_USED}% - insufficient space for backup"
    fi
    
    log_message "FRA usage: ${FRA_USED}%"
    
    # Execute RMAN backup
    log_message "Starting RMAN full backup..."
    rman target / msglog=${LOG_FILE} append <

Scheduling the Backup

Crontab - Automated Backup Schedule

# Oracle Backup Automation - Crontab entries

# Full backup: Every Sunday at 2 AM
0 2 * * 0 /oracle/backup/bin/backup_orchestrator.sh PRODDB

# Incremental backup: Monday-Saturday at 2 AM
0 2 * * 1-6 /oracle/backup/bin/incremental_backup.sh PRODDB

# Archive log backup: Every 4 hours
0 */4 * * * /oracle/backup/bin/archivelog_backup.sh PRODDB

# Backup validation: Daily at 8 AM
0 8 * * * /oracle/backup/bin/backup_validator.sh PRODDB

# Cleanup old logs: Weekly
0 3 * * 0 find /oracle/backup/logs -name "*.log" -mtime +30 -delete

5. Incremental Backup Strategy with Automated Scheduling

Incremental backups reduce backup windows and storage requirements. Here's the optimal strategy for production systems.

Incremental Backup Levels Explained

Level 0: Full backup baseline (all data blocks)
Level 1 Differential: Backs up blocks changed since last Level 0
Level 1 Cumulative: Backs up blocks changed since last Level 0 (faster restore)

Recommended Weekly Schedule

Day	Backup Type	Backup Window	Recovery Complexity
Sunday	Level 0 (Full)	2-4 hours	Simplest
Monday-Wednesday	Level 1 Differential	30-60 min	Moderate
Thursday	Level 1 Cumulative	45-90 min	Simple
Friday-Saturday	Level 1 Differential	30-60 min	Moderate

RMAN - Incremental Backup Script

RUN {
    ALLOCATE CHANNEL ch1 DEVICE TYPE DISK;
    ALLOCATE CHANNEL ch2 DEVICE TYPE DISK;
    
    # Incremental Level 1 differential backup
    BACKUP AS COMPRESSED BACKUPSET
        INCREMENTAL LEVEL 1
        DATABASE
        TAG 'INCR_DIFF_${DATE_STAMP}'
        FILESPERSET 4;
    
    # Archive log backup
    BACKUP ARCHIVELOG ALL DELETE INPUT TAG 'ARCH_${DATE_STAMP}';
    
    # Control file backup
    BACKUP CURRENT CONTROLFILE TAG 'CTL_INCR_${DATE_STAMP}';
    
    # Maintenance
    CROSSCHECK BACKUP;
    DELETE NOPROMPT EXPIRED BACKUP;
    REPORT OBSOLETE;
    
    RELEASE CHANNEL ch1;
    RELEASE CHANNEL ch2;
}

6. Automated Restore and Recovery Procedures

Restoring a database shouldn't require looking up documentation at 3 AM. Here's the automated restore framework.

Bash - Automated Restore Script

#!/bin/bash
# restore_orchestrator.sh - Automated database restore
# Usage: ./restore_orchestrator.sh ORACLE_SID [POINT_IN_TIME]

export ORACLE_SID=$1
export RESTORE_TIME=$2  # Optional: Format YYYY-MM-DD HH24:MI:SS
export BACKUP_BASE="/oracle/backup"
export LOG_DIR="${BACKUP_BASE}/logs"
DATE_STAMP=$(date +%Y%m%d_%H%M%S)
LOG_FILE="${LOG_DIR}/restore_${ORACLE_SID}_${DATE_STAMP}.log"

. /home/oracle/.bash_profile

log_message() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a ${LOG_FILE}
}

restore_database() {
    log_message "Starting restore for ${ORACLE_SID}"
    
    # Shutdown database
    log_message "Shutting down database..."
    sqlplus -s / as sysdba <> ${LOG_FILE}
SHUTDOWN ABORT;
EXIT;
EOF
    
    # Startup in nomount mode
    log_message "Starting database in NOMOUNT..."
    sqlplus -s / as sysdba <> ${LOG_FILE}
STARTUP NOMOUNT;
EXIT;
EOF
    
    # Restore controlfile
    log_message "Restoring controlfile from autobackup..."
    rman target / msglog=${LOG_FILE} append <> ${LOG_FILE}
ALTER DATABASE MOUNT;
EXIT;
EOF
    
    # Restore and recover database
    log_message "Restoring and recovering database..."
    
    if [ -z "${RESTORE_TIME}" ]; then
        # Complete recovery
        rman target / msglog=${LOG_FILE} append <> ${LOG_FILE}
ALTER DATABASE OPEN;
EXIT;
EOF
    else
        sqlplus -s / as sysdba <> ${LOG_FILE}
ALTER DATABASE OPEN RESETLOGS;
EXIT;
EOF
    fi
    
    # Post-restore validation
    log_message "Running post-restore validation..."
    sqlplus -s / as sysdba @${BACKUP_BASE}/sql/post_restore_validation.sql >> ${LOG_FILE}
    
    log_message "Restore completed successfully"
    log_message "Database ${ORACLE_SID} is now OPEN"
    
    # Send notification
    echo "Database restore completed successfully
Database: ${ORACLE_SID}
Restore Time: ${RESTORE_TIME:-Complete Recovery}
Log: ${LOG_FILE}" | mail -s "Oracle Restore Success: ${ORACLE_SID}" dba-team@company.com
}

# Execute restore
restore_database

7. Monitoring, Alerting, and Backup Validation

Backups are useless if you can't restore from them. Automated validation ensures your backups work.

Backup Validation Checks

SQL - Backup Status Monitoring Query

-- Check recent backup status
SELECT 
    TO_CHAR(start_time, 'YYYY-MM-DD HH24:MI') AS backup_start,
    TO_CHAR(end_time, 'YYYY-MM-DD HH24:MI') AS backup_end,
    ROUND((end_time - start_time) * 24 * 60, 2) AS duration_minutes,
    input_type,
    status,
    ROUND(input_bytes/1024/1024/1024, 2) AS input_gb,
    ROUND(output_bytes/1024/1024/1024, 2) AS output_gb,
    ROUND(output_bytes/input_bytes * 100, 2) AS compression_ratio
FROM v$rman_backup_job_details
WHERE start_time > SYSDATE - 7
ORDER BY start_time DESC;

-- Check for backup failures
SELECT 
    session_key,
    TO_CHAR(start_time, 'YYYY-MM-DD HH24:MI:SS') AS failure_time,
    operation,
    status,
    mbytes_processed,
    object_type
FROM v$rman_status
WHERE status IN ('FAILED', 'FAILED WITH WARNINGS')
  AND start_time > SYSDATE - 7
ORDER BY start_time DESC;

-- Validate backup coverage
SELECT 
    file#,
    name,
    TO_CHAR(MAX(completion_time), 'YYYY-MM-DD HH24:MI:SS') AS last_backup
FROM v$backup_datafile
WHERE completion_time IS NOT NULL
GROUP BY file#, name
HAVING MAX(completion_time) < SYSDATE - 1
ORDER BY MAX(completion_time);

Automated Alert System

Bash - Backup Monitoring and Alerting

#!/bin/bash
# backup_validator.sh - Automated backup validation and alerting

export ORACLE_SID=$1
export BACKUP_BASE="/oracle/backup"
DATE_STAMP=$(date +%Y%m%d)

. /home/oracle/.bash_profile

# Check if backup ran in last 24 hours
BACKUP_COUNT=$(sqlplus -s / as sysdba < SYSDATE - 1
  AND status = 'COMPLETED';
EXIT;
EOF
)

if [ ${BACKUP_COUNT} -eq 0 ]; then
    echo "ALERT: No successful backup in last 24 hours for ${ORACLE_SID}" | \
        mail -s "Backup Missing: ${ORACLE_SID}" dba-team@company.com
    exit 1
fi

# Check for backup failures
FAILURE_COUNT=$(sqlplus -s / as sysdba < SYSDATE - 1;
EXIT;
EOF
)

if [ ${FAILURE_COUNT} -gt 0 ]; then
    echo "ALERT: ${FAILURE_COUNT} backup failures detected in ${ORACLE_SID}" | \
        mail -s "Backup Failures: ${ORACLE_SID}" dba-team@company.com
fi

# Check FRA usage
FRA_USAGE=$(sqlplus -s / as sysdba < 90" | bc -l) )); then
    echo "ALERT: FRA usage at ${FRA_USAGE}% for ${ORACLE_SID}" | \
        mail -s "FRA Space Critical: ${ORACLE_SID}" dba-team@company.com
fi

echo "Backup validation completed for ${ORACLE_SID}"

8. Oracle 23ai New Features: Automated Recovery Enhancements

Oracle 23ai introduces several automation features that make backup and recovery even more reliable.

1. Predictive Recovery Time (23ai)

RMAN - Estimate Recovery Time (23ai)

-- Oracle 23ai: Predict recovery time before starting
RMAN> ESTIMATE RECOVERY TIME;

Starting estimate recovery at 05-FEB-26
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=245 device type=DISK

Estimated Recovery Time Statistics
==================================
Recovery Type: COMPLETE RECOVERY
Estimated Duration: 23 minutes
Estimated Data Blocks: 2,456,789
Estimated Archive Logs: 45 logs (125GB)
Confidence Level: 95%

Recovery time estimated based on:
- Historical recovery performance
- Current system resources
- Backup block sizes
- Archive log volume

2. Automated Cloud Backup (23ai)

RMAN - Direct Cloud Backup Configuration (23ai)

-- Configure direct backup to AWS S3 (Oracle 23ai)
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' 
    PARMS 'SBT_LIBRARY=/opt/oracle/lib/libosbws.so,
           SBT_PARMS=(OSB_WS_BUCKET=prod-oracle-backups,
                     OSB_WS_REGION=us-east-1)';

-- Backup directly to cloud
BACKUP AS COMPRESSED BACKUPSET 
    INCREMENTAL LEVEL 0
    DATABASE
    TAG 'CLOUD_BACKUP_${DATE}'
    PLUS ARCHIVELOG DELETE INPUT;

-- Oracle 23ai automatically:
-- - Encrypts backups to cloud
-- - Manages object lifecycle
-- - Validates backups after upload
-- - Provides cross-region replication

3. Incremental Forever with Auto-Merge (23ai)

Oracle 23ai can automatically maintain incremental backups without periodic Level 0 backups.

RMAN - Configure Incremental Forever (23ai)

-- Configure incremental forever strategy
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE INCREMENTAL FOREVER ON;
CONFIGURE AUTO MERGE WINDOW 7;

-- Oracle 23ai automatically:
-- - Creates initial Level 0 backup
-- - Takes Level 1 incrementals daily
-- - Merges incrementals into image copy weekly
-- - Never requires another full backup

BACKUP INCREMENTAL LEVEL 1 
    FOR RECOVER OF COPY WITH TAG 'INCR_FOREVER'
    DATABASE;

9. FAQ

Should I use RMAN or Data Pump for backups?

Use RMAN for production databases, always. RMAN provides block-level backups, point-in-time recovery, incremental backups, and is integrated with Oracle's recovery mechanisms. Data Pump is for logical backups (schema exports, data migration) not for disaster recovery. Think of it this way: RMAN is for "the database crashed, restore everything NOW" scenarios. Data Pump is for "we need to migrate this schema to test environment" scenarios.

How often should I test restore procedures?

Monthly minimum for production databases, quarterly for less critical systems. Your automated restore testing should include: (1) Full database restore to a separate server, (2) Point-in-time recovery to verify archive log chain, (3) Single tablespace recovery, (4) Individual datafile recovery. If you haven't restored from your backups in the last 30 days, you don't actually know if they work. Automate this testing—don't wait for production outage to discover your backups are corrupt.

What's the difference between Oracle 19c and 23ai backup automation?

Oracle 23ai adds: (1) Native cloud backup API (no OSB/ZDLRA needed), (2) Predictive recovery time estimation using ML, (3) Automated incremental forever with auto-merge, (4) Built-in backup validation during backup (not separate step), (5) Automated FRA expansion. For most DBAs, the biggest win is native cloud backup support—you can backup directly to S3/Azure/GCP without third-party tools. The predictive recovery estimation is also huge for SLA planning.

Should I mention backup automation experience on my resume if I haven't built it from scratch?

Absolutely. Even if you're using scripts someone else wrote, if you understand how they work, can troubleshoot backup failures, and can perform restores, that's valuable experience. Write: "Managed automated Oracle RMAN backup framework for production databases, including monitoring backup success rates, troubleshooting failures, and performing test restores." What matters is you understand backup/recovery concepts and can execute them reliably—not whether you wrote the first version of the script.

10. Related Reading from Real Production Systems

About the Author

Chetan Yadav

Throughout his career, Chetan has designed and implemented automated backup frameworks for mission-critical Oracle databases in finance, healthcare, and e-commerce sectors. He has successfully recovered dozens of production databases from disasters and has automated backup processes that manage petabytes of Oracle data.

Chetan is passionate about mentoring early-career DBAs and sharing real-world production lessons that aren't found in documentation. His writing focuses on practical decision-making, career growth, and the operational realities of database administration.

This blog focuses on real-world DBA problems, career growth, and practical learning — not theoretical documentation or vendor marketing.

Chetan Yadav

Oracle High CPU Usage: Causes and Fix in 19c

Oracle High CPU Usage: Causes and Fix in 19c

Cause 1: Runaway SQL and Oracle CPU Spike from Bad Execution Plans

Cause 2: Parallel Query CPU Overload from Uncontrolled DOP in Oracle 19c

Cause 3: Latch Contention and Library Cache CPU Spin in Oracle 19c

What Most DBAs Miss When Diagnosing Oracle High CPU Usage

Prevention: Monitoring Setup for Oracle CPU Spikes in 19c

Enable automatic AWR baselines for peak periods

Set a hard limit on PARALLEL_MAX_SERVERS

Monitor hard parse rate daily via a scheduled query

Frequently Asked Questions

Want the Complete Oracle Performance Toolkit?

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

How to Read an Oracle AWR Report in 19c

What this guide covers

What an AWR report actually tells you

How to read an Oracle AWR report in 19c: the 6-step order

The reading order

Steps 1 to 3: the 90-second triage

Step 1: Header and DB Time

Step 2: Load Profile

Step 3: Instance Efficiency

Step 4: Top 10 Foreground Wait Events (the heart)

Step 5: SQL Statistics, mapping waits to SQL

Generating the report in 19c

What NOT to do with an AWR report

Do NOT do this

Do this instead

Frequently asked questions

How do you read an Oracle AWR report in 19c quickly?

What is the first section to check when you read an Oracle AWR report in 19c?

What is a healthy DB Time to Elapsed Time ratio?

How long should the AWR snapshot window be?

Is AWR free to use in Oracle 19c?

Want my AWR triage cheat sheet?

Related reading

Standby Redo Logs Not Applying Oracle Data Guard Fix

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

SRL Architecture: Why Standby Redo Logs Matter

Step 1: Diagnose the Apply Engine

Query 1: MRP and RFS Process Status

Query 2: Standby Redo Log Status

Query 3: Apply Lag and Transport Lag

Query 4: Archive Destination Status

Step 2: Create or Fix Standby Redo Logs

Check Current Online Redo Log Size (Run on Primary)

Add SRL Groups on the Standby

Drop and Re-create Undersized SRL Groups

Step 3: Start or Restart the MRP Process

Start MRP in Background (Recommended)

Stop MRP Cleanly Before Restarting

Verify MRP Started Correctly

Step 4: Fix LOG_ARCHIVE_DEST Configuration

Check Current Configuration (Primary)

Wrong Configuration

Correct Configuration

Step 5: Resolve an Archive Gap

Detect Gaps

Register Missing Archivelogs Manually

Fix FAL Parameters (Prevents Future Gaps)

Step 6: Tune Parallel Apply to Burn Down Lag Faster

Post-Fix Verification Checklist

What NOT to Do When Standby Redo Logs Are Not Applying

Frequently Asked Questions

Want the Full Data Guard Troubleshooting Runbook?

Related Reading

Oracle Data Guard Switchover vs Failover: Step-by-Step Guide

Oracle Data Guard Apply Lag: Root Causes and Fixes

Oracle 19c RAC Architecture: Complete DBA Guide

Oracle High Availability: RAC, Data Guard, GoldenGate Compared

Oracle DBA Resume Guide: Get Shortlisted in 2026

Chetan Yadav

Fresher Resume Format for Tech Jobs 2026: ATS Tips

Fresher Resume Format for Tech Jobs 2026

Why Fresher Resumes Fail Before a Human Reads Them

The Correct Fresher Resume Format for Tech Jobs 2026

The Section Order That Works

Step-by-Step: Build Your Resume This Week

Step 1: Collect Three Target Job Descriptions