Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 12»»

DR solution..Pls respond Expand / Collapse
Author
Message
Posted Tuesday, March 08, 2011 6:20 AM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, February 07, 2014 5:50 AM
Points: 52, Visits: 165
Hi all

We have a scenario like we have 6 physical boxes on which sql server is running and no of dbs are approx 200.Now we are planning a DR for all these dbs.Can you pls suggest me best solution for this condition?
We are planing to build a single high end vmware servers and make it a DR server for all through Metro clustering,is it possible?or just create a consolidation server and move all 6 boxes into one box and create a single DR box in separate location ?
Post #1074735
Posted Tuesday, March 08, 2011 6:38 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Monday, April 14, 2014 1:34 PM
Points: 15,442, Visits: 9,588
To a very large extent, DR planning will depend on specific business needs, hardware availability, skillset availability, resources available/obtainable, and SLAs/SLRs.

Virtual machines can be part of a DR plan, but more often, they're part of a money-saving plan. They can help if a motherboard crashes, but they aren't really part of handling database corruption, I/O failure, power outages, facility damage/destruction, data loss due to developer/DBA incompetence/accident, et al.

I seriously recommend hiring a contractor who specializes in disaster prep and recovery and going over business needs, etc., with that person. It'll take some time and some (a lot of) work, but you'll end up with a better plan, more suited to your specific needs, than you will by asking a few questions on an online forum and getting a few short, generic answers.

If you can't go that route, then start with the basics. Tested backups, some sort of co-location in case of fire/earthquake/hurricane/civil unrest/etc., redundant power sources (tested, checked, fueled regularly), multi-channel SAN with appropriate RAID arrangements, logs on different I/O systems than data files, server redundancy (mirroring, log shipping, replication, clustering, VM, or some combination thereof), spare hardware (hot-swap drives and spare power supplies at the very least), and, most important, a plan that has been drilled and tested to see how long it takes to recover from various levels of server/database issue.

Those are all general. Hiring an expert will get you specifics applicable to your situation and your business, your budget and your geography, etc.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #1074745
Posted Tuesday, March 08, 2011 6:44 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Wednesday, March 05, 2014 4:14 AM
Points: 563, Visits: 971
GSquared (3/8/2011)
To a very large extent, DR planning will depend on specific business needs, hardware availability, skillset availability, resources available/obtainable, and SLAs/SLRs.

Virtual machines can be part of a DR plan, but more often, they're part of a money-saving plan. They can help if a motherboard crashes, but they aren't really part of handling database corruption, I/O failure, power outages, facility damage/destruction, data loss due to developer/DBA incompetence/accident, et al.

I seriously recommend hiring a contractor who specializes in disaster prep and recovery and going over business needs, etc., with that person. It'll take some time and some (a lot of) work, but you'll end up with a better plan, more suited to your specific needs, than you will by asking a few questions on an online forum and getting a few short, generic answers.

If you can't go that route, then start with the basics. Tested backups, some sort of co-location in case of fire/earthquake/hurricane/civil unrest/etc., redundant power sources (tested, checked, fueled regularly), multi-channel SAN with appropriate RAID arrangements, logs on different I/O systems than data files, server redundancy (mirroring, log shipping, replication, clustering, VM, or some combination thereof), spare hardware (hot-swap drives and spare power supplies at the very least), and, most important, a plan that has been drilled and tested to see how long it takes to recover from various levels of server/database issue.

Those are all general. Hiring an expert will get you specifics applicable to your situation and your business, your budget and your geography, etc.


very good advice... DR is so dependent on your environment, your systems, your budget, etc etc that it is nearly impossible to answer here.

The above is a good starting point though
Post #1074751
Posted Tuesday, March 08, 2011 6:56 AM


Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Friday, February 07, 2014 5:50 AM
Points: 52, Visits: 165
Ok suppose i have to ceate a DR solution for a instance whihc has more than 100 dbs and b sizes is approx upto 30-40 gb.cost is not a constraint for this.Can u pls advise the better solution.Ideally we can go with Logshipping only because mirroing is not possible here......but dont u think its very complex to manage tht logshipping setup?so in tht case wht sud we do for DR? and also whts is proc and cons of Vm boes in tersm of sql server?
Post #1074759
Posted Tuesday, March 08, 2011 7:01 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Yesterday @ 3:30 PM
Points: 41,531, Visits: 34,448
GSquared (3/8/2011)
I seriously recommend hiring a contractor who specializes in disaster prep and recovery and going over business needs, etc., with that person. It'll take some time and some (a lot of) work, but you'll end up with a better plan, more suited to your specific needs, than you will by asking a few questions on an online forum and getting a few short, generic answers.


Seconded. This isn't trivial to do and getting it wrong is costly.

