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

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tanel Poder
  INET: [EMAIL PROTECTED]

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: [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).