Re: asking your opinion

Thanks Robert, Malden and stephen. I am just wondering does master replication is an option too? As I mentioned earlier, the application is sun one portal, content based.

Joan

Freeman Robert - IL wrote:
>
> See comments below....
>
> RF
>
> Robert G. Freeman
> Consultant - TUSC
> www.tusc.com
>
> One browser to rule them all, one browser to find them,
> One browser to bring them all and into the darkness bind them
> In the land of Redmond where the shadows lie.
>
> -----Original Message-----
> To: Multiple recipients of list ORACLE-L
> Sent: 6/16/2003 11:14 PM
>
> >> 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?
>
> You are asking the question without yet really providing the requirements.
>
> The standby database (logical or physical) is there to meet disaster
> recovery requirements, *NOT* HA requirements. It's need is defined by your
> SLA's with regards to how much down time can I have, do I need a remote
> site, do I need to be able to revert to a previous image of my database,
> etc...etc... For some environments, offsite backups are perfectly
> satisfactory in this regard, at other sites, you have a hot offsite
> location, where you run dataguard (standby). So, you need to define your
> needs before you ask the question.
>
> Specifically regarding logical standby databases, they are a great idea but
> in my mind they are still new enough (and I've seen a bugs enough) that I
> don't trust them yet for mission critical application failover. I might
> consent to using one in combination with at least one physical standby if
> needs and resources allowed. Still, for right now, if my requirements
> dictated a standby database, I'd go physical.
>
> RAC, OTOH, is there to meet HA requirements, not DR requirements (unless you
> can configure a long distance RAC cluster which I have yet to see work
> really well yet). RAC is an added cost option to Oracle, with it's own set
> of headaches that may or may not be worth your time and money. Again, it
> depends on your needs, budget and SLA's. If you need four 9's uptime, then
> RAC may well be the way to go. If you have a rather stable system, and your
> users can stand an outage, then perhaps you do not need RAC. Again, you must
> define the requirements first, then look for the solutions.
>
> >> 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?
> My personal rule about this is that if a given application is going to
> largely share data with another existing application, and there are no good
> reasons to separate them into their own databases (for example wildly
> different SLA's with regards to HA or DR), then I will simply use the same
> database. This avoids problems with disparate data issues (and saves a bit
> of memory and CPU).
>
> However if the application is self-contained, or if it uses data feeds from
> several systems (which is much more frequent in my experience) then it goes
> into it's own database and we have to decide how we are going to feed it
> data.
>
> HTH!!!
>
> Robert
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Freeman Robert - IL
> 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).