Why To Do Some of the Grunt Work, Even If You Don't Have To

on July 1, 2010

Part of this past week I’ve spent doing a new SQL Server 2008 R2 installation and configuration on a Windows 2008 R2 cluster. I  haven’t done an install end-to-end in quite a while– I have teammates who take care of it while following our installation checklist document.

I started doing the install and configuration myself because I want to create fresh unattended install files, which I will later turn into slipstream drops. (For more on my love of slipstream installs, see the post here.) I will also be branching the install document soon to create a new version for SQL 2008 R2. Although the install for R2 isn’t very different, many of the paths used for copying files and a few scripts change, so  it’s less confusing in a separate document. In preparation for branching the file, I thought it would be good to give the 2008 install document itself a spring cleaning to clear up anything misleading.

Oh, Wouldya Look at That…

This was an interesting experience. Although everything technically worked, some cleanup was needed on Aisle Seven.

The checklist is in a Word document so it can be filled out and saved in a history folder on SharePoint each time it used. In a recent past life this was all in a wiki, however. The wiki-to-SharePoint conversion was a shared project on a tight timeline and a lot of copy’n’paste was needed, so some of the fOr****MatTing waS nOT wHat YoU’D e****XpecT 

Some steps were in a slightly strange order, so you were over here in PowerShell, now over here in SQL, now back to PowerShell, now  reboot! Reboot! Reboot!  Now check out your page file. Run another PowerShell script! Hey did you forget about the other nodes in the cluster, this step finally mentions them– let’s go back and do all those again on the other node, hmm?

I also found that lo and behold, there were some steps I’d kinda forgotten about. Sure, I know this stuff, I’m not a complete goofy panda a trained professional. I have lots of experience!  But that’s sort of the problem. I have lots of experience and while I can synthesize gobs and gobs of it into a cohesive picture, there’s certain details I end up forgetting if I don’t work with them for a very long time.

And yes, GOBS is the technical unit for DBA experience. It’s like how large volumes of data appear in WADS.

What I’m Sayin'

I re-learned that it’s important to occasionally revisit and improve things you already know how to do.  Especially if you’ve delegated these tasks to others, you may not understand them as clearly as you’d like to think. Maybe you’ve learned things recently that allow you to streamline the tasks and make them easier, too.

But most importantly, it’s key to understand the full details of your environment’s configuration. Knowing how something is set up will save a ton of time when you need to troubleshoot it. Besides time being money, it’s YOUR time, and that’s what you want more of, right?