Like many SQL Server DBAs I run into a problem at work or get an idea in my head then scour the internet to see if someone else had the same thing so I don’t have to reinvent the wheel. Some DBAs stop at that point, I don’t. I grab a script that serves my basic needs, test it out, rewrite it to be written as simple as possible while granting me every wish and desire I ever had on the process, then I save it off.

I use the term Simple with my approach because each thing I do displays information to the user (me) as simply and user-friendly as possible.  As I tweak my scripts they get increasingly more complex to make the results increasingly easier to read with more information available.  It makes my job easy as I find the information once, save a script, and get most of what I need by running the scripts.  If I find them lacking in a reusable area, the scripts get edited and I’m ready for next time.  The output of a script should describe what you’re looking for as simply as possible, mostly because Einstein said that if you can’t describe something simply then you don’t know it well enough, and he was kind of a smart guy.

Beyond that, my biggest thing on SQL Server is base-lining and trending. A common issue you’ll run into is in the middle of a performance incident you’ll find a stat that seems off on your biggest, most critical server. The other servers don’t look like that, but they don’t have the hardware or the load so you don’t know if you should trust that or not. I’ve read before (I think from Brad McGehee?) that the only thing consistent between all database servers is making sure the power is turned on, and it’s right. You’re lost, and the only solution you have should have started over a week ago so you know what “normal” is for that server. Many of my scripts will rely on info being gathered every 1, 5, or 15 minutes and will, by default, compare the current snapshot to the same time window yesterday and the same day last week.

Finally, my personal approach to it all. I don’t take anything too seriously as it stifles creativity and sets you up for arguments on things not worth arguing about. Some people will tell you there’s a right way and a wrong way…they’re wrong. There are thousands of right ways and millions of wrong ways. There are times I’m wrong, and always another “right” way to handle the way I do everything I do. Don’t keep these things to yourself, tell me, yell at me, compliment me, suggest other ways. The purpose of this blog is to have a previous coworker stop calling me a leech while at the same time leech off of your critiques of my work.

Ask for anything. I may have a script written for it, I may write queries for it ad-hoc (rare event…if I wrote it, I saved it), and it may be a new concept I never considered before. In any case, if it’s worth me knowing then I’ll find a way to know it, and if I know it then there’s no reason not to tell the world.  My biggest goal with this blog is to tell my former self what he needed to know and what would have started him on the fast-track of really calling himself a quality DBA many years before he did.  It’s too late for him, I know that, I’m not THAT crazy, but there are millions of people out there in a similar position and only a couple people doing quality blogging for that audience.

My only request in all of this is that you steal what I have, don’t just copy it (Is that a Picaso quote?).   Copying it mean you copy/paste my code and use it.  Stealing is copy/paste followed by making it your own.  That last part is where you’re going to learn the concepts and DMVs, and how you’re going to learn to put the pieces together that I don’t mention here.  I admit it, I just scratch the surface (intentionally), and to dive deep you need to understand the surface.