Replication Clean Up of Failed Server

On my distribution server, I have a failed replication (the big red X) for a
server that had hardware failure a couple of weeks ago. We were able to
bring this client up on a separate server and have re-replicated them. Now
I need to get rid of the failed replication however when I try to simply
delete it, it obviously cannot connect to the failed server since it doesn't
exist and therefore will not delete the information from the DISTRIBUTOR.
I would like to avoid manual system table clean up unless someone has the
method that will completely remove this information.
Is there a way to do this correctly?
Thanks,
Adam P. Cassidy
Did you follow these instructions?
http://support.microsoft.com/kb/324401
Also on your distributor you may have to issue a call to
sp_dropdistpublisher
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Adam Patrick Cassidy" <apcassidy@.aol.com> wrote in message
news:OnM$cTvaHHA.2436@.TK2MSFTNGP06.phx.gbl...
> On my distribution server, I have a failed replication (the big red X) for
> a
> server that had hardware failure a couple of weeks ago. We were able to
> bring this client up on a separate server and have re-replicated them.
> Now
> I need to get rid of the failed replication however when I try to simply
> delete it, it obviously cannot connect to the failed server since it
> doesn't
> exist and therefore will not delete the information from the DISTRIBUTOR.
> I would like to avoid manual system table clean up unless someone has the
> method that will completely remove this information.
> Is there a way to do this correctly?
> Thanks,
>
> Adam P. Cassidy
>

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