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).
