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-01 : 13:28:22
|
| We’ve been using SQL Server log shipping as part of my disaster recovery strategy for over a year now. A couple of weeks ago we decided to move the fail-over server (the server that the transaction logs are being shipped to) to a remote location (Disaster recovery site). The problem with the DR site is the bandwidth is only 1MB. The bandwidth of our local network is 1Gig. Due to the 1MB bandwidth problem Log shipping started having problems (restore and copy jobs started failing). After our normal weekend re-indexing, one of the transaction logs grows to about 40Gig. Log shipping isn’t able to copy and restore a 40Gig log file across a 1MB network to the DR site. We’ve decided to discontinue Log shipping and go with SQL Server transaction Replication for disaster recovery. I understand log shipping is the most appropriate solution in this situation besides clustering. Is there anyone out there who is using replication as a solution for disaster recovery? Does it really work? My main concern is with the recovery process since replication adds extra objects in a database. Please help.Regards |
|
|
ravilobo
Master Smack Fu Yak Hacker
1184 Posts |
Posted - 2005-03-24 : 10:02:14
|
| You can use merge replication. And select the merge agent property for a weak bandwidth. Only problem i foresee is that, merge replication adds a ROWGUID column to all replicated tables. Your user applications may have to handle this properly...------------------------I think, therefore I am |
 |
|
|
|
|
|
Using Replication as a disaster recovery solution