Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: RMAN Backup of Standby Database In Managed Recovery Mode

RE: RMAN Backup of Standby Database In Managed Recovery Mode

Date: Wed, 14 May 2003 11:57:29 -0800
Message-ID: <>

Arup - Sorry you didn't get any replies earlier. The part that confuses me is what you are trying to accomplish. I've never done a standby database, only what I've heard in class. But my understanding is that there are many actions you can take against the primary database that will render the standby unusable. Therefore, the usual issue isn't "how to back up the standby". It is only a copy of the primary, so most people are much more concerned about the primary and consider the standby a "throwaway" since it is just a copy of the primary. The usual issue is how to quickly rebuild the standby database. I believe that RMAN can help with that because, as you point out, it is good at performing online backups. Robert Freeman has a chapter on how to do that in his book.

Dennis Williams
DBA, 80%OCP, 100% DBA
Lifetouch, Inc.

-----Original Message-----
Sent: Wednesday, May 14, 2003 11:22 AM
To: Multiple recipients of list ORACLE-L


I did not get a response to this question of mine. Meanwhile, I did a few tests and pestered Oracle Support to provide a definitive answer. The latter never happened. However, my tests did reveal a few things. Please read on if you are interested.  

First, a standby database does not have to be in mounted state while being backed up by RMAN, contrary to what some notes in Metalink say. The standby could be any state - managed recovery or open read only, meaning it was in INCONSISTENT state. In that state, the restore simply needs more archivedlogs to be conistent, just like a simple RMAN or hot backup, nothing special.  

Second, only the archived logs of standby can be backed up, not the primary. While recovering the primary, you can simply use the archived logs from the standby, without any problems. Some documentation seems to indicate to the contrary.  

In a restore situation you have the following choices.  

  1. If a datafile of primary is to be restored, merely ftp over the datafile from standby, rename it if necesary to the primary's name and recover that datafile.
  2. If the standby datafile is gone, too; restore the RMAN backup of the datafile to the primary and recover it. Remember this backup was taken at the standby.
  3. If archived logs are missing from primary, merely ftp over from the standby or restore directly to primary from backup.
  4. If you primary is intact but the standby is broken, instead of restoring the standby datafile from tape, place the tablespace in hotbackup mode in primary and ftp the file over to the standby and perform a manual recovery. Then place the standby in managed recovery.

I hope this helps.  

Arup Nanda <>  

We run a standby database in managed recovery mode and back the standby using RMAN to save CPU cycles on primary. According to the fine manuals, the RMAN backup should be taken off standby after the managed recovery is canceled. Otherwise the backup is "inconsistent", although no further explanation is given what that means and whether that means an "invalid" backup. We currently cancel the managed recovery on standby and then initiate the RMAN backup. Has anyone done the backups without canceling managed recovery mode? I did a few test recoveries and every time the recovery was successful, but I will feel a lot reassured if I hear someone else has done that.  

Oracle, RMAN Catalog, RMAN version, Solaris 2.8  

Thanks a lot in advance.  

Arup Nanda


Please see the official ORACLE-L FAQ:


Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message to: (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Wed May 14 2003 - 14:57:29 CDT

Original text of this message