Disaster recovery? High Availability? Who cares?
When I was still a database developer, every time I received an email saying that the "dev(elopment server)'s down" or "prod(uction server)'s down"--I would 1) not panic and 2)not freak out. To me, it really just meant longer coffee breaks. (Yeah, time I could have spent studying or filling up my Journyx timesheet but heck, I was young, I was restless, and break times were good! The longer, the better.)
Customers on the other hand were screaming. Management and users were freaking out. And the DBAs were in deep s***. As long as I could test on my local db, I was okay. I didn't even know about service level agreements. My only SLA, a term totally foreign to me then, was to fix bugs and complete enhancements on the day they were due. Life was easy.
For the DBAs, life wasn't. I'm pretty sure they had some DR and HA strategies implemented. Were they good ones? Maybe. Maybe not.
I really didn't care.
Thomas LaRock
In time, I did learn to care. And in time, I actually got paid to care. If I wasn't careful though or believed everything I read, I'd be one of those saying this "If we have HA, then we don’t need DR". And yes, you would probably be able to slap me with Thomas LaRock's permission. High Availability (HA) and Disaster Recovery (DR): these two concepts get mixed up as often as Gordon Ramsay says BLIIIIP in Hell's Kitchen. Seriously. Shouldn't come as a surprise though. Afterall, some people think REPAIR_ALLOW_DATA_LOSS does not cause data loss.
So kudos to anyone who exerts effort to introduce concepts like HA and DR in a way so understandable you simply just can't mess it up. Exactly as Thomas LaRock described them here: SQL University - HA/DR Week.
My friend once told me, if you put too many people up on that pedestal, it may get crowded. And sometimes, you may have to push people off it. When I read articles like this, I'm reminded why I pushed someone off the pedestal to get Thomas LaRock in (sorry, Mom!). Articles like this, introductory as they are, are what make an expert a teacher. When an expert goes down a few notches to explain something to make you understand and to simplify that which to you may be complex, it is then that he becomes a mentor and more than just another smart guy on the street. Smart techies are admired; mentors *inspire*. And when you're in a community, isn't that what really counts?
Teaching is a challenge. The responsibility is enormous. So to Thomas LaRock and everybody else in the SQL community who bother to make learning easy--thanks! One may say, "But Janice, that article was so basic. Why make a big deal out of it?" Ever heard of the saying "get the head right and the rest will follow"? You see, getting the head right is *not* easy. Giving a good foundation is difficult especially when you've been doing something a looong time. Basic concepts become "just" common sense. Experience convolutes definitions with best practices. Problem solving takes 2 steps instead of 20--and you instinctively just know what to do. Imagine having to step back and see what you know from the eyes of a beginner. Imagine having to figure out how to make learning things that you probably had to learn the hard way, fun. No, it's not that easy. So yes, it is a big deal.
Getting the head right is tough but if you're able to do it, the rest *will* follow. And it is oh-so-blip-worth-it.
CONCLUSION
Imagine a blank sheet of paper. Imagine that it's absolutely critical that you write on it. If somebody spills water on that blank sheet of paper, your DR strategy is to leave it to dry. See the other blank sheets of paper you have in your drawer? That's your HA strategy.
See? I get it. 
June 11th, 2010 - 17:56
Thank you so much for such kind words. I am glad you found the information useful.