SAN Replication for DR site

Does anyone use SAN Asynch Replication for Disaster Recovery to a secondary
site ? If so, are there any issues with it at the production site i.e. the
source when you set it up,etc. ?
Also when you break the link to test the DR i.e. bring the secondary site
databases online, do you have to push all the blocks again from the primary
to resynch it once your DR test is complete ?
Are there any performance issues at the source when you set it up ? I do not
wish to take any downtime at the source to configure this. Do we need to
quiesce ?
Hi
"Hassan" wrote:

> Does anyone use SAN Asynch Replication for Disaster Recovery to a secondary
> site ? If so, are there any issues with it at the production site i.e. the
> source when you set it up,etc. ?
> Also when you break the link to test the DR i.e. bring the secondary site
> databases online, do you have to push all the blocks again from the primary
> to resynch it once your DR test is complete ?
> Are there any performance issues at the source when you set it up ? I do not
> wish to take any downtime at the source to configure this. Do we need to
> quiesce ?
You should be talking to your SAN vendor about this.
John
|||Agreed John..
The only reason I am asking the group here is that I am hoping I may get a
response from some customers using it in production mode today.
The vendors would love to market their product and give you all the pros,
but I want to see how it actually fares out once deployed compared to
theory,etc. I hope you understand.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:6C8799D9-451C-4FD7-87B8-940DEF42D1D8@.microsoft.com...
> Hi
> "Hassan" wrote:
>
> You should be talking to your SAN vendor about this.
> John
|||Hi Hassan
It sounds like you need to get past the sales guy!! What is their reply?
You may want to mention this is a HDS SAN?
John
"Hassan" wrote:

> Agreed John..
> The only reason I am asking the group here is that I am hoping I may get a
> response from some customers using it in production mode today.
> The vendors would love to market their product and give you all the pros,
> but I want to see how it actually fares out once deployed compared to
> theory,etc. I hope you understand.
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:6C8799D9-451C-4FD7-87B8-940DEF42D1D8@.microsoft.com...
>
>
|||Well their reply is everything works and yes for now it is HDS SAN.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:0CC3BE37-573C-4F70-8DFA-7F86F75775E1@.microsoft.com...[vbcol=seagreen]
> Hi Hassan
> It sounds like you need to get past the sales guy!! What is their reply?
> You may want to mention this is a HDS SAN?
> John
>
> "Hassan" wrote:
|||Hi Hassan
Can they not provide you with documentation on how best to set up SQL Server
on their system?
"Hassan" wrote:

> Well their reply is everything works and yes for now it is HDS SAN.
>
John
|||On Apr 8, 1:19 am, "Hassan" <has...@.hotmail.com> wrote:
> Well their reply is everything works and yes for now it is HDS SAN.
> "John Bell" <jbellnewspo...@.hotmail.com> wrote in message
> news:0CC3BE37-573C-4F70-8DFA-7F86F75775E1@.microsoft.com...
>
>
>
>
>
>
>
>
>
> - Show quoted text -
I'm also curious to know if after unlocking the target to mount the
databases if they are able to complete their testing, lock the target
and then continue mirroring without doing a complete resync of the
data while also not impacting production. The way that SteelEye Data
Replication, a host based replication product, would handle this is to
simply discard the changes that occured on the secondary target while
it was unlocked so that after testing, only the writes that occured on
the primary would have to be sent to the secondary.
David A. Bermingham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com
|||Hi

> I'm also curious to know if after unlocking the target to mount the
> databases if they are able to complete their testing, lock the target
> and then continue mirroring without doing a complete resync of the
> data while also not impacting production. The way that SteelEye Data
> Replication, a host based replication product, would handle this is to
> simply discard the changes that occured on the secondary target while
> it was unlocked so that after testing, only the writes that occured on
> the primary would have to be sent to the secondary.
> David A. Bermingham, MCSE, MCSA:Messaging
> Director of Product Management
> www.steeleye.com
>
I would not expect SAN replication to discard changes on the secondary when
it was acting as the primary! This would effectively remove most of the
benefits of having such a high cost solution. I would also expect failover to
a DR to be similar to failover in a cluster, but with the potential that
additional uncompleted transaction that have not be replicated between the
SANs to be rolled back.
John
John
|||On Apr 13, 3:18 am, John Bell <JohnB...@.discussions.microsoft.com>
wrote:
> Hi
>
> I would not expect SAN replication to discard changes on the secondary when
> it was acting as the primary! This would effectively remove most of the
> benefits of having such a high cost solution. I would also expect failover to
> a DR to be similar to failover in a cluster, but with the potential that
> additional uncompleted transaction that have not be replicated between the
> SANs to be rolled back.
> John
> John
You misunderstood what I was saying. The secondary can be unlocked
and the data validated without ever actually making it the primary.
Meanwhile the primary server continues to accept writes and track the
changes to the blocks via a bitmap file. Once you locked up the
secondary and continued the mirror, only the blocks that changed on
the primary server would be sent to the secondary. While working on
the secondary in this "unlocked" state, you are able to have full read
write access to the volume for data inspection, including mounting a
database, etc. You need to be aware that any changes you make on the
secondary will be discarded once you lock the volume back up.
If you want to make the secondary the primary, that is an entirely
different story. In that case, you would reverse the mirror so that
any changes made on the secondary are automatically replicated back to
the original primary.
The original question was how to test the DR site without doing a
complete resync. With SteelEye Data Replication, you have two
options. You can simply pause the mirror, unlock the drive, mount the
databases, validate the data, lock the drive (discarding changes) and
continue the mirror from the primary without impacting production.
This is a simple way of testing DR without actually bringing DR into
service.
The second way is to actually bring the secondary volume into service
as the primary and have all the changes mirrored back to the original
primary. The second option has more impact on production because
production is actually shifted to the DR site during the test. This
option is good to run for a complet DR test, but obviously the impact
is much greater to production. If a simple data validation test needs
to be run, option 1 is the much better choice.
Either way, I was curious to know how storage based replication
handles these situations. Do they have similar options to allow
testing without doing comlete resyncs and without impacting production?