>>1. Is the critical data would be updated in the sites..? Yes... >> 2. If yes , are you expecting the other sites to 'see' this update...? Yes... >> 3. If one site is down, then are you expecting the other sites to share the >> load or you have the closest site in take in all the load...? Yes
but add this requirement as a wrinkle, the sites have to be able to run independently of each other (e.g. a WAN failure) and then resync with each other after a period of time. Finally, this is a bit different than Amazon in that this system has some human safety considerations associated with it. Amazon outage might represent lost sales, outage of this system could represent lost lives. Needless to say, I'm being very careful about the architecture we use. I've implemented replication solutions before as well as stand-by database solutions. But the replication solutions to this point have been very simple and not nearly as complex... so I was hoping for someone to say, we do that and here are the issues we ran into. As for RAC, we will be running RAC at each site, and replicating between the RAC cluster. Sites are way to distant for RAC between them through a SAN or some such thing. RF What does shareplex buy me that Oracle's advanced replication does not? Robert G. Freeman - Oracle8i OCP Oracle DBA Technical Lead CSX Midtier Database Administration The Cigarette Smoking Man: Anyone who can appease a man's conscience can take his freedom away from him. -----Original Message----- Sent: Tuesday, March 26, 2002 12:38 PM To: Multiple recipients of list ORACLE-L Robert, If I understand your requirements correctly, You have multiple sites separated geographically ( 200 Miles perhaps..?? ) and you are looking for a highly available , 'Multimaster' kinda environment. This kind of setup is common in oh-don't-say-the-name-companies i.e. 'dot bombs' and companies with regional offices around the world, with certain variations. I think off the top of the top of head I can say Amazon as an example. To clear some points before jumping to solutions, 1. Is the critical data would be updated in the sites..? 2. If yes , are you expecting the other sites to 'see' this update...? 3. If one site is down, then are you expecting the other sites to share the load or you have the closest site in take in all the load...? Depending upon the answer you have to make a choice. For example, I notice you have been discussing "RAC" as a possible solution. In this case ,since you have multiple sites , which is going to be the Primary..? or are you proposing to use a "RAC" for each site..? Wouldn't a third party assisted solution be more scalable and cost effective..? Like EMC or HP's XP storage solution has some kinda 'track' or 'Block' replicating mechanism between the storage, which is extendable in term of geographical location...? Or if you are looking to share the load like in question 3 above, then wouldn't it be easy to Get a 'replicating' software to help replicate the data in real time or near real time...? Example , like said before quest software's shareplex. This can give you master-master replication capabilities. Just my 2 cents. Cheers, RS --- "Freeman, Robert " <[EMAIL PROTECTED]> wrote: > Log application services can run in foreground or > background now, but I > don't think the > database can be open read-only at the same time > while doing managed > recovery, even in > 9i..... > __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards® http://movies.yahoo.com/ -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Sakthi , Raj INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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.com -- Author: Freeman, Robert INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
