'Down time', ah. Switching to another machine is not that easy a decision to take. Remember that when you switch from the main machine to its spare, you also jump from an architecture in which you have two machines in synch (more or less), to a single-machine architecture. This is often overlooked, returning to business-as-usual (i.e. resynching two machines) is rarely a piece of cake. In other words, switching to the backup machine is rarely a decision you take lightly. What will happen in practice? Bang, the main server crashes. What will you do? First try to reboot it, it's obviously the simplest solution. Doesn't want to? Try to get hold of a manager, discuss, etc. In the best of case, I doubt that the switch will occur before a quarter of an hour at best (I have the experience of this type of situation on trading floors, where a lot of money is at stake, it was always at least 45mn before users were able to resume business). The possible down time of the standby database is totally negligible compared to all this. I agree with Jared, standby is BY FAR the best solution for this. Put in balance the trouble vs the risks.
Peter Barnett wrote: > > Howdy, > > Once the consultants understood their requirements, > they did not want the possible down time of a standby > database. We actually have a really slick Veritas > fail over solution installed but it only works on > Solaris and the servers on this project are AIX. > Bummer... > > Pete > > --- [EMAIL PROTECTED] wrote: > > Pete, > > > > Have you considered using a standby database? > > > > More suitable for failover than Advanced > > Replication, and > > much easier to implement and maintain. > > > > Jared > > > > > > > > > > > > > > Peter Barnett <[EMAIL PROTECTED]> > > Sent by: [EMAIL PROTECTED] > > 02/14/02 03:03 PM > > Please respond to ORACLE-L > > > > > > To: Multiple recipients of list ORACLE-L > > <[EMAIL PROTECTED]> > > cc: > > Subject: Oracle Advanced Replication > > > > > > We are looking at Advanced Replication as a fail > > over > > option for a web site. Straight forward > > installation, > > both boxes on the same subnet on their own dmz. The > > servers will be located on the same rack in the > > computer room. Very few tables storing data from an > > application that is tracking click through data. > > > > Does anyone see any flaws with the basic plan? Any > > hidden 'features' that we may run into? > > > > Thanks > > -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Stephane Faroult INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
