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@backup
instead of scott/tiger@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: [EMAIL PROTECTED]
>
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Stephane Faroult
  INET: [EMAIL PROTECTED]

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: [EMAIL PROTECTED] (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).

Reply via email to