I had the opportunity to present a talk last weekend at the SQL Saturday event in Nashville. The organizers arranged for me to give my talk at the start of the day, and put me up against some advanced sessions. The idea was that if people were looking for an introductory session that mine would be the easy choice.

The talk was received well enough. It was a little different venue than I am used to. We held the talk in the cafeteria. That meant the acoustics would be slightly different, the screen was a little smaller, and people would be prone to distractions as other people walked by (or, as they loaded food and drinks onto tables). I tried to use all of that to my advantage in some way and I would like to think I succeeded as the overall rating for my talk was a 4.5 on a 1-5 scale with 5 being ‘great’.

Afterwards I had eleven people ask for a copy of my book and I hope to be able to get them each a copy as my way of saying ‘thanks for coming’. I did have a few people ask if I had copies of my book for purchase, but I didn’t. And I doubt I will ever bring books to such an event and charge people for them. That’s just not my style. When I go to events like this I will bring a few copies to give away as prizes, but I will not be charging money.

All in all I think the talk went very well.

I was thrown to the wolves this past week while at TechEd. My new company, Confio Software, asked me to join them for the show and to work the booth with them as well. I felt like a shiny new toy. I was also asked to speak on occasion to attendees who came over with some questions. I did the best I could, and in each case I found that it was easy to have a conversation if I did something very simple at the start: I listened.

By listening to someone I could get an idea of what it is they needed. One person stopped by and asked if our product handled database security (it doesn’t). Another person seemed to want to know a lot of performance details but then said they weren’t the admin so they were essentially looking to recommend a tool for their admins to purchase. In both cases I was fortunate to know enough to listen to the person speak first in order to get an idea about their needs.

The entire experience made me think about a section in my book, DBA Survivor, where I discuss the importance of sitting down and talking with someone. This excerpt is geared towards your life as a production DBA, but the idea is the same; learn how to talk with, and listen to, others around you.

Pure and simple, nothing beats sitting down and talking with someone. The more people get to know you the more they get to understand what it is you actually do for work. Along the way they will get to understand the variety of tasks you perform and even some of the difficulties you face.

If your shop has multiple offices then it is going to be more difficult to sit down and talk with people. While it is more difficult, it is not impossible. No matter who you are talking with or where they are located the most important thing you can do is maintain an even tone of voice. I know that those are always the people I enjoy talking with every day.

Another tip would be to learn the power of the phrase “I understand”. Those two words can communicate a lot to the person you are talking with. You can be saying that you agree with them (“I understand what you are saying”), or you could be saying that you do not agree with them (“I understand what you are saying but I am still not convinced.”) The bottom line is that you can be a most agreeable person to talk with simply by using those two words.

Now imagine this conversation:

“Why the hell is that restore taking so long”

“Well, it looks like the database has grown in size. It should take another fifteen minutes.”

“We need it to be finished now, why is it not done yet?”

“I understand that you need it done quickly, and as soon as it is done I will send you an email or I can call you if you prefer.”

How could someone possibly be expecting you to do anything more for them at this point? By talking with them you have made a connection with them, shown them that you are human, that the desired results are coming, and most importantly that you understand their needs.

That might be the most important thing you could ever communicate to someone, and it is easiest to communicate when you sit down to talk.

At TechEd I had the opportunity to sit, talk, and listen with a lot of different people. I hope that I was able to offer assistance and guidance when necessary. And I would like to think that my years as a production DBA have served me well when it comes to having such conversations.

Today I was reminded about how easy it is for people to get frustrated with things they do not understand. And these days it seems as if there is even more to be confused about than ever. What can be frustrating for a DBA is that even though you are trying to help, you are simply perceived as being part of the problem. So I reached for my copy of DBA Survivor and went back through the chapter that covered some basics of the job and I found this section…

This one is fairly self explanatory. People will always tend to blame something they are aware of but do not fully understand. It is only natural, right? I mean, if you think you already know everything about nine out of ten items then your mind will focus on that tenth item and you will spend far too much time on why the tenth item is causing you so much heartache at the moment.

You will frequently be told such things as “Our code hasn’t changed in years”, “Everything ran fine last night”, or even “You guys must have done something yesterday because now all of our stuff runs much slower”. Get used to being the focus of attention for any problems with any system. Start developing some thick skin because you are going to need it, and soon.

Any time there is even one hint that something is amiss with a system and the first thing people will do is blame the database server. Despite the fact that there are many layers between their screen and the database server your phone will be the first to ring. You will be expected to investigate the issue immediately and you will also be surprised to see emails with sentences that say “I called the DBA and they are going to fix the problem.” Wait a minute! We never said there was a problem with the database server, why are you telling people we are going to fix anything? The problem could be the network, or a poor design that didn’t scale, or anything. And yet people will fixate on the database server because (1) it is known and (2) most people do not understand how it works. And, in some cases, because they will get an error message such as “Could not connect to the database…”, or the word “database” is in the error message somewhere, and people automatically assume that the problem must be with the database.

