TSQL Tuesday – Beach Time

TSQL TuesdayWell here we are, it is already time for another TSQL Tuesday. This month Jason Brimhall has asked what a dba should do before they head out on vacation. This is certainly a topic near and dear to my heart. While I certainly work my tail off and I am more than happy to be the first in and last to leave, I also like to play hard to.

In my current position I am pretty lucky all the way around but particularly when it comes to vacation time. I get a good amount of time each year and for the most part my team is very flexible when and how I spend that time. I’m not a production dba so there are not any systems which I am directly responsible. Instead I work as part of a small team providing consulting services for more than 9,000 servers running SQL Server.

So while I cannot make specific recommendations on what I do, I will try to make some recommendations from the standpoint of anyone walking into the unknown. There are occassions where I get called in because the companies dba is out on vacation. Whether it is a consultant or coworker filling in there are several things that can be done to help things run smoothly in your absence.

#1 Documentation- Document the heck out of everything. What is the application, who is it serving, what are the availability requirements, and how do we connect are great places to start. Take a few minutes and think about the db, the instance, and the server. Are there any quirks, any special jobs (particularly if they are scheduled outside of sql), or anything else that may not be inherently self documenting. The more information you provide the better, and the more likely your much needed days of R&R will go uninterrupted.

#2 Change Management - While this is a variation of #1 I think it is important enough to warrant bringing up seperately. I come from a law enforcement background and we were constantly told, “If it is not written down, it never happened.” I still firmly believe in this. Whether it is 3 days or 3 years later it is important to know what has been changed, when it was changed, and why it was changed. I can remember one time spending two days chasing down an issue only to find out someone had made a very simple and seemingly innocuous change. Had we known about the change and the time frame, we could have put two and two together and saved a whole heck of a lot of hassle.

#3 Monitoring – You are monitoring your servers aren’t you? It is great to see what is currently happening but it is even better to have a history of it. A good baseline of what is “normal” can go a long way. I have seen some servers that can easily handle and regularly do handle 1200 connections. Other times I may be on a server that regularly has 200 connections, but at 250 it falls over. Again this is about saving time and hopefully keeping the person filling in for you from running down unnecessary paths.

Looking over the post, I noticed a definite theme. In reality everything is a matter of good documentation and having good polices and procedures in place AHEAD of time. In the end it should not matter if you are skipping town for a week on the trip of a lifetime or if you need to take a last minute day off because of xyz… It is just a good practice to be prepared and make sure your absence goes smoothly. There is something wrong if everything will fall apart while you are gone and it is not a good situation for you or your employer. The real hero of the day will be missed because they are a true asset, not because the world stopped in their absence.

,
Trackback

3 comments untill now

  1. Strong finish to your post. I like the last sentence.

  2. [...] Jeremy Carter (Blog | Twitter | TSQLTuesday9) [...]

  3. Nice post!! I agree that the sign of a good system is that everything operates smoothly when you’re gone, not that it falls apart without you!!