I hit on this topic a little in my previous blog post (Helping the Helpers), but I wanted to expand on it in a different way. Whether you’re posting to a newsgroup, at a conference in a 75 minute session, or even paying for an hour of help, very rarely – if ever – are you going to design a solution or get the whole story in a short amount of time. Is it impossible? No. Unlikely? You bet.

I’ve found people want absolutes, and I sound like a broken record, but nearly everything about SQL Server, and especially with things like high availability boil down to two words: it depends. I never take a one size fits all approach when I’m consulting or presenting a session and answering questions. What is right for one customer is not for another; there’s a difference between how something works, which can lead to black and white answers, and how something fits into an overall context. I like to think that I provide end-to-end, holistic, and realistic solutions when I work with customers; I don’t just “do clustering”. I can’t know everything about your situation by only talking to you for a few minutes; I can make some good guesses as to what you have going on based on experience, but I’m always hesitant to give anything more than more generic advice if I don’t know most of the facts. Here’s an example: people are suprised I don’t lead with failover clustering as a solution for everything considering it’s what I’m best known for. It’s just not appropriate in every single solution I help with, but more often than not, it can and does work.

Similarly, I’m often the focal point for what people don’t like or feedback about a feature – for example, I can’t tell you how many times I’m asked why failover clustering isn’t like Oracle’s RAC. I may have worked for Microsoft, but I didn’t design SQL Server. I don’t sit in meetings where decisions are made about features like failover clustering. A lot of the problems I think people have are just misunderstandings of how a feature or technology works versus how they think it should work. Whether you agree or disagree with how something works, it is what it is. No one knows that better than me.

It’s not always easy to ride the line between honesty about how a feature works versus sounding like you’re complaining. I try to do the former, and let people form their own opinions.  Anyone who knows me well understands I’ll be honest about how I feel about something, but one of the things you learn as you get on in a career is when to self edit. If you’ve seen or used either Facebook or Twitter, you know what I mean. Some people put a LOT about themselves out there. My job as a speaker is to convey my experience, give some opinions, and to paint a realistic picture of how things work – good and bad. Nothing is perfect. It is NOT my job to bash Microsoft or a feature. Sometimes those opinions or facts of how a feature may come off as negative, but that’s not really the intent. Those in the audience won’t relate if I’m trying to sound like a salesman; they know the pain that can happen when you’re a DBA. I also realize that DBAs who come to see me speak just want some nuggets to do their job better; they’re so busy doing their day to day thing, when they’re at a conference they need to soak up as much as possible because they’ll be back to heads down in a day or two … if not already, since conferences are always working events for everyone.

I always joke, but it’s true – you often spend more time planning than you do the actual work. You can plan for months to do a data center move that when executed, only consumes 24 or 48 hours. It may seem odd, but it’s completely accurate. The technical bits are only part of the picture; failover clustering is just the end implementation of an overall high availability solution which is tied into people and process, SLAs, and the needs of the application. Those months are spent mitigating risk, gathering information, and testing.

So what’s the bottom line here? Don’t expect that what Company A does is right for you, and to get it right is more than talking to someone for a few minutes. Take what you get at a user group or conference, and apply it to your situation. There is no magic SQL fairy dust which gives you better availability that is completely transparent to every application known to mankind. Everything has its tradeoffs. Knowing how each feature works allows you to design applications and solutions which fit your needs.