I have lost count of the number of times I have been told there is something wrong with the server only to find that the issue is that the person or account did not have rights to login. Sorry, but that is not a problem with the server. And it is also not a problem with the server if you try to load 100Gb of data onto a disk that only had 10Gb of space free. Same for filling up a 33Gb tempdb drive; the issue is not with the server, it is with inefficient code. And yet your server (and ultimately yourself) will be forced to carry the burden of fault.

That’s OK, because one of the reasons you are a DBA is because you are able to carry such a burden as would crush most of your peers.

John Sterrett posted a review of my book at http://johnsterrett.com/2010/05/13/dba-survivor-becoming-a-rock-star-dba/ yesterday. It pleases me to know that people are truly enjoying the book. I was especially happy to hear that John thought my “Where’s the Buffet” chapter was one of the most important. During the writing process that chapter was called into question a couple of times as some people felt it might not be the right fit for the theme of the book overall.

I am very glad that my editor supported the idea of that chapter, and even more glad to know that at least one other person on this Earth saw the value in having it included.

Thanks for the kind words John.

Today I was pleased to see a review of my book by Brent Ozar. You can read it for yourself at:

http://www.brentozar.com/archive/2010/05/dba-survivor-by-tom-larock-book-review/

I was very fortunate to have Brent agree to take part in the review process as it was being written. Brent has been through a lot of fires in his career, and his input on the book was instrumental in making those final chapter drafts resonate.

Thanks Brent!

[This is an excerpt from Chapter Six, Basic Troubleshooting]

Think of the job of a police detective assigned to the forensics unit. No matter what time of day or night, when a crime happens they will be called to investigate. They make certain the scene is secure, they gather their evidence, interview witnesses and suspects, and do their best to solve the crime. Not only will they need to interview people but they will need to set up surveillance on their suspects and monitor their activities for a period of time.

On television all of this happens in less than an hour. In real life it takes a little bit longer. And some crimes never get solved.

Now think about your life as a DBA. No matter what time of the day or night someone, somewhere, is going to have an issue with a database or a database server. And when that happens, you are going to get called in to investigate. You will be expected to immediately analyze all available details and provide a recommended course of action. If your job was a television show, you would be given about an hour to solve the issue. In real life people want an answer in less than a few minutes, especially if it is the middle of the night. And rarely are your issues allowed to go unsolved.

In order to provide that high level of support you will need to make certain you can do three things. First, you need to know where to look. Second, you need to know what questions to ask (and who to ask). And third, either review your monitoring or put your monitoring in place. In order to provide that high level of support you will need to make certain you can do three things. First, you need to know where to look, which we will assume to mean an incident has taken place. Second, you need to know what questions to ask (and who to ask), which you can think of as an interview (or an interrogation). And third, either review your monitoring or put your monitoring in place, which is the same as surveillance.

That is the DBA circle of life: something will happen, you will ask some questions, and you need to monitor some things going forward.

I touch upon these topics in Chapter 4 of the book, DBA Survivor, and every now and then I need to remind myself of the fact that a little rest can go a long way. Here is the excerpt:

“Stress relief is important to time management as it allows for you to continue operating at a higher level of efficiency. When stress hits it will affect you in a variety of ways, one of which is your lack of focus and subsequent decrease in productivity. Not to mention the fact that you can bite someone’s head off if they approach you without bearing gifts. When you start to sense that you are feeling overwhelmed and that stress is wearing you down it is time to get up out of your cube.

Take a walk at lunch. You’ll be surprised how ten minutes around the block outside can make a big difference in your day. Go sit on a bench somewhere and watch people pass by for a few minutes. I took up jogging a few years back and find it a nice distraction during the day, especially when you have a jogging partner that you enjoy having a conversation with.

No matter what you or anyone else chooses to do to relieve stress you all have one thing in common: you select activities that energize you in some way.

That is the key to relieving stress effectively. Find something that energizes you, something you enjoy doing no matter what your mood. Of course, if you happen to find that your job is what energizes you then you are one of the lucky ones.

Another key to relieve stress is identifying those times when you are stressed and you know to get up and do something that energizes you. This is not going to be the same for each person; you will need to find the things that work for you as well as recognize the symptoms of stress when they occur.

Now, I am often asked this question regarding stress relief and time management: “…but isn’t taking time away from work in fact wasting valuable work time and making it harder to get things done in the time allowed?”

Absolutely not.

Relieving stress will keep you productive; when you are productive you are also efficient; when you are efficient, you are maximizing your time wisely. It really is that simple. Would you rather spend an hour dragging your heels to get through some tasks or spend thirty minutes getting some fresh air and then another thirty getting the tasks done with a clear mind?

When I was coaching basketball I would always stress that if we prepared ourselves mentally, physically, and emotionally then we were going to be tough to beat on any given night. Same thing for when you are at work. If you feel stress coming on and it is draining you in some way, find something to energize yourself and you will be amazed at how much more productive you can become.”

