Every DBA managing an Oracle Data Guard setup eventually faces this situation. The standby database has fallen behind the primary, archive logs are missing, and managed recovery refuses to start. Most people assume a full standby rebuild is the only way out \u2014 but that can take hours or even an entire day depending on database size.<\/p>\n\n\n\n
There is a smarter approach. By taking an RMAN incremental backup from the primary database at the standby’s current SCN, you can bring everything back in sync without moving the full database. This method is faster, less disruptive, and works even when the redo gap is large.<\/p>\n\n\n\n
Understanding the root cause helps you prevent it from happening again. A standby loses sync when it stops receiving or applying redo data from the primary. Common causes include:<\/p>\n\n\n\n
Archive logs deleted on the primary before the standby could apply them \u2014 this usually happens when the Fast Recovery Area fills up or the retention policy is too aggressive. Network interruptions that break the redo transport stream for an extended period are another frequent culprit. Disk failures on the standby side can cause datafile corruption or log apply errors. A long maintenance window where the standby was intentionally taken offline also creates a gap. In all these situations, a full rebuild feels like overkill. The incremental backup approach targets exactly the missing data and nothing more.<\/p>\n\n\n\n
The logic behind this approach is simple. Every Oracle datafile block carries an SCN stamp that records when it was last changed. When you take an RMAN incremental backup from the primary starting at the standby’s lowest SCN, Oracle collects only the blocks modified since that point. Those changed blocks are then applied directly to the standby datafiles, fast-forwarding them to match the primary. After that, normal redo apply closes the remaining gap automatically.<\/p>\n\n\n\n
No full export. No duplicate operation. No unnecessary data movement across the network.<\/p>\n\n\n\n
Check that you have enough disk space on both servers for the incremental backup. Depending on how far behind the standby is, the backup size can vary significantly. Confirm that the Oracle OS user on the standby has SSH access from the primary, since files need to move between servers. Also note your current standby datafile paths \u2014 you will need them later if they differ from the primary.<\/p>\n\n\n\n
This is the most critical step in the entire process. An incorrect SCN will cause recovery to fail or leave the standby in a broken state. Connect to the standby and run the following queries:<\/p>\n\n\n\n
SELECT CURRENT_SCN FROM V$DATABASE;\n\nSELECT MIN(fhscn) FROM X$KCVFH;\n\nSELECT MIN(kc.fhscn)\nFROM X$KCVFH kc, V$DATAFILE dd\nWHERE kc.hxfil = dd.file#\nAND dd.enabled != 'READ ONLY';<\/code><\/pre>\n\n\n\nThe third query is the most reliable because it reads the SCN header of every writable datafile and returns the absolute lowest value. Use that number as your starting SCN. When uncertain, subtract a small buffer from it \u2014 starting the backup slightly earlier is always safer than starting it too late.<\/p>\n\n\n\n
\n\n\n\nStep 2 \u2014 Stop Managed Recovery and Shut Down the Standby<\/h2>\n\n\n\n
An incremental backup cannot be applied to a running database. Cancel the Managed Recovery Process first, then shut the standby down cleanly.<\/p>\n\n\n\n
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;\nSHUTDOWN IMMEDIATE;<\/code><\/pre>\n\n\n\nIf the shutdown hangs, run SHUTDOWN ABORT<\/code> followed by a clean startup and shutdown cycle. A consistent shutdown ensures all datafile headers are in a recoverable state before you proceed.<\/p>\n\n\n\n
\n\n\n\nStep 3 \u2014 Take the Incremental Backup on the Primary<\/h2>\n\n\n\n
Connect to the primary database through RMAN and run the backup using the SCN you identified in Step 1. The primary stays online throughout this operation \u2014 no downtime is needed.<\/p>\n\n\n\n
BACKUP INCREMENTAL FROM SCN 4829301\nDATABASE\nFORMAT '\/oracle\/backup\/increment_%U.bkp'\nDEVICE TYPE DISK;<\/code><\/pre>\n\n\n\nReplace 4829301<\/code> with your actual SCN value. The %U<\/code> placeholder generates unique filenames automatically. If RMAN has multiple channels configured, the backup runs in parallel and finishes faster.<\/p>\n\n\n\n
\n\n\n\nStep 4 \u2014 Back Up the Current Archived Logs<\/h2>\n\n\n\n
This step is often skipped in other guides, but it is important. After the incremental backup is applied, the standby still needs archived logs to reach real-time sync. Back them up now so they are ready to transfer alongside the incremental pieces.<\/p>\n\n\n\n
BACKUP ARCHIVELOG ALL\nFORMAT '\/oracle\/backup\/arch_%U.bkp';<\/code><\/pre>\n\n\n\n
\n\n\n\nStep 5 \u2014 Transfer All Backup Files to the Standby Server<\/h2>\n\n\n\n
Copy both the incremental backup and the archived log backup to the standby host.<\/p>\n\n\n\n
scp \/oracle\/backup\/increment_*.bkp oracle@standby:\/oracle\/backup\/\nscp \/oracle\/backup\/arch_*.bkp oracle@standby:\/oracle\/backup\/<\/code><\/pre>\n\n\n\nFor large files, rsync<\/code> is a better option as it compresses data during transfer and can resume automatically if the connection drops midway.<\/p>\n\n\n\n
\n\n\n\nStep 6 \u2014 Generate a Fresh Standby Control File on the Primary<\/h2>\n\n\n\n
The existing standby control file may be outdated. A fresh one must be created from the primary and transferred to the standby server.<\/p>\n\n\n\n
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '\/oracle\/backup\/standby.ctl';<\/code><\/pre>\n\n\n\nscp \/oracle\/backup\/standby.ctl oracle@standby:\/oracle\/backup\/<\/code><\/pre>\n\n\n\nAlways generate a new control file for this procedure. Reusing an old one risks inconsistencies between what the control file records and what actually exists on disk.<\/p>\n\n\n\n
\n\n\n\nStep 7 \u2014 Start the Standby Instance in NOMOUNT Mode<\/h2>\n\n\n\n
On the standby server, bring up the instance without mounting any database. At this point, Oracle reads only the parameter file.<\/p>\n\n\n\n
STARTUP NOMOUNT;<\/code><\/pre>\n\n\n\n
\n\n\n\nStep 8 \u2014 Restore the Control File via RMAN<\/h2>\n\n\n\n
Connect to the standby instance through RMAN and restore the control file you transferred in Step 6.<\/p>\n\n\n\n
RESTORE STANDBY CONTROLFILE FROM '\/oracle\/backup\/standby.ctl';<\/code><\/pre>\n\n\n\n
\n\n\n\nStep 9 \u2014 Mount the Standby Database<\/h2>\n\n\n\nALTER DATABASE MOUNT STANDBY DATABASE;<\/code><\/pre>\n\n\n\n
\n\n\n\nStep 10 \u2014 Catalog the Backup Files in RMAN<\/h2>\n\n\n\n
RMAN needs to register the backup pieces before it can use them for recovery. Run a catalog scan pointing to the backup directory.<\/p>\n\n\n\n
CATALOG START WITH '\/oracle\/backup\/';<\/code><\/pre>\n\n\n\nThis scans all files in the directory and registers both the incremental backup and the archived log backup in the control file. Verify that RMAN picks up all the files before moving forward.<\/p>\n\n\n\n
\n\n\n\nStep 11 \u2014 Remap Datafile Paths If Needed<\/h2>\n\n\n\n
Skip this step if your primary and standby servers use the same directory structure for datafiles. If the paths differ \u2014 which is common when the standby was built on different storage \u2014 you need to remap them before recovery.<\/p>\n\n\n\n
CATALOG START WITH '\/standby\/oradata\/';\nSWITCH DATABASE TO COPY;<\/code><\/pre>\n\n\n\nThe SWITCH DATABASE TO COPY<\/code> command updates the control file so all datafile references point to their correct standby locations. Missing this step is one of the most common reasons resync operations fail in cross-server environments.<\/p>\n\n\n\n
\n\n\n\nStep 12 \u2014 Apply the Incremental Backup<\/h2>\n\n\n\n
Now apply the incremental backup to the standby datafiles. The NOREDO<\/code> option tells RMAN not to apply redo at this stage \u2014 that happens later through managed recovery.<\/p>\n\n\n\nRECOVER DATABASE NOREDO;<\/code><\/pre>\n\n\n\nCompletion time depends on how many changed blocks were backed up. Watch the RMAN output carefully and make sure it finishes without errors before moving to the next step.<\/p>\n\n\n\n
\n\n\n\nStep 13 \u2014 Start Managed Recovery Process<\/h2>\n\n\n\n
With the incremental backup successfully applied, restart MRP. It will begin applying archived logs and eventually switch to real-time redo apply once it catches up with the primary.<\/p>\n\n\n\n
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE\nUSING CURRENT LOGFILE\nDISCONNECT FROM SESSION;<\/code><\/pre>\n\n\n\nThe DISCONNECT FROM SESSION<\/code> option runs MRP in the background so your session stays free for other work.<\/p>\n\n\n\n
\n\n\n\nVerifying the Standby Is Back in Sync<\/h2>\n\n\n\n
Check the MRP process to confirm it is actively applying redo data from the primary.<\/p>\n\n\n\n
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#\nFROM V$MANAGED_STANDBY;<\/code><\/pre>\n\n\n\nA status of APPLYING_LOG<\/code> means recovery is in progress. A status of WAIT_FOR_LOG<\/code> means the standby has caught up and is waiting for new redo \u2014 both are healthy outcomes.<\/p>\n\n\n\nRun this query to check for any remaining archive gaps.<\/p>\n\n\n\n
SELECT * FROM V$ARCHIVE_GAP;<\/code><\/pre>\n\n\n\nNo rows returned means no gaps exist. If rows do appear, transfer the missing sequences from the primary and register them manually before MRP can continue.<\/p>\n\n\n\n
To measure how close the standby is to the primary, compare the last applied sequence on the standby against what the primary is currently generating.<\/p>\n\n\n\n
-- Run on standby\nSELECT MAX(SEQUENCE#), APPLIED\nFROM V$ARCHIVED_LOG\nGROUP BY APPLIED;<\/code><\/pre>\n\n\n\n
\n\n\n\nMistakes That Will Break This Process<\/h2>\n\n\n\n
Using the wrong SCN<\/strong> is the most common error. The backup must start from the lowest SCN across all writable datafiles \u2014 not the current database SCN. Even one missed block will cause recovery to fail.<\/p>\n\n\n\nSkipping the archived log backup<\/strong> means the standby will apply the incremental backup successfully but then stall waiting for log files that were never transferred.<\/p>\n\n\n\nReusing an old control file<\/strong> instead of generating a fresh one from the primary can cause mismatches between what the control file expects and what physically exists on the standby server.<\/p>\n\n\n\n
\n\n\n\nWrapping Up<\/h2>\n\n\n\n
The RMAN incremental backup resync method solves a problem that most DBAs assume needs a full rebuild \u2014 and it does so in a fraction of the time. Once you have run through this procedure, it becomes the first tool you reach for whenever a standby has fallen too far behind for normal recovery.<\/p>\n\n\n\n
Getting the SCN right in Step 1 is everything. Nail that, and the rest of the procedure is straightforward.<\/p>\n","protected":false},"excerpt":{"rendered":"
Every DBA managing an Oracle Data Guard setup eventually faces this situation. The standby database has fallen behind the primary, archive logs are missing, and managed recovery refuses to start. Most people assume a full standby rebuild is the only way out \u2014 but that can take hours or even an entire day depending on […]<\/p>\n","protected":false},"author":1,"featured_media":5534,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"googlesitekit_rrm_CAowu461DA:productID":"","footnotes":""},"categories":[1225],"tags":[],"class_list":["post-5521","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-database"],"_links":{"self":[{"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/posts\/5521","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/comments?post=5521"}],"version-history":[{"count":1,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/posts\/5521\/revisions"}],"predecessor-version":[{"id":5522,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/posts\/5521\/revisions\/5522"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/media\/5534"}],"wp:attachment":[{"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/media?parent=5521"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/categories?post=5521"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/w3buddy.com\/blog\/wp-json\/wp\/v2\/tags?post=5521"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}