Re: Availability during software/hardware upgrade.

I keep forgetting that what's listed as a 9i New Features sometimes actually got rolled out in an earlier release!! You're quite right: 8.1.7 got treated as a 'pre-9i' release as far as Data Guard was concerned, and DG made it into that release... thanks for the reminder.

For the rest: I'll take your word. I think the real message as far as minor patch differences with DG is concerned is: test, test, test.... in your specific environment.

Cheers as ever,
HJR "Sean McKeown" <smckeown_at_adephia.net> wrote in message news:3DBDFAE4.F848A7A4_at_adephia.net...
> Hi Howard-
>
> Just wanted to add a few minor clarifications. Dataguard 3.0.2 for
> Oracle 8i fully supports "switchover" - i.e. graceful switching back and
> forth between primary and standby without ever needing to rebuild the
> standby. This has been available for 8i for some time now. For more
> information please see:
>
> http://otn.oracle.com/docs/deploy/availability/pdf/A95293_01.pdf
>
> ... particularly the section on p. 3-34.
>
> Also, in most cases minor patch differences between the two hosts are
> acceptable. The main concern is the same OS version and release. So
> using Dataguard to apply a patch to the standby and then "roll onto" it
> via graceful switchover is possible and not necessarily unsupported,
> though your mileage may vary.
>
> As far as I know, Transparent Application Failover works just fine with
> a standby environment (i.e. you don't necessarily need RAC for TAF - you
> can have the "failover" TAF connection point to a standby database),
> though I have no direct experience with this.
>
> Finally, as far as cost and complexity go, Dataguard certainly does add
> to the overall operational cost and upkeep. But for what it provides,
> the price is quite reasonable IMHO when compared with 3rd party remote
> disk mirroring solutions, and Dataguard definitely simplifies the care
> and feeding.
>
> Regards,
> Sean M
>
>
> "Howard J. Rogers" wrote:
> >
> > Another flurry of useful replies, I see!
> >
> > Yes, what you ask for is possible, provided you have version 9i, and
> > provided you implement something called Data Guard (ie, Standby Database
on
> > steroids).
> >
> > You have a requirement to switchover to Database 2, and then back again
to
> > Database 1: that's not possible with any version of Standby Database
before
> > 9i. You *could* "failover" to Database 2 in previous versions, but that
> > caused Database 2 to receive a resetlogs, meaning it was in a new
> > incarnation compared to Database 1, and meaning that you couldn't
failover
> > back to Database 1, until Database 1 had been completely blown away,
> > re-cloned from Database 2, and the standby re-initialised.
> >
> > Havng said that, any and all versions of Standby, including Data Guard,
> > require both Databases to be running on the same operating system, so
it's
> > not possible to use this mechanism to do a rolling upgrade from, say,
> > Windows to Unix. And the doco. states that each O/S must be at the same
> > patch release, so point upgrades of the same O/S are theoretically not
> > possible either.
> >
> > The costs of Data Guard are considerable. Not only must you be running
the
> > Enterprise Edition, but to satisfy your requirement to lose no records,
> > you'll have to be running in one of the three higher modes of protection
> > which make LGWR do the transmission of redo from one Database to the
other.
> > And that has significant performance implications (nothing that some
> > expensive kit won't fix!!).
> >
> > Another idea would be to use RAC (Real Application Clusters). You could
> > have a two node RAC, take one of the nodes offline to patch it/upgrade
> > it/whatever, and then bring it back into the cluster. Do the same on the
> > other node, and you achieve truly non-zero downtime for the cluster as a
> > whole. Again, however, you can't cluster a Windows box with a Unix one,
so
> > O/S changes are out of the question. Point release upgrades of the same
 O/S
> > shouldn't necessarily be a problem, however.
> >
> > Also, I note you require no 'broken' transactions. Data Guard requires
that
> > you ask your users to get off the database nicely, so in theory you
> > shouldn't break anything there. But RAC cannot failover DML (it can
> > transparently failover selects, but not inserts, updates or deletes). So
> > anyone connected to a RAC node that you cause to leave the cluster would
> > lose any DML they were in the middle of.
> >
> > Anyway: that's two things for you to investigate: Data Guard and RAC.
Both
> > require the Enterprise Edition; both are expensive; both require good
> > hardware; both are quite tricky maintenance prospects for the DBA.
> >
> > HTH
> > Regards
> > HJR
> >
> > "Andre Sluiter" <A.Sluiter_at_gesloten.nl> wrote in message
> > news:3db50850.3320984_at_news.nl.uu.net...
> > > Is it possible to change over from
> > > hardware, OS version, Oracle version
> > > without going off line ?
> > >
> > > I am thinking in the line of two (or more)
> > > servers where server 1 is online, server 2 gets
> > > upgraded, then a switch over from 1 to 2
> > > server 1 get's upgraded and then a change back
> > > to server 1.
> > >
> > > The switchover should be done without dataloss
> > > or broken transactions.
> > >
> > > Is this possible ?
> > > What is required for this ?
> > > (If you can put a price on this please do,
> > > or point me to a website or more info, thanks).
> > >
> > > Just checking if we should be looking into this.
> > > (I have always claimed that if feasable this is
> > > going to be to expensive for us, but have no
> > > solid arguments).
> > >
> > >
> > > Andre Sluiter
Received on Tue Oct 29 2002 - 01:45:16 CST