Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

Re: asking your opinion

From: Joan Hsieh <joan.hsieh_at_tufts.edu>
Date: Tue, 17 Jun 2003 11:18:52 -0700
Message-ID: <F001.005B3275.20030617102942@fatcity.com>


This application will need to tie into Sun one portal, the key items are web central to provide unit to create content, change pages..etc undergrades site for class registration, staff pages do other stuff.

Joan

Stephen Lee wrote:
>
> 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).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Joan Hsieh
  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).
Received on Tue Jun 17 2003 - 13:18:52 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US