It is our own application.  That's an interesting approach, thanks!

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

Reply via email to