| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Common Oracle RDBMS Misconceptions - standby db?
Stephane,
Um, how about because hardware maintenance is needed on the primary server? I know I would much rather gracefully schedule a fallover and fallback to do something like that, given the luxury of actually being able to close the database for the few minutes it takes to complete the switch.
In the case of a crash, of course all bets are off -- you can't really DO a graceful switchover (well,remote mirroring the online logs maybe)
But we all always forget that there are on occasion SCHEDULED downtimes to build procedures for
Rachel
>From: Stephane Faroult <sfaroult_at_oriole.com>
>Reply-To: ORACLE-L_at_fatcity.com
>To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
>Subject: Re: Common Oracle RDBMS Misconceptions - standby db?
>Date: Tue, 26 Jun 2001 16:27:34 -0800
>
>But in practice, why would you switch to the standby database, unless
>the primary database is crashed or worse? You know how it is in a
>production environment, the database crashes. Even if failover is easy,
>you always have to instruct users to connect as scott/tiger_at_backup
>instead of scott/tiger_at_prod - or perhaps modify the tnsnames.ora to make
>it transparent, or perhaps play with IP addresses which may mean trouble
>for a while with in-memory routing tables etc. My point is that, even if
>the switch can be quasi-immediate, it is not so easy, so people will
>naturally try to make the main machine work first, there will be some
>delay assessing the damage, waiting until 2am to ring the VP in his bed
>to get the authorization to switch, etc. In real life, half-an-hour or
>an hour is easily passed before everybody is back at work on the backup
>machine, busy trying to catch up on the wasted time. Do not forget that
>since the transmission of redo logs is asynchronous (I have heard about
>improvements with 9i) some transactions - committed ones - will have
>been lost, so users will have to check and probably reenter the missing
>transactions. At this point the main machine will probably be totally
>out of order. Wait another 2 or 4 hours to have somebody to come if it's
>a hardware problem, I guess that when everything is over everybody will
>be on their knees and the last thing they will have in mind is make the
>old primary database the new standby - assuming of course that all files
>are intact. And even if the ex-standby machine is possibly less
>powerful, everybody will probably wait until a quieter time, say the
>W/E, to switch back to the initial configuration. At which time, in all
>likelihood, a full database copy will have become necessary; I think
>that the simple fact of having reentered a couple of transactions not
>transmitted yet to the standby database would require it. Do I err ?
>
>--
>Regards,
>
>Stephane Faroult
>Oriole Corporation
>Voice: +44 (0) 7050-696-269
>Fax: +44 (0) 7050-696-449
>Performance Tools & Free Scripts
>--------------------------------------------------------------
>http://www.oriole.com, designed by Oracle DBAs for Oracle DBAs
>--------------------------------------------------------------
>
>Jeremiah Wilton wrote:
> >
> > With graceful standby failover (I demo'd it last year at OOW), you can
>switch
> > back and forth, back and forth as many times as you want without
>recopying any
> > database.
> >
> > Basically, when you fail over to a standby, you shut down the primary,
>apply all
> > the archived redologs to the standby, then copy all the online logs and
>the
> > controlfile from the primary to the standby. People who use incremental
> > checkpoints (DB_BLOCK_MAX_DIRTY_TARGET) must do a 'create controlfile
>reuse
> > database <blah> noresetlogs' at this point. Other people don't have to.
> >
> > Finally, you "recover database" to get the last one or two online logs
>and open
> > the standby "noresetogs." The standby just picks up the chain of SCNs
>where the
> > primary left off.
> >
> > The old primary can be immediately pressed into service as a standby.
>Just
> > generate a standby controlfile on the new primary, copy it into place on
>the old
> > primary and start it up as a standby database.
> >
> > You can go back and forth in this way as many times as you want, and one
>just
> > picks up the chain of SCNs where the last one left off. You never get a
> > divergence of changes.
> >
> > I have talked to people who found this out, and looked like they were
>going to
> > cry, thinking of the countless hours they had spent after every standby
> > failover, recopying to the standby to get it rollong forward again.
> >
> > In 9i, they have an "automated" graceful failover mechanism for standby
> > database. I haven't taken a look at it yet. Probably it is a massive
> > java-based GUI that instantly consumes 512Mb or RAM.
> >
> > --
> > Jeremiah Wilton
> > http://www.speakeasy.net/~jwilton
> >
> > On Tue, 26 Jun 2001, Koivu, Lisa wrote:
> >
> > > OK. I admit my knowledge on standby is minimal, having only read up
>on it,
> > > fiddled with it and used the idea sparingly for migrations.
> > >
> > > However, Jeremiah, I'm very curious. You state that 'Must
>reinstantiate
> > > standby after failover by recopying' is a misconception. Yes, like
>many of
> > > the things you state below, the documentation does say that - once you
>open
> > > a standby db in r/w mode, it is no longer a valid standby after
>switching
> > > back to the primary.
> > >
> > > Can someone shed some light on why this is not true? It seemed to
>make
> > > complete sense to me. I can see how opening a database read only will
>work
> > > and not invalidate the standby, but r/w?
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Jeremiah Wilton
> > INET: jwilton_at_speakeasy.net
> >
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>--
>Author: Stephane Faroult
> INET: sfaroult_at_oriole.com
>
>Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
>San Diego, California -- Public Internet access / Mailing Lists
>--------------------------------------------------------------------
>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.com -- Author: Rachel Carmichael INET: carmichr_at_hotmail.com Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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 Tue Jun 26 2001 - 19:42:46 CDT
 |
 |