Replication as backup

Hello All

We intend to replicate a database in order to have it as a near immediate
standby in case of the failure of the main server.

Is this the best solution for disaster recovery?

We are currently testing our replication plan. When we set up the
subscriber, a snapshot of the publisher is created and this takes hours. Is
there a better way?

My understanding is that a RAID array would help in the case of the failure
of a single disc in the server.

What about log shipping. How does log shipping work with identity columns?

Does anyone have any experience of this? Can you offer advice and guidance?

Regards

Ian"Ian Wyld" <ianwyld@.tiscali.co.uk> wrote in message
news:41507254_1@.mk-nntp-2.news.uk.tiscali.com...
> Hello All
> We intend to replicate a database in order to have it as a near immediate
> standby in case of the failure of the main server.
> Is this the best solution for disaster recovery?
> We are currently testing our replication plan. When we set up the
> subscriber, a snapshot of the publisher is created and this takes hours.
> Is
> there a better way?
> My understanding is that a RAID array would help in the case of the
> failure
> of a single disc in the server.
> What about log shipping. How does log shipping work with identity columns?
> Does anyone have any experience of this? Can you offer advice and
> guidance?
>
> Regards
> Ian

I don't really know from your description what you mean by "disaster
recovery" - this page covers some of the high-availability options you have
with MSSQL:

http://www.microsoft.com/sql/techin...vailability.asp

One issue with a replicated database as a standby is that if the primary
fails, then your applications need to be reconfigured with the new server
and database name; if you need failover which is transparent to your
clients, then clustering is the usual solution.

For information on optimizing the replication initial snapshot, see here:

http://www.microsoft.com/technet/pr...n/tranrepl.mspx

RAID will protect you against losing one or more disks, depending on the
configuration, as will a NAS or SAN, although MSSQL is only supported on
NAS/SAN solutions certified for it:

http://support.microsoft.com/defaul...1&Product=sql2k

Log shipping copies every transaction from one database to another by
copying transaction log backups and then restoring them. The secondary
database is always offline so the logs can be restored as they arrive from
the primary server - that means no changes can be made (it can't even be
read), so identity values aren't an issue. Log shipping also has the same
application reconfiguration issue as replication, of course.

Log shipping is a simple solution, but the secondary database is offline and
you would lose (at best) minutes of data if the primary goes down.
Replication is more complex, but the secondary database can be online, and
you can limit data loss to seconds rather than minutes. Clustering is
probably the most expensive solution, but you can lose a whole server and
still carry on with no interruption.

Simon|||Consider log shipping instead of replication if all you need it DR.

"Ian Wyld" <ianwyld@.tiscali.co.uk> wrote in message
news:41507254_1@.mk-nntp-2.news.uk.tiscali.com...
> Hello All
> We intend to replicate a database in order to have it as a near immediate
> standby in case of the failure of the main server.
> Is this the best solution for disaster recovery?
> We are currently testing our replication plan. When we set up the
> subscriber, a snapshot of the publisher is created and this takes hours.
> Is
> there a better way?
> My understanding is that a RAID array would help in the case of the
> failure
> of a single disc in the server.
> What about log shipping. How does log shipping work with identity columns?
> Does anyone have any experience of this? Can you offer advice and
> guidance?
>
> Regards
> Ian

Replication and User Defined Trigger

Hi, all:
We have 5 databases which contains invoice and invoiceHistory tables.
We have an update and insert trigger on invoice table to record every
modification into InvoiceHistory table. The invoiceHistory table is not
read only, it has some fields that the end user can edit (comments,
date ...etc). At the same time, we using scheduled snapshots every 5
minutes to 'refresh' the table at the suscribers. The problem is when
the replicate server replicate table invoice to a subscribe, the
trigger on invoice table will be triggered and update/insert
InvoiceHistory table in the subscribe. Then when the replicate server
replicate table InvoiceHistory, we will get duplicate record in
InvoiceTable, one is from Invoice table trigger and another is from
InvoiceHistory replicate.
If we do not replicate InvoiceHistory table, then those fields that end
user updated can not be sync to subscribes.
Can I disable the trigger on invoice table when replication?
Does anybody there have a better idea how to do something like this?
Thanks
Check for the NOT FOR REPLICATION option. If you put it, trigger will not be
fired for replication.
MC
<rockdale.green@.gmail.com> wrote in message
news:1143418413.367012.182670@.v46g2000cwv.googlegr oups.com...
> Hi, all:
> We have 5 databases which contains invoice and invoiceHistory tables.
> We have an update and insert trigger on invoice table to record every
> modification into InvoiceHistory table. The invoiceHistory table is not
> read only, it has some fields that the end user can edit (comments,
> date ...etc). At the same time, we using scheduled snapshots every 5
> minutes to 'refresh' the table at the suscribers. The problem is when
> the replicate server replicate table invoice to a subscribe, the
> trigger on invoice table will be triggered and update/insert
> InvoiceHistory table in the subscribe. Then when the replicate server
> replicate table InvoiceHistory, we will get duplicate record in
> InvoiceTable, one is from Invoice table trigger and another is from
> InvoiceHistory replicate.
>
> If we do not replicate InvoiceHistory table, then those fields that end
> user updated can not be sync to subscribes.
> Can I disable the trigger on invoice table when replication?
> Does anybody there have a better idea how to do something like this?
>
> Thanks
>

Replication and User Defined Trigger

Hi, all:
We have 5 databases which contains invoice and invoiceHistory tables.
We have an update and insert trigger on invoice table to record every
modification into InvoiceHistory table. The invoiceHistory table is not
read only, it has some fields that the end user can edit (comments,
date ...etc). At the same time, we using scheduled snapshots every 5
minutes to 'refresh' the table at the suscribers. The problem is when
the replicate server replicate table invoice to a subscribe, the
trigger on invoice table will be triggered and update/insert
InvoiceHistory table in the subscribe. Then when the replicate server
replicate table InvoiceHistory, we will get duplicate record in
InvoiceTable, one is from Invoice table trigger and another is from
InvoiceHistory replicate.
If we do not replicate InvoiceHistory table, then those fields that end
user updated can not be sync to subscribes.
Can I disable the trigger on invoice table when replication?
Does anybody there have a better idea how to do something like this?
ThanksCheck for the NOT FOR REPLICATION option. If you put it, trigger will not be
fired for replication.
MC
<rockdale.green@.gmail.com> wrote in message
news:1143418413.367012.182670@.v46g2000cwv.googlegroups.com...
> Hi, all:
> We have 5 databases which contains invoice and invoiceHistory tables.
> We have an update and insert trigger on invoice table to record every
> modification into InvoiceHistory table. The invoiceHistory table is not
> read only, it has some fields that the end user can edit (comments,
> date ...etc). At the same time, we using scheduled snapshots every 5
> minutes to 'refresh' the table at the suscribers. The problem is when
> the replicate server replicate table invoice to a subscribe, the
> trigger on invoice table will be triggered and update/insert
> InvoiceHistory table in the subscribe. Then when the replicate server
> replicate table InvoiceHistory, we will get duplicate record in
> InvoiceTable, one is from Invoice table trigger and another is from
> InvoiceHistory replicate.
>
> If we do not replicate InvoiceHistory table, then those fields that end
> user updated can not be sync to subscribes.
> Can I disable the trigger on invoice table when replication?
> Does anybody there have a better idea how to do something like this?
>
> Thanks
>