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

Reply via email to