Recently I was contacted by someone who wanted to thank me for writing my book DBA Survivor. They had been hired as a full time DBA and were re-reading Chapter 2 (“Now What Do I Do”). They were thankful that someone had taken the time to explain how much a DBA has in common with the President of the United States:
“Do you really have anything in common with the President? Yes. More than you probably realize. First, about half of the people around you doubt whether you are qualified to actually hold the job you have been given. Second, every time you make a decision or plot a course of action you will constantly be criticized even by your supporters. And third you are going to be judged by what you accomplish in your first one hundred days, good or bad, even if it was something not in your control.
Every four years we elect a new President, and the person in office is always subject to approval ratings. You will have your own version of this fact of life; it is called your annual performance review. Come review time, you want your approvals ratings to be as high as possible.
Sound awful? Perhaps, but it really is not all that bad as long as you are aware of these things when you start. The most important objective for you is your plan of action for when you first arrive. If you think you can show up, grab a cup of coffee, and ease into your new position then you are mistaken. Your cup of coffee can wait until after you start gathering the information you need in order to do your new job effectively.
And what information is that? How about some of the basics first, such as: what servers are you responsible for? What applications are you expected to support? What time of day are the applications used? Who are your customers? Are the databases being backed up properly right now? How would you know if the backups were failing? With so many items to check, it can become very overwhelming, very fast. That is why you need to put together a checklist of the bare essentials and get started. Then, after you are able to get a handle on your environment you can start making some short term plans for improvements. Before you know it your first one hundred days will be behind you and you will be able to look back and see just how far you have come in a short amount of time.
Trust me, it is easier than it sounds, you just need to be organized.“
That chapter goes on to explain how to put together your initial checklist, how to gather details on your environment, the groups you need to meet with, how to manage alerts, how to become more proactive, and how to track your progress.
I am often sought out for advice on being a DBA, or getting into a job role that involves data. The post gives a rough idea about the variety that exists. It also points out the shift I have seen over the past 15 years in IT.
There used to be a time that every company had their own group of developers or systems teams that were responsible for creating, updating, and maintaining existing code. Over the past 15 years a lot of those systems have been replaced with third party software. You know, vendor applications that come pre-package and as a DBA you are asked (or told) to “make it work”.
With the purchase of that software there wasn’t as much of a need to have your own developers. Lots of those jobs were lost. But they were replaced by folks that knew how to move data, how to integrate systems together. In my post I call them the Manufacturer, but they are also the DBA.
So, fewer designers and developers perhaps, but an increase in Manufacturing, which includes ETL, reporting, and business analytics.
This video is an hour-long but well worth sharing with you today. One of the main takeaways from this video I want you to have is the fact that troubleshooting performance is not always rocket surgery. When you watch this video and listen to Conor Cunningham talk about some of the real world examples he has faced you will see what I mean.
I also liked how they help you to understand the concept of how to “bucketize” performance issues. It goes something like this:
Are all queries affected, or just a subset of queries affected?
If all queries are having performance issues then you will want to examine settings that affect the entire instance, such as memory settings, or high CPU utilization. You will want to do this first before trying to examine any one particular query.
If it is only a subset of queries (or users, or a particular application) then you will want to focus your efforts on those queries first. Otherwise you will be wasting time trying to fix one query without addressing the root cause of the performance issue affecting all queries. [A great example of this for my customers has to do with virtualization: why waste time trying to tune one query when the reason for the slowness is because your memory settings have been dynamically changed? Better to spend five minutes talking to your server admins about the memory for your guest than to waste time trying to get a query to suddenly run faster with less memory available.]
Just being able to diagnose “all versus some” in the first five minutes of triage in a production down situation can save you a lot of time as you begin to form your action plan to correct problem and bring performance back to within acceptable limits. Set aside some time this week to watch this video and learn more.
And thanks to everyone that has contacted me in 2011 with so many kind words regarding the book. I’m touched to know that my words have been able to help others get a leg up on a career that is often shrouded in mystery.
How often do you use a performance monitor? No, not that performance monitor, I am talking about someone you trust to give you thoughtful advice on your career as a DBA.
Most DBAs have their performance review given by someone that has little to no understanding of what it means to be a DBA. We are often given career advice that has little to nothing to do with our career goals, because the manager hasn’t bothered to take the time to ask you what it is you want to accomplish in your career. Most managers not only have little value when it comes to career advice but they offer little value when it comes to motivating the people that work underneath them.
So, who do you turn to? I hope the answer is a mentor. If you don’t have a mentor, go get one. Find someone that knows what it is like to be a DBA and can offer you some advice. Most likely this will be someone outside your office, but sometimes you can get lucky and find a coworker to fill this role.
Just go get one, and soon. You’ll find yourself in a better place.
It seems that benchmarking is a lost art these days. People tend to expect a query to return results in three seconds or less, no matter how much data they are asking to be returned (or processed).
Such results are required no matter where the end user happens to be. They could be in the server room, at their desk, at home, or using their iPad on a train. It doesn’t matter, the user experience must remain constant.
And as a DBA, you are going to be responsible for performance. It will be on your shoulders should any one user have a bad experience. People tend to blame what they don’t understand, and more and more people have no idea how databases work.
We’ve all heard about how it is important to know the right time to say “no” to some request. What we don’t often hear about is the how to say no.
Email is a great way to say yes to something, or someone. And it is a lousy way to say ‘no’.
If you get an email asking for something from you, and you need to say ‘no’, it is best for you to get up out of your cube and say ‘no’ to someone face-to-face. If you can’t see them in person, then pick up a phone.
Stop using email to say ‘no’ and start using other inter-personal skills to communicate effectively.
Which would you prefer? Most people would prefer to be liked rather than right. Most DBAs I know would rather be right and could care less about being liked.
It is a delicate balance, however, and one you come across as a DBA frequently. This is especially true when you have built up a good relationship with coworkers and one of them suddenly needs a “favor”. It doesn’t have to be anything serious, but how you handle the request will say a lot about whether you want to be right or liked.
If the favor requires a process to be followed and you point your colleague to the proper process then you don’t care about being liked. If you circumvent the process to take care of the favor then you don’t care about being right.
Not everything is as black and white as I presented here, but you get the idea (I hope). There are times when you need to make this choice.
Most DBAs are towards the bottom of any organizational chart. And yet our role and function is no less important than anyone else, and in many cases I would argue even more important than most. We guard data, we keep things running smoothly as possible, and we are there to recover in the event of a disaster.
But make no mistake we *are* at the bottom. And we all know what flows downhill: everything does. We often have to prioritize how we handle tasks simply by whoever is yelling the loudest.
This is not the way we want to function. And make no mistake that such an environment leads to a higher rate of turnover, which leads to comments such as “We have had trouble finding a good DBA.”
Good DBAs are all around you. People who treat DBAs with respect are in a far greater shortage.