| DBA Survivor |
| How to be a Rockstar DBA |
Saw this blog post today and wanted to share it here.
http://www.mikefal.net/2012/01/03/dba-survivor-learning-how-to-rock-out-with-databases/
I’m always touched when someone tells me that my words have had such a positive impact.
Thanks Mike.
If you could give just one thing to a person you know is starting out as a DBA, what would it be?
Well, my book, of course.
And as luck would have it, Apress is offering a 40% sale until Christmas, use the code SNOW11 at the checkout. I bet if you ordered it today you would still have time to give it as a gift.
http://www.apress.com/9781430227878
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.
The best DBAs don’t care about being liked.
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.
You’ve spent weeks or months building out your monitoring solution. When it is up and running for the first time you are excited because you get alerts. These alerts allow you to be proactive, and to fix problems before your customers know the problems exist.
Soon enough the volume of alerts increases, like a tidal surge. You don’t notice the increase right away, but it is there. There are two things that will happen next:
If you are at this point then take a moment to go back and evaluate the value of the alert itself. If you cannot take action, do you really need an email to be sent? If you are filing them for later (perhaps creating a paper trail), do you really need that in an email?
This is the point where the alert you create, something with enormous value originally, no longer holds any value.
Just turn them off. I bet you will find less stress and feel more productive at the end of the day.
As a DBA, you need to be able to help educate developers with regards to good database practices. But this is only useful if the developer has an open mind to new things. I recall one time when I pointed out that a cursor was not the best solution for a particular update process and was met with the response “How do you expect me to do row-by-row processing without using a cursor?”
Being open is key to moving forward as a database professional. But this is a two way street. For all the times we desire to have a developer present an open mind, we also need to ask ourselves if we are being open.
How do you react if a developer wants to try something new? What about if the server team needs to change something? Are you being open with them?
Never forget to treat others the way you want to be treated. If you are open with others, you will find that they will be open with you.
Recently there was an outage with one of the major Cloud providers, Amazon Web Services (AWS). My company uses Get Satisfaction, which was hit by the outage. We got an email apologizing for the interrupted service along with a promise to “get under the hood” to understand more about how this can be avoided in the future. When I read that my first thought was “why didn’t you already understand what was going on under the hood?”
Now, compare that to the email I got from Netflix regarding the AWS outage. Wait a minute…I didn’t get an email? Is that because they didn’t feel the need to send me one? No, it’s because they didn’t have any downtime as a result of the AWS outage. And the reason why is because they already knew what was going on under the hood.
I am a big advocate of the Cloud, I really am. But I a bigger advocate for knowing more about what I am building, and understanding what it means to have a single point of failure.
I want you to do the same. Just ask yourself a simple question: “what if?” Try it. Go ahead and say “what if this server fails”, and run through the different scenarios. If your company is providing a service that requires uptime make certain you have the right solution in place, and not just the promise of the right solution.
