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).
Received on Fri May 16 2003 - 12:53:03 CDT
