Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: asking your opinion

RE: asking your opinion

From: Stephen Lee <Stephen.Lee_at_DTAG.Com>
Date: Tue, 17 Jun 2003 09:42:30 -0700
Message-ID: <>

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:
Author: Stephen Lee

Fat City Network Services    -- 858-538-5051
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).
Received on Tue Jun 17 2003 - 11:42:30 CDT

Original text of this message