Manvendra, you say cost isn't a constraint. So is geo-dispersed clusters, multiple SANs, multiple servers, multiple data centres and top-end fibre connections costing tens of millions of dollars feasible? DR at the top end is not cheap. I've never seen a client with an unlimited HA/DR budget, not even the banks where downtime is measured in millions of dollars a minute.



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1074760
Posted Wednesday, March 09, 2011 6:40 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Monday, April 14, 2014 1:34 PM
Points: 15,442, Visits: 9,588
Manvendra (3/8/2011)
Ok suppose i have to ceate a DR solution for a instance whihc has more than 100 dbs and b sizes is approx upto 30-40 gb.cost is not a constraint for this.Can u pls advise the better solution.Ideally we can go with Logshipping only because mirroing is not possible here......but dont u think its very complex to manage tht logshipping setup?so in tht case wht sud we do for DR? and also whts is proc and cons of Vm boes in tersm of sql server?


How transactional are the databases? Does it vary from database to database or are they all the same? What kind of connection are you log shipping through and how much bandwidth does it have? How fast does your co-location restore the shipped logs and how reliable is their uptime? How reliable is your uptime? Are you backing up to a separate I/O subsystem than your data and log files? Are your databases on a SAN? If so, how is that configured? How about your log files? The backups?

There are too many questions that affect this to just start giving answers blind like this.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #1075505
Posted Wednesday, March 09, 2011 6:46 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Yesterday @ 3:30 PM
Points: 41,531, Visits: 34,448
GSquared (3/9/2011)
How transactional are the databases? Does it vary from database to database or are they all the same? What kind of connection are you log shipping through and how much bandwidth does it have? How fast does your co-location restore the shipped logs and how reliable is their uptime? How reliable is your uptime? Are you backing up to a separate I/O subsystem than your data and log files? Are your databases on a SAN? If so, how is that configured? How about your log files? The backups?


And...

Why do you say mirroring isn't possible?
What's the downtime SLAs for these databases? Same for all or different for each?
What are the data loss SLAs for these databases? Same for all or different for each?
How far away is the co-location? Is it far enough for the potential disasters whereever you are?
Do you need automated failover?

etc...



Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1075510
Posted Wednesday, March 09, 2011 8:40 AM
Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, April 03, 2014 12:46 PM
Points: 1,413, Visits: 4,531
the pro's of vmware is that you ship the entire instance to DR and just mount it on your DR vmware host and change the IP. no need to mess with logins or anything else. assuming you have dynamic DNS everything should work in 15-30 minutes since the instance is just a bunch of bits on your network that can be moved between any vmware server

https://plus.google.com/100125998302068852885/posts?hl=en
http://twitter.com/alent1234
x-box live gamertag: i am null
[url=http://live.xbox.com/en-US/MyXbox/Profile[/url]
Post #1075612
Posted Wednesday, March 09, 2011 8:46 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Monday, April 14, 2014 1:34 PM
Points: 15,442, Visits: 9,588
alen teplitsky (3/9/2011)
the pro's of vmware is that you ship the entire instance to DR and just mount it on your DR vmware host and change the IP. no need to mess with logins or anything else. assuming you have dynamic DNS everything should work in 15-30 minutes since the instance is just a bunch of bits on your network that can be moved between any vmware server


You're assuming you have (a) the bandwidth to ship it, (b) the server(s) it's hosted on are still up and available to ship from, (c) you have the time to ship it.

None of those will be applicable if you are dealing with, for example, a fire in the server room, or a power outage you weren't actually prepared for, or your SAN dies because of a 2-disk failure in a RAID 5 array.

VMotion and other virtual machine movement solutions are really most applicable for moving virtual machines around in the same data center if one of a set of blade servers (or something similar) fails. That helps with a very specific type of DR, but it's pretty much useless in other types.


- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread

"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Post #1075618
Posted Wednesday, March 09, 2011 9:00 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: 2 days ago @ 11:24 AM
Points: 32,781, Visits: 14,942
DR for 100 databases, 30GB.

Solution1 : Copy the backups onto DVDs/tape, have someone drive them to a remote location every afternoon. Have standby serverse ready in the second location.

Solution 2 : log ship all databases to a second servers somewhere.

Solution 3 : use geoclustering with six servers at each location and SAN replication to make it work.

Which one is appropriate for you? It depends. What is your Recovery Time Objective (RTO) and your Recovery Point Objective(RPO)? IF you don't know what SLA you have to meet for recovery in a disaster, how can you decide which is appropriate for you.

You might want to read up on what is involved with DR first, and understand what things you need to get clarified before you start with any technology.

http://en.wikipedia.org/wiki/Recovery_time_objective
http://en.wikipedia.org/wiki/Recovery_point_objective
http://technet.microsoft.com/en-us/sqlserver/gg545012







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1075631
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse