From: Ellen K. 

I went to the site.  They do have a solution that allows geographic
separation of up to 500 miles.  HOWEVER, my situation is that I am looking
for an availability and disaster recovery solution for my *SQL SERVER
DATABASES*, so solutions requiring other than Windows operating systems
aren't really solutions.

I think if I can come up with a solution for the BLOB data the log shipping
seems like the way to go.

On Sun, 05 Jun 2005 18:53:02 -0400, Mike '/m'  wrote
in message :

>
>Look into OpenVMS clustering.  The nodes of the cluster can be
>geographically distant.
>
> /m
>
>On Sun, 05 Jun 2005 15:49:45 -0700, Ellen K. 
>wrote:
>
>>Well, after a little more reading, I don't think clustering is going to
>>be my answer.  If I correctly understood what I read, clustering means
>>the clustered machines all use ONE set of data.  So it protects against
>>machine failure and network failure but if the location where the data
>>reside goes down for whatever reason what good are the additional boxes?
>>(Our L.A. location is obviously vulnerable to earthquakes, and not so
>>obviously vulnerable to terrorist attack of several nearby institutions,
>>and TJ, well, it's in Mexico, nuff said.)  I think we want redundancy of
>>the DATA in addition to being protected against machine failure and
>>network failure.
>>
>>Log shipping (similar to replication but specifically designed for when
>>you want a standby server, for example there are stored procedures for
>>making the standby the primary etc) seems more like what I want except
>>that for my recordings database it isn't going to be a solution because
>>BLOB data are actually stored on their own pages, all that's in the BLOB
>>field is the pointer to the location of the data, and the BLOB data per
>>se are not written to the log.   I haven't seen anything about whether
>>BLOB data are propagated if we go back to my original idea of
>>transactional replication, that's my next piece of research.
>>
>>My boss agreed that using replication with the idea of changing the IP
>>number of the Subscriber wouldn't work because they will be on different
>>subnets, but suggested that instead of changing the IP number of the
>>Subscriber, change the *applications* to point to the Subscriber instead
>>of the Publisher.  On further thought it seems to me that since we're
>>going with this Enterprise Service Bus thing we could have something
>>that sends a message with the new location to point to, and/or have the
>>connection string somewhere in the middle tier so we could change it in
>>the event of a disaster, and this would be transparent to the users.
>>
>>Comments?

--- BBBS/NT v4.01 Flag-5