I've had days like this one. Something goes wrong, then something else, and before you know it, you are overwhelmed by a cascade of disasters, enough to overwhelm you even if you'd thought of contingency plans for all of them. The link is from a blog by MVP Jonathan Kehayias and he brings up some great points in the blog about disaster recovery.

You should have a plan for possible problems, like a spare tire in your car. I know most of us have a spare tire, which comes by default from the manufacturer. Wouldn't it be nice if we had a default DR plan for SQL Server that came from the manufacturer? Some type of spare tire to protect us against common faults in the product. Like an automatic backup set for once a week, you know, just in case something like corruption happens? (hint, hint, MS).

However setting up your plan, even validating it after it's documented isn't enough. A computing environment, just like our experiences on the roadways, are always changing. We come to expect a certain level of stability, but there are always unexpected events coming up. Debris on roads, software changes due to patches, new databases are created, all kinds of seemingly trivial alterations of the environment occur reguarly. Most have no impact on our lives, but occassionally, once in awhile, one does.

That's a disaster.

And if you haven't regularly checked the air in your spare, you could find yourself in a bad situation. Maybe even a job-ending or company-failing situation. I'm not completely sold that being unable to recover an important database, especially in a large company will cause them to go out of business, but is it worth the chance?

Set yourself a periodic reminder to go over your DR plan, double check that its assumptions and its processes are still valid. More importantly, make sure it's actually protecting what it should be protecting.

Virtualization

I've seen a lot of debate and discussion about virtualizing SQL Server instances. I tend to be on the pro-side of considering virtiualization, but it is certainly not for every instance in your environment. You have to carefully analyze each instance and make a decision about whether or not it's a good candidate for virtualization. And even then you need to be sure that you have properly sized the virtualization environment. One VM is not like another.

This past week I saw an interesting series on virtualization from Andrew Fryer. It has four parts on Licensing, Performance, Management, and a general overview. Andrew works for Microsoft, and so this is definitely a pro-MS software point of view. It contains lots of links to other parts of Microsoft, but it's worth reading. The ideas that he presents, along with some good fundamental files, are things you should consider. I especially like that he addresses some of the concerns, like how many CPUs you can commit to VMs and specifically how licensing works.

I think that you still might want to be conservative with your SQL Server instances, and potentially not push your hardware to the limit. If you have busy SQL Servers, meaning they use a lot of CPU and IO, I'd be wary of consolidating them through virtualization. If you have new instances and you think they might experience any sort of load, start them as physical machines. There are plenty of tools to move them to virtual machines later if they don't need lots of hardware. Not a lot of tools to do the reverse.

Steve Jones