End-to-End Data Guard Recovery: Standby Controlfile Restore, Catalog, Switch Database to Copy, and MRP Restart

 

To perform this operation safely on a Production environment, you must execute these steps in a precise, logical sequence. Since you are modifying the standby controlfile and re-aligning it with existing physical data files on disk, the order of execution is critical to avoid data loss or accidental file overwrites.

Forget your old metadata, learn the current primary database structure, match your existing files, and then apply missing changes

Step-by-Step Production Sequence

Step 1: Stop Redo Apply (MRP)

You must halt the Managed Recovery Process before changing the state of the database or its controlfiles.

• Run on Standby (SQL*Plus):
  sql

  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

Step 2: Shutdown and Restart Standby in NOMOUNT State

To overwrite or restore a new standby controlfile, the database must not have the old controlfile locked or mounted.

• Run on Standby (SQL*Plus):
  sql

  SHUTDOWN IMMEDIATE;
  STARTUP NOMOUNT;

Step 3: Restore the Standby Controlfile from the Primary Service

Connect to RMAN on the standby and pull the fresh metadata directly from the active primary database instance (ORCL).

• Run on Standby (RMAN):
  program

  rman target /
  RMAN> RESTORE STANDBY CONTROLFILE FROM SERVICE 'ORCL';
  
  What is a Controlfile?
  The controlfile contains the database metadata:
  Datafile names and locations
  Redo log file names
  Standby redo log information
  PDB information
  Checkpoint SCNs
  Archive log history
  RMAN repository information

Why restore it?

Suppose on Primary:

DROP PLUGGABLE DATABASE PDBORCL01 INCLUDING DATAFILES;

Primary controlfile now knows:

PDBORCL01 does not exist

But standby controlfile still knows:

PDBORCL01 exists

Datafile 14 exists

Now MRP applies redo and sees:

Primary says file removed

Standby says file exists

Result:

ORA-65138

ORA-10458

Therefore we restore the latest standby controlfile from Primary.

After restore:

Primary Metadata = Standby Metadata

Step 4: Mount the Standby Database

Now that the fresh controlfile is in place, mount the database so Oracle can load the primary's structural metadata into memory.

• Run on Standby (RMAN or SQL*Plus):
  sql

  ALTER DATABASE MOUNT;

Step 5: Catalog the Existing Standby Data Files

Because the primary controlfile points to the primary's storage path (e.g., +DATAC1), you must tell RMAN where the actual physical files live on the standby storage (e.g., +DATAC2).

• Run on Standby (RMAN):
  program

  RMAN> CATALOG START WITH '+DATAC2/D2/' NOPROMPT;
  
  (Note: Ensure the trailing slash is included in the path so RMAN scans the directory correctly).

Step 6: Switch the Controlfile Pointers to the Local Files

This step instantly rewrites the newly restored controlfile pointers to use the disk paths discovered during the catalog step.

• Run on Standby (RMAN):
  program

  RMAN> SWITCH DATABASE TO COPY;

Step 7: Roll Forward the Standby via Primary Service (Incremental Sync)

Instead of processing days of archived logs, this command performs an online network-based incremental roll-forward. It synchronizes the SCN gaps by blocks.

• Run on Standby (RMAN):
  program

  RMAN> RECOVER STANDBY DATABASE FROM SERVICE 'ORCL';
  
  Exit RMAN once completed successfully.

Step 8: Clear Standby Redo Logs (Optional but Recommended for Production)

Before starting MRP, it is a production best practice to clear the standby redo logs to prevent archival or synchronization hangs due to mismatched log metadata.

• Run on Standby (SQL*Plus):
  Review your log groups via SELECT GROUP# FROM V$LOGFILE; and clear them:
  sql

  ALTER DATABASE CLEAR LOGFILE GROUP 1;
  ALTER DATABASE CLEAR LOGFILE GROUP 2;
  -- Repeat for all standby redo log groups

Step 9: Restart Managed Recovery Process (MRP)

Start the redo apply engine to keep the standby in continuous real-time synchronization with the primary.

• Run on Standby (SQL*Plus):
  sql

  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
  -- Or if using Real-Time Apply:
  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
  

  
  

🔍 Verification Steps

Once the sequence is complete, run these queries in SQL*Plus on the Standby to confirm health status:

1. Check Data Guard Role and Open Mode:
   sql

   SELECT database_role, open_mode, protection_mode FROM v$database;

Check MRP Status:

sql

SELECT process, status, sequence# FROM v$managed_standby WHERE process LIKE 'MRP%';