If this is to be a web server kind of application then another possibility to consider: Transparent Application Failover (TAF)
I think this works well with web applications where the data in the database(s) isn't constantly changing at a high rate. You have two or more independent databases that you keep in sync with replication. If one becomes unavailable, sqlnet will send the app to the other database. This is handled entirely by sqlnet and requires no specific coding in the application. One handy thing about this setup is that if one of the departments turns out to be a real database pig and needs to be put on its own machine(s), you can setup the database(s), make a change to the tnsnames.ora that the app is using, and it will magically start using the new database(s) without ever taking down the app. If you need to do some maintenance on one box, then you just shut it down, and the app will go to other. If you have multiple web servers hitting the databases, you can get some sort of load balancing by fiddling with the tnsnames.ora on each of the web servers; for example, web server #1 hits database #1 and fails over to database #2, and web server #2 is just the opposite. The disadvantages of TAF (that I can think of at the moment) are: The syntax for the network files for TAF is a little obscure and touchy. If you fail over -- usually because you want to do some maintenance on one of the database servers -- then you might have to do some restart this and restart that to get the web servers pointed back to the database they are "supposed" to be using. But often, this can be done without taking down the web front ends And a comment about this whole "It can never go down" philosophy. The Unix stuff from Sun and IBM is actually very reliable. If your storage is fault tolerant (i.e. 0+1 ... or ... RAID5 Oh YESSSSSS!), and as long as you don't do something inherently unreliable such as putting critical stuff on NFS mounts, these systems should stay up for a long time. Most of the time your outages will be caused by human error or network outages (caused by human error -- Those damned humans!). > -----Original Message----- > > Hi Dear listers, > > I'd like to ask your opinion about our possible new project. > overview; install fatwire for the whole community for web > application. no > single point of failure, sun servers, oracle. > We have more than 10 divisions currently( different > department, like arts, > dental, enginerring..etc), but we want the flexibility to add > more "unit" as > the environment changes and grows. > Question 1: database option; what is the pros and cons about > physical standby > database, logical staandby or RAC? I think the answer should > be RAC, right? > question 2: Among the questions is whether this is a series > of databases for > each unit or a central database that is shared by all? > > I am new to this area, I would appreciate any input informantion. > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Stephen Lee 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).
