From treegarden@yahoo.com Thu, 10 Jul 2003 11:15:55 -0700 From: Paul Baumgartel Date: Thu, 10 Jul 2003 11:15:55 -0700 Subject: Re: High availability and upgrades Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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).