I was reminded of this just yesterday while taking a jog. Towards the end I got a little tired and started to walk. Another jogger was slightly ahead of me when I stopped. I walked for a bit and then started running at 1/4 pace (rugby term). I got closer to the other jogger, then started walking again. I started running at half-pace (rugby term) and passed the jogger, then walked again. This back-and-forth continued until I was sprinting at full pace on and off for the last half mile.

Had I just continued jogging then I would have likely completed my route in a certain amount of time. By doing the intervals, with a gradual increase in pace, I completed the route in less time.

Other things in life are the same way. Know when to rest, know when to walk, and know when to run.

My book was mentioned in a recent Midnight DBA podcast. Sean and Jen had Jorge Segarra (blog | twitter) and Denny Cherry (blog | twitter) as guests in their hotel room and the four of them had a brief chat about how there are not very many opportunities in our industry for apprenticeships. I was very fortunate to have a mentor take me under his wing when I was getting started as a DBA, but not everyone is as lucky. I share my story (and a few others) in Chapter One of DBA Survivor.

The idea of an apprenticeship also led to a very interesting comment, and that was: companies want to hire junior DBAs with a wealth of experience. About the only thing ‘junior’ with regards to the job position is the salary, because the job requirements are usually so long that only a mid- to senior level DBA would have all of the necessary skills. So, where does one go to get that experience?

Well, I actually talk about that in chapters 1 and 8 of the book, DBA Survivor. I discuss how you can get yourself prepared to find a job as a DBA and where to find the necessary additional training. Face it, companies are always going to ask for everything under the Sun when they post a job listing for a DBA. You will need to first build up those skills and then keep those skills sharp if you are to position yourself to land that job. My book can help you to understand what steps you need to take in order to make it all happen.

Looks like I had an excerpt from my book published over at CTOEdge.

The excerpt includes my “shards of broken glass comment” with regards to merge replication. The exact context is as follows:

“I would rather eat shards of broken glass than implement merge replication, but that’s just me. Some people make a great living eating broken glass at carnivals. You should choose your own path in life.”

Yeah, the book *was* fun to write.

About a year ago I blogged on how I thought Chris Hansen would make a great DBA. A few people said they liked that blog post and I loved the idea of getting Chris Hansen involved but he has yet to return my phone calls, emails, or telepathic messages.

Anyway, as I was assembling materials for the book, it occurred to me that Chris would be best suited to handling code reviews for any IT organization on the planet. So I included it in the book, inside of Chapter Four, “A Development Server is a Production Server to a Developer“, and here is the excerpt:

Chris Hansen and Code Reviews

Good code reviews are a necessary evil. They should be performed at regular intervals, perhaps at a project milestone or tollgate. Code reviews are a time for you to explain to your peers your thought process as well as receive feedback on your code and design. The end result is better code, which results in a more stable system, which results in less production support issues. So why are most companies not bothering to do code reviews?

Because everyone dreads code reviews.

Most people are not good at presenting, and on top of not being good they know they are not good and that makes them even worse. Some people could be good, but get nervous when talking in front of a group of their peers. And those that are having their code reviewed feel as if they are being interrogated by Chris Hansen from “To Catch a Predator”. It all adds up to some of the most dreadful assemblies of employees you could ever hope to imagine.

So, we know code reviews are important, right? And we know that everyone dreads them and as a result no one does them anymore, right? Now, I want you to imagine that Chris Hansen is leading the code review and you are the developer currently making your presentation. You get done explaining what you are doing, and Chris starts asking you some questions, such as…

CH: “Do you know how old DTS is? What were you thinking? And you were not going to batch your transactions? Do you know what that will do to your log file?”
You: “I swear man, it was just talk, that’s all it was. I wasn’t going to do anything. I came here to tell my DBA that we needed to go our separate ways.”
CH: “Just talk? It’s a lot of talk. I’ve got the transcript right here. You say here ‘I want to cursor through all your rows’. Man, that’s just wrong.”
You: “I know, I know. I’m getting help. The other day I bought a book on SQL 2008. And I am willing to do whatever I can to help you guys. Just tell me what you want me to do.”
CH: “Help us?”
You: “Yeah, with whatever.”
CH: “There’s the door. Go tell your friends we’re watching. And the next time they hand us deployment instructions that are more complicated than a NASA launch sequence we’re coming after them.”

Clearly you don’t want to have things go that far, but there are going to be times when you really want to call a developer out and ask them why they have their head up their ass. Stay calm, no one person knows everything, right? But also put yourself in their shoes. If every piece of code that you just spent weeks putting together was being picked apart you would be defensive, right? So it is natural to see the developer get defensive as well. In fact, it is natural for anyone to be somewhat defensive even if their code is not being picked apart.

Do your best to see this as an opportunity to teach something new. Not everyone wants a lesson, however, and for those people you need to remain calm and try your best to persuade them to see things from a different point of view. Find out their roadblock (why don’t they want to do something new) and help them get around it. Over time people will begin to trust your feedback rather than think you are always on the offensive.