Oracle-L: RE: RMAN Backup of Standby Database In Managed Recovery Mode

From: Pete Sharman <peter.sharman_at_oracle.com>
Date: Fri, 16 May 2003 13:36:49 -0800
Message-ID: <F001.0059B823.20030516133649@fatcity.com>

Tell them and you die! :)

Pete
"Controlling developers is like herding cats." Kevin Loney, Oracle DBA Handbook
"Oh no, it's not. It's much harder than that!" Bruce Pihlamae, long-term Oracle DBA

-----Original Message-----
- IL
Sent: Friday, May 16, 2003 2:07 PM
To: Multiple recipients of list ORACLE-L

A most excellent point, and great new feature in 9i. Just wait until you see what's coming folks!!

-----Original Message-----
To: Multiple recipients of list ORACLE-L Sent: 5/16/2003 12:53 PM

Hopefully the FORCE LOGGING capabilities of 9i were considered in that discussion. It's a wonderful thing -- DBAs get reliable and complete standby propagation and developers/end-users get to think that they are optimizing performance using NOLOGGING... :-)

It isn't everyday that you can make everyone happy!

on 5/16/03 9:21 AM, DENNIS WILLIAMS at DWILLIAMS_at_LIFETOUCH.COM wrote:

> 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: Tim Gorman
  INET: tim_at_sagelogix.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: Freeman Robert - IL
  INET: FREEMANR_at_tusc.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: Pete Sharman
  INET: peter.sharman_at_oracle.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).

Received on Fri May 16 2003 - 16:36:49 CDT