Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
magictech
Starting Member
44 Posts |
 Posted - 2005-03-10 : 13:53:22
|
| Is there anyone out there using replication as a disaster recovery solution? I would really like them to share their experience using replication as a solution for disaster recovery. For example, replication doesn't copy constraint to the DR server. What is their strategy to ensure that objects in both databases stay in sync? How do they handle login id transfer to the DR database? Any information would be greatly appreciated. |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2005-03-10 : 18:00:26
|
| The PASS conference had a session on this. You can purchase a copy of it from the sqlpass.org site.But replication is not a disastery recovery solution. If the reason why you don't want to use Log Shipping is because you don't want to purchase Enterprise Edition, then simply create your own log shipping routines. This is quite easy to do. You can find information about it at nigelrivett.net sql-server-performance.com.Tara |
 |
|
|
magictech
Starting Member
44 Posts |
Posted - 2005-03-11 : 09:50:38
|
| Thanks for responding to my posting. I had log shipping up and running for over a year until the DR server was moved to a remote location. The problem is the bandwidth at the remote site is only 1MB. The bandwidth of our local network is 1Gig. Because some of the log files after our weekly re-index job runs in about 40Gig. It’s impossible for log shipping solution to copy and restore a 40Gig log file via 1MB bandwidth network to the DR server. That’s why we made a decision to stop using log shipping and go with replication instead as a disaster recovery solution. This is my story in a nutshell. Any information to ensure the DR server is in sync via replication would be greatly appreciated.Thanks again |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2005-03-11 : 12:17:59
|
| You'll have a similar problem with replication when you need to perform a snapshot.Tara |
|
|
|
ravilobo
Master Smack Fu Yak Hacker
1184 Posts |
Posted - 2005-03-24 : 09:23:41
|
| We are using mere replication for DR. What info you need?------------------------I think, therefore I am |
|
|
|
magictech
Starting Member
44 Posts |
Posted - 2005-03-24 : 10:23:37
|
| Thanks for responding. I need enough information to be able to setup DR solution using merge replication in my environment. I've tried using Transaction replication with immediate update but it doesn't seem to be working. I'm getting this error message "Updatable Subscriptions: The text/ntext/image values cannot be updated at Subscriber. " when testing the immediate update solution. Please provide enough information on how merge replication could be use as a DR solution. After setting up the merge replication, do you end up with identical databases that would allow your application to function properly on the second database when a disaster occurs? Thanks in advance. |
|
|
|
ravilobo
Master Smack Fu Yak Hacker
1184 Posts |
Posted - 2005-03-24 : 10:31:25
|
quote:
Originally posted by magictech
After setting up the merge replication, do you end up with identical databases that would allow your application to function properly on the second database when a disaster occurs? Thanks in advance.
Yes you can achieve this. But this is not automatic..the db server name you may have to change in your connection strings...merge replication adds a rowguid column to every table in replication is it ok with you? Your user application need to handle this...------------------------I think, therefore I am |
|
|
|
|
|
|
Using Replication as a Disaster recovery solution