RE: RMAN Backup of Standby Database In Managed Recovery Mode

List - Just wanted to report that off-list Arup straightened me out about why backing up the standby is a great idea and does not introduce any gaps in your recovery capability. He also reported that he has indeed tested recovery.

   Thanks Arup and if I get pushed toward standby databases, I'll know who to go to.
Dennis Williams
DBA, 80%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Thursday, May 15, 2003 6:24 PM
To: 'ORACLE-L_at_fatcity.com'

Arup - Thanks for clarifying that. Just the thought of "we can't tax the production server with backups, so we'll backup the standby instead" gives me the willies. But you know your environment. Regardless of the answer you get from the manuals on this issue, I would test it. Verify whether you can recover from the backup.

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

-----Original Message-----
Sent: Thursday, May 15, 2003 11:32 AM
To: Multiple recipients of list ORACLE-L

Dennis,

Absolutely not! Standby databases are not for throw-away. Since they run on a different server, they RMAN backups from that server will reduce the load on the primary server significantly. Also if your tape backup software (Tivoli in my case) uses compression, precious CPU cycles are saved from the primary. So, it's an important part of your overall infrastructure strategy and thus backups from standbny are necessary, not just desirable. Of course, if your standby amounts to, say, 10% of your primary, it may be difficult to run RMAN and tape compression over there.

The issue was not how to take backups from standby database, but rather the confusion created by Notes and Manuals stating that "standby should NOT be in managed recovery mode while being backed up". This means for the duration of the backup, which in our case takes 6 hours (2.3 TB, OLTP, 1000 concurrent sessions), the standby is out of sync with the primary. My question was wheether we could backup WHILE in managed recovery mode. And, fortunately, the answer is yes.

I have been doing standby databases for years, but the backups were always from the primary, so this issue never really arose. At this customer, the size of the database, time of backup and insfrastructure prompted me to rethink that approach.

HTH. Arup

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Wednesday, May 14, 2003 3:57 PM

> 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.
> dwilliams_at_lifetouch.com
>
> -----Original Message-----
> Sent: Wednesday, May 14, 2003 11:22 AM
> To: Multiple recipients of list ORACLE-L
>
>
> List,
>
> 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
> www.proligence.com <http://www.proligence.com>
>
> ----- Original Message -----
> To: ORACLE-L_at_fatcity.com <mailto:ORACLE-L_at_fatcity.com>
> Sent: Thursday, May 08, 2003 11:15 PM
>
> 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 8.1.7.4, RMAN Catalog 8.1.7.4, RMAN version 8.1.7.4, Solaris 2.8
>
> Thanks a lot in advance.
>
> Arup Nanda
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: DENNIS WILLIAMS
> INET: DWILLIAMS_at_LIFETOUCH.COM
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (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).
>
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Arup Nanda
  INET: orarup_at_hotmail.com

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DENNIS WILLIAMS
  INET: DWILLIAMS_at_LIFETOUCH.COM

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (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).