JoshDBGuy (1/6/2014)
My concern has to do with contact backups on the primary database, transmissions failures, etc. From what I've seen, when transmitting a large number of logs because of potential connection issues and the number of backups we run, log-shipping may be a problem.
With LS you control the frequency of
In the past i've log shipped a large database from UK to Arizona over a less than ideal link, by compressing the backups you'll save bandwidth. Quests Litespeed log shipping or Redgates sqlbackup log shipping are both excellent for this. If using 2008 R2 std you have native compression available too, no excuses 😉
JoshDBGuy (1/6/2014)
Also, we do need the secondary DB to be readable. Which I know can be done with log-shipping but I thought it would be easier to use replication. This may not be the case.
The fact you want readable rules out mirroring. Yes you could snapshot but the overhead to maintain the snapshots, plus the disk space required. Hmm, naaaah thanks.
(12/30/2013)
From what both of you have said, mirroring may be the way to go.
No that's not what I'm saying
JoshDBGuy (1/6/2014)
I have never implemented mirroring between servers at different data locations.
Even more reason to give it a wide berth then 😀
JoshDBGuy (1/6/2014)
We do have a fast connection so even if there is a couple gigs of data to mirror, do you see this as being a problem? Also in terms of maintenance, is it easier to maintain log shipping or mirroring.
I'm confused, you won't use LS cos you're worried about log copies sucking bandwidth, but you have bandwidth to support mirroring!!
Log shipping is the easiest to maintain and still provides a readable secondary, lots of bang for your buck 😉
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