I think there is a limit with RAC of 90KM, from the Oracle side (I need to check on this but this number sticks out in my head). So, a wide area SAN architecture with RAC would not work for us because we are looking at sites well over 90KM apart. The other problem is that if we loose the wide area network connectivity, (or the SAN) we still need the region to be able to run independent of that WAN. So, we apparently have a requirement for redundant servers and disks. We will be running RAC on the servers at the remote sites, and have considered running a SAN and having them physically located at two different locations. I also thought about using something like a network appliance which I understand has been recently certified by Oracle but I've not heard anything positive about this option yet, and have had some negative experiences with NA here.
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: Monday, March 25, 2002 3:14 PM To: Multiple recipients of list ORACLE-L Robert, I think it is possible to use "RAC" where the corporate data is located on a SAN accessible to all and each region has their own storage that they have "RAC'd" with the rest of the organization. If one region dies each region continues to function. If the corporate office dies each region continues to function. It sounds complicated and requires fast inter-connectivity between each region and the SAN. Sound reasonable? ROR mª¿ªm >>> [EMAIL PROTECTED] 03/25/02 02:38PM >>> Robert, Given what you've said it would appear that your only choice is going to be symetric/advanced replication, multi-master. The conflict resolution rules may be a bear to set up with 5 sites though. Using a standby db would not be very effective since data updates are dependent on the archive log switch points and that does not address the different sites if your reason for failure is a network related one. Snapshots won't work either since they are read only. Dick Goulet ____________________Reply Separator____________________ Author: "Freeman; Robert " <[EMAIL PROTECTED]> Date: 3/25/2002 9:48 AM Pretty stringent. They want as little latency as possible. Changes at a master should be available to all sites ASAP. Now, they could all go to one central site, and thats ok as long as our networking is healthy, but if it goes down, there is a requirement that they be able to work independently (there are 4-5 sites) and then all changes need to be synchronized. Data loss is secondary to availability however. These requirements smack of trouble to me. Robert G. Freeman - Oracle8i OCP Oracle DBA Technical Lead CSX Midtier Database Administration -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Ron Rogers 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).