For February 2011, T-SQL Tuesday is brought to us by Pat Wright (blog | @SqlAsylum). It’s funny, I’ve talked to him on Twitter a few times, but didn’t know his real name until now. Pat has some great photos from PASS 2010, which last November made me even more jealous that I wasn’t able to go.
Anyway, I just realized yesterday that T-SQL Tuesday was today, so this is will be a quick one. But I didn’t want to pass it up, because automation is a topic that I feel is extremely important yet still somewhat under appreciated in parts of the DBA world.
In my job history working with SQL Server, I’ve almost always been part DBA and part developer. And every job I’ve had has looked something like this:
- There are day-to-day repetitive traditional DBA type activities that I need to get done
- There are existing products or processes that need improvement for stability and/or optimization
- There are longer term projects that I would like to dedicate time to and make progress on
Over time, I try to push toward reducing the time needed for mundane things and increasing the time available for longer term things. The longer term things are always more valuable, certainly more educational, and definitely more fun. One of the ways I try to get there is though automating repetitive processes wherever possible.
I’ve had mixed success with this though – here’s a cautionary tale from my own experience. At a previous job there was a process that was run twice each week to create a set of data that eventually became AP payments to customers. When this was first developed, there were some serious problems with the process and with the source data, so I volunteered to step thorough it to verify and balance the results. Because this worked so well (read – no bad checks), I was asked to do it again. And again. Before I knew it, this became the “Dave process.” After the source data was cleaned up, I made some attempts to push for an automated solution, but wasn’t able to get there, partially because I was busy and partially because there were other already overworked teams that would have had to dedicate resources to the effort.
I’m embarrassed to say this went on for almost 2 years!, and it only ended when I announced I was moving on, and would therefore no longer be the Dave in the “Dave process”. Fortunately, I was able to finally convince them that this task shouldn’t be transitioned, but really needed to be automated. That was completed before I left, and it’s still going strong last I heard.
I often wonder how much time I would have had for other things if that process had been automated from the beginning. I think the amount of time could easily be measured in weeks. And that was just one process – there were many other developers / DBAs in similar situations. I never want to get into that type of situation again.
Just yesterday, I read a good post by Denny Cherry (blog | @MrDenny) about backups that basically said, if you’re not doing database backups, you’re not doing your job. Kind of harsh, but definitely true. I think in the same way, if you’re not trying to automate your repetitive tasks, you’re not doing your job as a DBA. Sure, you may be getting by for now, but you’re not doing the best that you can for your employer or for yourself. And isn’t that really what it’s all about?
Thanks for reading, and happy Tuesday!