I put a page together for this blog to help people understand how to find a good DBA.

I often hear people lamenting the fact that they cannot find a SQL Server expert. Many times this is a result of the people trying to find an expert by conducting a job search using standard methods (recruiters, online ads). The job description lists everything under the Sun as requirements and sometimes even list more than one job title (Sharepoint administration, Exchange administration, etc.), but those jobs rarely pay equivalent money. In short, employers want to find someone willing to do everything for less money than they are worth.

Guess what? You’re going to have a hard time finding those people.

I think part of the problem here is that most often a good DBA is nothing more than an appliance for most shops. Managers and IT directors have little understanding of the true value for a DBA so they are considered to be the equivalent of a toaster. They sit there and work on demand when you need them most. But for most of the day you don’t need them at all, but you know you want to keep them around for the next time.

If you want to find a SQL Server expert you need to stop thinking of them as a toaster. If you are serious about finding quality people to hire for your staff then you need to get out of your office and start meeting quality people that you would want to put on your staff.

Sitting in your office and posting ads for jobs or hiring recruiters is going to give you the same rate of success as if you were ordering a bride from Russia. It’s a crapshoot. Better you understand that now and start laying the groundwork to expand your network accordingly.

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.

Ever stop and wonder why everyone is always asking you questions about so many different Microsoft products? Besides the fact that as a DBA you are usually the smartest person in the room to begin with, chances are they think you are an expert in anything that has the letters ‘SQL’. Here is an excerpt from chapter four of my book, DBA Survivor.

SQL Server has a LOT of functionality inside. Have you ever noticed how many components have the letters ‘SQL’? Here’s a short list:

• SQL Server
• SQL Server Management Studio (SSMS)
• SQL Server Reporting Services (SSRS)
• SQL Server Integration Services (SSIS)
• SQL Server Analysis Services (SSAS)
• SQL Server Notification Services (SSNS)
• SQL Azure

And if it has the letters ‘SQL’ you can bet that someone will walk up to you at some point to ask you a question. And when you respond with “No, I do not know how to wrap a notification from SSNS into an SSIS package, build a report in SSRS, and then push everything to SQL Azure” you will get a blank stare and hear the words “But aren’t you the DBA?”

Tip: Remember, no one person knows everything.

The answer is “yes”. Yes we are the DBA, but that does not mean we know everything about each product that has the letters ‘SQL’. It’s the same reaction a developer has when I say “what do you mean you need me to restore the production database from yesterday down to test so that you can get a stored procedure? Don’t you have a copy of the stored procedure in your source control?”

[Getting Asked About SQL

Jonathan Gennick

What Tom says about the letters S, Q, and L is true. You really will get asked. A few years ago, I was approached about teaching a class on “SQL”. I don’t remember now whether it was someone who’d read my books and articles, or whether the person had simply heard that I was good at SQL. What I soon discovered though, was that the person wanted someone to teach a class not on SQL the query language, but on SQL Server the database management system. They are two different things, of course. Trust me. I am comfortable with SQL, but you do not want to see me teaching about SQL Server.]

Now that we have established that SQL Server has a lot of functionality you need to be aware that developers are going to ask you a lot of questions about various components that you have never used. That’s OK, do not panic, the developers are doing their job well and are researching different ways to complete a particular task.

With all the functionality the SQL has to offer, developers are not only going to ask you to help them to make something work, but they are going to also expect that you can help explain why something works in a particular way. It could very well be the case that a particular component of SQL is working in a way that is contrary to what everyone expects. Of course you will be expected to provide an answer for the behavior; the answer had better be found fast, and the answer better come with a solution that does not require the developer to undo months of coding. If it does then that same developer is going to ask for you to take out a hammer and make the square peg fit into the round hole.

If such a situation comes up you should do your best to offer the developers a handful of alternative solutions. The last thing anyone wants is for some band-aid solution to make its way to production. Too many times I have seen poorly designed systems deployed to production simply because a developer did not want to admit that perhaps they could have done things in a way that did not cause a slow memory leak and subsequent server reboots once a week.

Usually when that happens they do their best to shrug their shoulder and tell you to ask Microsoft for a patch to fix the problem. After all, they don’t have time to fix things right because they are under pressure to finish some other project.

I received a wonderful email last week regarding the book, and I wanted to share an excerpt with everyone:

“Hello Thomas,

I just wanted to let you know that I just finished reading your book and I was truly inspired to become a better DBA. This book will be the first book I recommend to staff who has the desire to become a DBA but wasn’t sure exactly what a DBA did for a living.   It was so much fun to read and thank you for NOT writing those dry technical books that are really boring to read.

I posted a review on Amazon and I hope you much success in the future.

Thank you again. ”

A few weeks ago I asked my editor if he was happy with the way the book was being received. His reply was simple:

“…every time I read the reviews Tom, every time I read the reviews.”

And that sums it up for me as well. Every time I get an email from someone I have never met and they thank me for writing the book it makes my day a little brighter.

Recently I was contacted by Matt Velic regarding my book. Matt wanted to write a review about the book and asked if I had any objection to his doing so. I was flattered that Matt would want to write a review…actually I was amazed that he had even heard of the book. And after reading the review I was happy to hear that my words were able to help yet another DBA out there, somewhere.

For those of you that don’t know, Matt is one of the lucky winners for the upcoming SQL Cruise. You can watch his video entry here:

I had never thought about organizations such as Matt’s that does such great work helping other people. To think that my book helped Matt, who in turn helps millions of people each day, is a little overwhelming at times.

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.