Tanel,
points 1 & 2 .... isn't it like using data guard ??
Raj
Rajendra dot Jamadagni at nospamespn dot com
All Views expressed in this email are strictly personal.
QOTD: Any clod can have facts, having an opinion is an art !
-----Original Message-----
From: Paul Baumgartel [mailto:[EMAIL PROTECTED]]
Sent: Thursday, July 10, 2003 3:10 PM
To: Multiple recipients of list ORACLE-L
Subject: Re: High availability and upgrades
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).
*********************************************************************This e-mail
message is confidential, intended only for the named recipient(s) above and may
contain information that is privileged, attorney work product or exempt from
disclosure under applicable law. If you have received this message in error, or are
not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000
and delete this e-mail message from your computer, Thank
you.*********************************************************************1
Received on Thu Jul 10 2003 - 13:56:06 CDT
