Thursday 31 July 2014

Scripts Library

Probably my most valued tool is my script library.  This is a collection of scripts that I've written and collected and to help manage, audit, interrogate and repair SQL Server databases and services ever since becoming a DBA.  Actually, 'ever since becoming a DBA' is not quite accurate.  In my early days, I had not idea that a script I wrote or found might ever possibly be needed again.

I am proud to say that most of the scripts in my library are written by me.  I say most, because there are a few occasions when I've need something in a hurry and I did not have a script for it.  On these occasions, a quick goggle or a search through the many books I have will give me a script in no-time.  I sometimes add these to my collections, but often rewrite them into a style that meets my needs (like adding output columns, performing calculations or removing information I'm not interested in.)  The re-write is in part to get an understanding of the logic and internals, but also to optimize it for my needs and style.

I first kept my scripts just in my documents on the file system, but soon adopted the use of the script templates area in SSMS.  This made it quick and easy to use the script by double clicking it or dragging it into a query window.  I have considered using a SSMS Project, but have no source control plugins and never quite liked how they worked.  I have also considered using RedGates script library, I'm most attracted to it because its free.  But, I've not yet bitten the bullet and given it a try yet.  (Perhaps I will and I can then blog about my experience.)

Like I said... I'm proud most are written by me.  So I was feeling very uneasy with myself when one of my SQL idols blogged that we should not reinvent the wheel.  I do see why this might be good advice.  I don't know everything, and I don't always have the time to write a script from scratch.  Also there are may cases where a short simple solution will service.  However, I tend to be a careful DBA and I'm not just going to run something on my production server without first understanding it and testing it..  By writing my own scripts (especially the basics like backup and index management.) I firstly get a deeper understanding of how stuff works, why stuff works, and how to get the result I'm looking for.  A downloaded script written by a professional for backup might work great, but by writing it myself, I know I'm going to get the logic and features to satisfy my requirements.  I also will have a better understanding of how to tweak and tune it.  If I only ever relied on scripts written by others, how would I ever develop my skills in script writing and always get the right result.

So what is in my library?  Mostly query's to interrogate state and let me know what is happening on the instance.  These are script looking at things like current session requests, memory grants, file io and (of cause..) Wait Stats.  But I also have: templates for common task, feature demo scripts, audit scripts, and configuration scripts.  There are a number of scripts I've forgotten about or never used since I first wrote them.

So what I'm trying to say is, get your self a script library of your own.  They don't have to be your own scripts, but do take pride in any that are.  What is most important it that you know what they do before you run them.

No comments:

Post a Comment