| 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: High availability and upgrades
Ugh - this is a tricky idea for a couple of reasons. What happens when one database goes down? When its brought back up its no longer in sync with the original, and has to be brought up to speed somehow (I see that you mention that, but that in and of itself is a project). Besides that, what if an application node can't talk to one of the database servers, either because the node is down or network problems are preventing proper communications. Either:
In the case of 1), not only have you not given yourself high availability, you've actually reduced the MTBF for your system, since you'll go down twice and often. In the second case, you've got data consistency problems - log mining is fine and dandy, but how do you deal with a situation where a database is intermittently available?
What about a storage-level solution? Either at the software (i.e. Veritas) or hardware (i.e. your big honkin' storage array) level, have a "third mirror" of your data. Configure your two servers in a cluster, then when you want to do separate testing, split off the mirror, detach the idle node from the cluster, run your tests against the third mirror, and then resync/rejoin the nodes. Basically every reasonable hardware vendor and every storage software vendor supports some notion of r/w point-in-time copies that are designed for just this purpose.
Thanks,
Matt
-- Matthew Zito GridApp Systems Email: mzito_at_gridapp.com Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.comReceived on Thu Jul 10 2003 - 16:39:25 CDT
> -----Original Message-----
> From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] On
> Behalf Of Tanel Poder
> Sent: Thursday, July 10, 2003 3:59 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: High availability and upgrades
>
>
> Hi!
>
> I wouldn't call it replication, because data is not
> replicated from one database to other. The DML feed always
> goes from app servers to all active databases. One database
> doesn't even have to know about existence of other one during
> normal operations, it's done on app server (client) level.
>
> Since all databases are always in sync, there is no need for
> complicated conflict resolution or similar mechanisms. But
> this concept definitely has it's gotchas, like every system out there.
>
> Tanel.
>
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Thursday, July 10, 2003 10:09 PM
>
>
> > are you suggesting that they basically write their own home-grown
> > version of replication?
> >
> > If so, I believe Peter Robson has already done this in his shop and
> > may be able to share the code, or at least give a list of "gotchas".
> >
> > seems a bit excessive and prone to error and failure to me.
> >
> >
> > --- Tanel Poder <tanel.poder.003_at_mail.ee> wrote:
> > > Hi!
> > >
> > > Is this your own-written app?
> > >
> > > If you want performance, control and no-data-loss reliability:
> > >
> > > 1) Have 2 completely independent databases
> > > 2) Have your application servers multiplex
> > > all DML requests to both database servers
> > >
> > > That means, if your client inserts something,
> > > then app layer does one insert on first DB
> > > and the same insert in second DB too.
> > >
> > > It can be more efficient than standby
> > > database in maximum protection mode,
> > > because DMLs are sent to databases
> > > parallelly, not through primary to standby.
> > >
> > > Depending on application you could commit
> > > done either when both servers acnowledge
> > > commit, or when only one acknowledges it.
> > > In that case you could check whether second
> > > instance managed to commit when next request
> > > is sent to it. That could give some
> > > performance practically without losing any
> > > reliability features.
> > >
> > > Also, since you now have two identical
> > > databases, you can make your app servers
> > > load balance the selects.
> > >
> > > 3) Before you shut down one database for
> > > maintenance, you first configure your
> > > app servers to use only one database
> > > AND set change logging on on active DB.
> > > There are several ways for change logging,
> > > starting from customer triggers ending
> > > with logminer.
> > >
> > > 4) When you bring second db up again you
> > > first synchronize all changes manually,
> > > several times if needed, and when the
> > > log of changes is sufficiently low you
> > > just halt both app servers for very short
> > > time, do the final synchronization and
> > > activate both databases again.
> > >
> > > If you upgrade your application, will you change the
> schema as well?
> > > Then you must move from physical to logical level, where you have
> > > some kind of mapping, which columns of old tables match
> columns in
> > > new tables.
> > >
> > > That way you have two separate fully functional
> databases, no Stanby
> > > or RAC restrictions or additional licence costs etc. If
> you have a
> > > packaged 3rd party app, then my post is quite useless,
> but the idea
> > > should be ok.
> > >
> > > Tanel.
> > >
> > >
> > > ----- Original Message -----
> > > To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> > > Sent: Thursday, July 10, 2003 8:59 PM
> > >
> > >
> > > > We're considering high availability options. One of our
> > > requirements
> > > > is to be able to take one database offline (i.e., direct all
> > > > application connections to a second database server), perform
> > > database
> > > > and application upgrades, and perform a few hours'
> worth of tests
> > > > before bringing it back online. We would then take the second
> > > database
> > > > offline and repeat the procedure.
> > > >
> > > > We've tried Data Guard logical standby but it's
> incompatible with
> > > Label
> > > > Security (which we plan to run), presents performance problems,
> > > > and
> > > has
> > > > a number of bugs. We'd like to use the secondary database for
> > > > reporting as well, so a physical standby isn't practical.
> > > >
> > > > RAC doesn't give us a second database copy.
> > > >
> > > > Multimaster replication requires that changes to replicated
> > > > objects
> > > be
> > > > made via DBMS_REPCAT.ALTER_MASTER_OBJECT, which propagates the
> > > changes
> > > > to all masters at once.
> > > >
> > > > We haven't tested Streams yet.
> > > >
> > > > I'd be interested in hearing of any experiences from those who
> > > > have
> > > the
> > > > same or similar requirements.
> > > >
> > > > Paul Baumgartel
> > > >
> > > >
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
> > > > --
> > > > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > > > --
> > > > Author: Paul Baumgartel
> > > > INET: treegarden_at_yahoo.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).
> > > >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Rachel Carmichael
> > INET: wisernet100_at_yahoo.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: Tanel Poder
> INET: tanel.poder.003_at_mail.ee
>
> 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: Matthew Zito INET: mzito_at_gridapp.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).
 |
 |