Friday, March 30, 2012

Replication to establish warm Standby

Using SQL Sever 2k. Anyone seeing a problem with use of transactional replication to establish warm Standby Server. The only problem that I am aware of would be user defined data types.
Aleksandar,
Transactional replication can be used for the purpose you want. I would,
possibly, caution that replication appears to be one of the SQL Server more
"delicate" abilities in that, from my experience, it is "prone" to breaking
under a number of circumstances. However, in a reasonably stable
environment, you should probably be okay. Do keep in mind that transactional
replication will not by itself automatically failover to the replicated
server if your primary server goes down for any reason. If your primary
server does fail, the replicated server will require manual intervention in
order to allow your users to access it as if it were your primary server.
For a rather comprehensive list of options of maintaining database
availability, along with the associated pro's, con's and costs, I recommend
picking up a copy of the book "Microsoft SQL Server 2000 Resource Kit" from
Microsoft Press. Part 4, "Availability" covers the topic, I believe, better
than any other write up than I've encountered to date.
Chief Tenaya
"Aleksandar" <anonymous@.discussions.microsoft.com> wrote in message
news:2867FCF4-6B75-45CD-ABF3-0F338C4FE5B9@.microsoft.com...
> Using SQL Sever 2k. Anyone seeing a problem with use of transactional
replication to establish warm Standby Server. The only problem that I am
aware of would be user defined data types.
>
|||Aleksander
Log shipping is much more suitable for maintaining a warm spare for a number of reasons.
1. Log shipping copies all transactions that occur on the database. Replication copies all the data in articles you have set up. This means that when the database changes you do nothing with log shipping, with replication you need to remember to update th
e relevent articles.
2. With log shipping, you can place the warm database in loading state, no 'accidental' updating can occur. With replication the database is still available.
3. With log shipping if anything happens with any of your logs so that they can not be loaded you will get errors in your log shipping alerting you to the fact there is a problem. With replication if far any reason any of the data is not updated on the wa
rm database you will not know.
4. With log shipping you have controlled updates to your warm database. You always know where you are. Replication does the updates behind the scenes, although fast it is not instant. If you loose the system you can not be sure how up to date the data is.
Hope this helps
John
|||Log Shipping it is. This is exactly what I was looking for. Great help, thank you for replay.

No comments:

Post a Comment