The Book Is at the Printer …
Got the word today that the book was sent to be printed a few days ago. Woo hoo!
Got the word today that the book was sent to be printed a few days ago. Woo hoo!
I'm proud to announce today that Microsoft made me an MVP today for Clustering. I'm very honored to have even been considered.
Now back to your regularly scheduled program.
Buck Woody recently put up an interesting blog post entitled Help Me Help You. It’s a subject that hits close to home for me. The basic idea of the post is that if you want some help via some Internet forum, don’t post a one liner and expect to get expert help. As someone who does post over on the TechNet/MSDN forums as well as here, speak at conferences, etc., I try to help people as best I can within the parameters of free assistance.
I find Buck’s three main points to be right on the mark. Here’s my spin on them:
1. If you don’t ask the right question, you’re not going to get the right answer. Whether English is your native language or not (and I’ve answered plenty of questions from non-English speakers; I can generally interpret pretty well), doing a drive by (“My SQL Server went down, help!” or “I’m having poor performance, any ideas?”) just does not work. Get specific. If it takes 3, 4, 5, 6 posts just to get to what problems you’re experiencing, it can be frustrating for you. And people like me just want to help. When we ask questions to probe, it’s not to raise your dander. We genuinely need more info to help you.
2. There’s nothing more frustrating sometimes than not doing the basics. Let us know what you’ve done so far. If you’ve done nothing, say so, but realize it’s harder for us. It’s much more helpful to those trying to help you if you can articulate what happened before the event, what you did to try to fix it, etc. Even if you are a junior DBA, it’s easier for us to help someone who can help themselves a little bit. I know many of you want some free advice or help, but doing some homework (for example, you may not have done any fixes, but you found three approaches to your problem and you want to know which would be the best) goes a long way.
3. When it comes to SQL Server, you may be a novice who is under a lot of pressure. Or you may be an Oracle DBA. Heck, you may just be the operator on duty who doesn’t even know Windows. Whatever your feelings are towards Microsoft and/or SQL Server shouldn’t play into your post. If you genuinely want some help, don’t say things like “Well, I was using SQL Server which I hate, but I need to get this issue solved so I figured I’d post here.” I’m less inclined to respond to things like that. SQL Server is not a religious war for me; I’ve used most of the major RDBMSes over the years and at the end of the day, if you like something else or have an anti-MS agenda, that’s your thing. If you want help, do your best to leave that baggage at the proverbial door.
I’d also like to add to what Buck said:
4. Someone else I know mentioned that a “thank you” would be nice if your problem is resolved (whether a PM or a post), and also post what the resolution actually was. Someone else may encounter the problem and your post could possibly help another person who encounters the same problem. The MSDN/TechNet newsgroups have a way to mark a post as an answer, and I like when that feature is used.
5. Do not shoot the messenger. What do I mean by that? You may not like the solution(s) proposed which are more than likely accurate. For example, if you ask how to change the domain for a SQL Server 2008/Windows Server 2008 failover cluster, the answer is going to be it’s an uninstall/reinstall. That is the only supported way to do things. Again, you may not like the answer, but it’s the right one. If you don’t like the answer, that is NOT the time to spout off on Microsoft, SQL Server, the application vendor, the responder, or anything else bothering you at the moment. People who respond are generally just trying to help you in a supported manner.
6. This point is one I run into frequently in the mission-critical space: if you are experiencing a server down situation, newsgroups or e-mailing someone is NOT the best place to look for help. I often see paralysis and waiting to see if things fix themselves or for an answer. In a critical situation, every minute counts. You should be picking up the phone and calling support. I know some of you do not have paid support accounts with some or all of your vendors (including Microsoft), but it’s the best course of action. You will be happier for doing it. Now, I’m not advocating calling support for every minor problem you encounter. There’s a middle ground somewhere. What I’m talking about here is true server down, life or death type situations. If you do not have an urgent problem, alternative methods of support can be just fine.
Well, it’s been about a month since I last posted, but I’ve been pretty busy. I’m literally in the final stages of the book (looking at the final few PDF proofs), so that’s consumed a lot of time. I also delivered my first SQL Server 2008 failover clustering training class down in Dallas for four days last week, and spent a bunch of time getting the demo/test environments up and running. The class went well and I’m looking forward to doing it more if people ask for it. If you’re interested in a delivery, contact me.
This week I’m out in Redmond working on a project and have a few meetings with some Microsoft folks.
One of my PASS abstracts was accepted (Advanced Failover Clustering Installation Techniques with SQL Server 2008 and Windows Server 2008), and I’ll be presenting in November. I have a few that were accepted as alternates, and I’ll know soon enough if they make the final cut.
I’m also presenting two sessions at the Best Practices Conference which is in Reston, VA, from August 24 – 26. The sessions are DBA359 – Tips and Tricks for Successful Database Mirroring Deployments with Microsoft SQL Server and DBA366 – Planning a SQL Server 2005 or 2008 Failover Cluster with Windows Server 2008.
I promise once I’m back from this trip and the book is done, I’ll be a bit more active.
I live in the Boston area. Today, there were massive delays on the T trains (public transportation) all due to a power outage. The power outage which lasted about 7 minutes, was inadvertently caused by a maintenance crew accidentally tripping a breaker at one of the worst possible times – rush hour. To get everything back up and running took about 30 minutes, but the outage brought the trains to a standstill and things took awhile to get back to normal.
http://www.boston.com/news/local/breaking_news/2009/05/power_outage_de.html
Imagine if someone did something similar to your IT infrastructure? This is why having clear processes, good plans, and fully testing everything BEFORE implementing in production is key.