Oracle 8 min readMay 29, 2025

Rolling Forward a Physical Standby Using RMAN Incremental Backup

Reference: Oracle MOS DocID 836986.1

Problem Statement

A physical standby database falls too far behind the primary. The archive logs needed to apply are no longer available — either because the primary's FRA was too small, logs were deleted, or the standby was down for an extended period.

A full rebuild (active duplicate) would take too long. The incremental backup roll-forward method is faster because it only transfers changed blocks since the standby's current SCN — not the entire database.

Full Rebuild

Transfers entire DB over network

Incremental Roll-forward

Transfers only changed blocks since standby SCN

Step 1 — Get the Standby's Current SCN

Connect to the standby and capture the SCN to use as the incremental backup start point:

sql

-- On STANDBY
SELECT current_scn FROM v$database;

-- More precise: minimum SCN across all datafile headers
SELECT MIN(fhscn) FROM x$kcvfh;

-- Note this value — it becomes the FROM SCN for the primary backup
-- Example: 9823746510

Step 2 — Stop MRP on Standby

sql

-- On STANDBY
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

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

Step 3 — Take Incremental Backup on Primary FROM Standby SCN

Connect to primary and take an incremental backup starting from the standby's SCN:

bash

# On PRIMARY
rman target /

sql

-- Replace 9823746510 with the SCN captured from standby in Step 1
BACKUP INCREMENTAL FROM SCN 9823746510
  DATABASE FORMAT '/oracle/backup/rollforward/inc_%U'
  TAG 'STANDBY_ROLLFORWARD';

-- Also backup the current control file
BACKUP CURRENT CONTROLFILE
  FOR STANDBY
  FORMAT '/oracle/backup/rollforward/stby_ctrl_%U';

💡

The incremental backup captures only blocks changed since the standby's SCN — much smaller than a full backup for a recent outage.

Step 4 — Transfer Backup Files to Standby

bash

# From PRIMARY, transfer backup pieces to standby server
scp /oracle/backup/rollforward/inc_*     oracle@standby-server:/oracle/backup/rollforward/

scp /oracle/backup/rollforward/stby_ctrl_*     oracle@standby-server:/oracle/backup/rollforward/

Step 5 — Restore the Standby Control File

On standby, mount with the new control file from primary:

bash

# On STANDBY
rman target /

RMAN> SHUTDOWN IMMEDIATE;
RMAN> STARTUP NOMOUNT;

sql

-- Catalog and restore the standby control file
CATALOG START WITH '/oracle/backup/rollforward/' NOPROMPT;

RESTORE STANDBY CONTROLFILE FROM '/oracle/backup/rollforward/stby_ctrl_xxx';

ALTER DATABASE MOUNT;

Step 6 — Catalog the Incremental Backup

sql

-- Catalog the incremental backup pieces transferred from primary
CATALOG START WITH '/oracle/backup/rollforward/' NOPROMPT;

Step 7 — Recover the Standby Using Incremental Backup

sql

-- Apply the incremental backup to roll forward the standby
RECOVER DATABASE NOREDO;

💡

NOREDO tells RMAN to apply only the incremental backup blocks — not to apply archive logs. The remaining gap will be closed when MRP starts and archive logs from primary are applied.

Step 8 — Switch Files and Start MRP

sql

-- In RMAN: switch database to use cataloged copies if needed
SWITCH DATABASE TO COPY;

-- In SQL*Plus: start MRP to apply archive logs and sync fully
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Step 9 — Verify Sync

sql

-- Check MRP is running and sequences are applying
SELECT process, status, thread#, sequence#
FROM v$managed_standby;

-- Check for archive gap
SELECT thread#, low_sequence#, high_sequence# FROM v$archive_gap;

-- Compare max applied vs max archived on primary
SELECT MAX(sequence#) FROM v$archived_log WHERE applied='YES';

Key Points

This method works for any size of gap — the backup is only as large as the changed blocks
If the standby is very old (months), a full rebuild might still be faster — evaluate the backup size first
Always take a standby control file backup alongside the incremental — they must match
After MRP starts, full synchronization may still take time as remaining archive logs are applied
You can run multiple incremental roll-forwards iteratively to get closer to primary before the final sync

All postsOracle · Standby · RMAN · DataGuard · MOS 836986.1