June 1, 2015 at 4:06 pm
I am looking for some recommendations of how to get the fastest Disaster Recovery for our databases based on the number of databases, instances, and clusters we have.
We currently have 9 2012 SP2 Standard Sql Server Failover Clusters, Each Cluster node currently hosts 3 instances of Sql Server, each with anywhere from 300 - 600 databases per instance.
Our original plan was to replicate over the files through our storage system and then reattach the dbs from there. The second half works great the problem is the replication of the files themselves through the storage is taking almost 48 hours. We are currently working with our storage vendor to see what we can do.
The obvious problem is 48 hours is unacceptable. We are looking for no more than 4 hours if possible.
What would people recommend?
Is log shipping an option and manageable with this many databases? What other thoughts?
I would appreciate any help I could get.
June 1, 2015 at 7:43 pm
I am probably one of the most qualified out there to answer this, since I actually have run 7400+ databases on a single (SQL 2005) server and managed to do this as far back as 2007.
I don't understand why you are worried about "initial full sync time". One would expect SAN replication to take a long time initially but then be able to keep files in sync acceptably without that massive delay. This could even be done synchronously with sufficient bandwidth, although the expense of that would likely be extreme for so many databases unless they were mostly quiescent.
Log shipping is what I used, although it was a custom built system. NOTHING built in will touch the metadata for thousands of databases, at least not back then. In fact the ONLY tool I could use against the servers was SSMS (yep, believe it or not!!) or command-line batch scripting stuff. EVERYTHING barfed on the metadata - ALL third party tools I tried, which was pretty much all of them. But the custom log shipping I built is STILL working all these years later, although the company got stupid and lost most of their business and are now down to less than 3K databases still on the same two servers from 8 years ago.
You have it quite a bit easier with just 300-600 databases per instance.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply