Art of the DBA Rotating Header Image

career

Preparing for 2012 (part 3)

Dec 20th, 2011
by Mike Fal.
1 comment

If you missed the earlier installments, check out part 1 and/or part 2.

Getting Proactive

SQL Server is a large product and it’s getting bigger every day. Within it we have engine performance, query tuning, encryption, disaster recovery, report writing, data analysis, ETL processing…the list is a lot like the Energizer Bunny in how long it is. Trying to know all of that is pretty much impossible, so the database administrators who truly excel in the field become experts on a certain area of SQL Server and rely on their SQL family to help with the areas they may not know so well.

It’s hard to do, because in our jobs we’re usually only one of a couple folks who do what we’re do and we are expected to handle whatever gets thrown at us. I typically have to touch 4-5 distinctly different areas of our discipline just to fight the fires of the day. Like all fires, they need to be solved quickly. I can’t spend a lot of focused time learning about those different areas, because the system can’t be down or running slowly.

This, of course, ends up being a very reactive approach to learning. We only learn what we need in order to solve the problem at hand, then move on to the next one. Even then, we usually don’t learn much, just copy a script or grab a job, verify that it won’t break anything, then implement and get going. It’s continually preached (rightfully so!) that managing our databases in a reactive fashion is a recipe for disasters, all-nighters, and RGE’s, why do we think it would be any different with our education?

The challenge to myself is to stop being reactive in my learning. While it’s cool to be like a sponge in a sink, soaking up whatever is available, I’m only able to scratch the surface of whatever happens to be the topic du jour. To do that I need to take a discipline within SQL Server, focus on it, and make it my own.

Focus, Daniel-san!

Unfortunately, there’s no crane kick or leg sweep that is the magic key to my DBA success. Any number of areas would be valuable, I just have to pick one. My decision, which really only came to me in the last month, is to focus on SQL Server monitoring. The reasons are simple:

  1. In order to have the most stable environment, you need to know what’s going on in your environment. To do this, you need established baselines and systems to monitor your environment.
  2. To stop problems before they become serious, you need to have systems in place to watch for issues and deviance in your operations.
  3. You can’t start corrective action, such as adding hardware resources or query tuning, without first understanding the problem. Proper monitoring will give you the signposts to indicate what your problem is.
  4. If you want to impress the boss, the easiest way is to create reports and display the data on your environment and how it is changing. While I tend to think that doing your job well is the best way to impress the boss, your boss may not always understand how good of a job your doing unless you show him the data.

Over the next year, much of this blog will be about researching and implementing monitoring. It will include planning elements such as service level agreements (SLAs), third party monitoring tools, and reporting queries, along with other items as I come across them. Hopefully it will become more than just my brain dump area, but it might not. Either way, you should be able to follow along with the solutions and methodologies I develop and learn along with me.

Look out 2012, it’s gonna be a wild ride!

Planning for success in 2012 (part 2)

Dec 15th, 2011
by Mike Fal.
No comments yet

If you missed part 1, you can head over here.

Speaking

In 2011, I jumped in to the presentation gig with both feet and found that I really liked it. If you’re an avid blog reader, you’ve probably heard the benefits of presentations ad infinitum. So instead of talking about those, let’s talk about why I like them so much.

First off, it’s a chance for me to study up on something I find really cool. I find databases and some of the topics in SQL Server to be really neat, most likely because I’m a geek. It’s stuff I want to learn about anyway, but since there’s a definite end point (giving the presentation), it helps me put some structure around learning an aspect of SQL Server.

Secondly, I like to talk. I’ve actually been offered criticism that I talk to much, but I figure that’s something I can work on and it’s easier to overcome chattiness than a reluctance to speak. And it’s more than just talking towards an audience in a presentation, I’ve found the best experiences I’ve had giving presentations are when there’s a good Q & A period at the end of a presentation.

Thirdly, people are genuinely appreciative of my efforts. I’ve written and talked at great length about how giving the SQL Community is, but one of the reasons it is so giving is because it’s also very thankful for the knowledge we share. I’ve received numerous compliments and “thank yous” for the sessions I’ve done, which really makes me feel good about the work I’ve been doing.

I want to continue speaking, so for the upcoming year, my second set of goals will be focused on presenting, with the following specifics:

  • Speak at 4 SQL Saturdays. Now, I’ve already got a jump on this because I’ll be speaking at SQL Saturday #104 in Colorado Springs, giving a new presentation on SQL Server partitioning.
  • Speak at SQL Rally – Dallas. Granted, this means I have to be selected, but I will be at least trying. I will submit my sessions by the end of the month and cross my fingers.

No, submitting for the PASS Summit this year is not one of my goals. I still might, but I’ll let that unfold. There’s some other items in the works, plus the nice thing about going to an event where you’re not a speaker means you can just be at the event. That’s what I liked about the 2011 summit, is I was able to experience it without worrying about obligations.

4-5 speaking engagements for the year may not seem much, but I’m finding out that speaking at user groups and SQL Saturdays can quickly beget other opportunities. By setting this goal, I establish a bar for myself, but also plenty of room on my plate for other things. In fact, I actually already have a couple things lined up already that I’m very excited about and will talk more about soon. But while I want goals that push me, I don’t want to overload myself and burn out.

Stay tuned, one more goals post coming soon!

P.S. If you can make it, we’d love to see you at SQL Saturday #104. I’ll be giving this presentation:

Eating the Elephant: SQL Server Table Partitioning – Is your table fat? Do you need to manage a table that has billions of rows within it and are overwhelmed by index rebuilds that take more than 12 hours? SQL Server’s table partitioning gives the DBA the tools to manage this beast and support very large tables in a way where index management and data retrieval does not become unwieldy. This presentation will take you step by step through choosing an appropriate partitioning key, setting up the partitioning on the table, and finally maintaining the partitions.

It will be a great time and an awesome way to kick off your SQL career in 2012!

Getting ready for 2012 (the year, not the version)

Dec 13th, 2011
by Mike Fal.
No comments yet

So with the new year just around the corner, I wanted to take a bit to take what I have gotten out of 2011 and use it to figure out where I’m going in 2012. While not to bore you with the details, 2011 was an explosion of career development, with the following highlights:

  • Regular user group attendance
  • Blogging (if somewhat ireggularly)
  • 6 Presentations given (3 at local user group meetings, 2 at SQL Saturdays, 1 internal)
  • Attending the PASS Summit
  • New job!

This has been good stuff and very fulfilling, but it’s felt a little about throwing spaghetti at the wall and seeing what sticks. While that works for a bit, it can wear you out quickly, so now it’s time for me to sit down and refine my focus a little more. After giving it some thought, I’ve found three general things (for lack of a better description) that I want to emphasize in the next year to drive my career even more than what I’ve done in the past year. I’m going to break these posts up over the next two weeks so that I’m not writing a novel, but I’m really excited about this next phase of my career that the new year will bring.

 Adjectives

When I went to the Summit, I sat in on a session with some “big names” talking about becoming a linchpin at your job. There was lots of great material out of the session, but the thing that really kind of stuck with me was something Kevin Kline talked about, and that’s what adjectives you want to be used when others talk about you. I’ve been thinking about this ever since, trying to decide what I want those to be. It’s hard, because we want to be all sorts of great things, but the cliché holds true: You can’t be all things to all people.

So now that I’ve had almost two months to think about it, I’ve come up with four words that describe want I want to be. Some of these already describe me, but some I need to work on. But in no particular order:

  • Smart – This is the easy one and something we all want to be. However, this just isn’t about knowing stuff, but also about knowing how to do stuff. A comment I’ve heard about me at work is that if someone comes to me with a problem and I don’t know it, I know how to get the answer. People know they can rely on me to answer their questions and help them with their problems.
  • Creative – It’s one thing to know stuff, it’s another thing to do something with it. Sure, we can all create log backups, design replication strategies, or performance tune queries, but not everything fits in the magic flowchart of all answers. Almost every company does something different, and as data professionals our challenge is to take the various bits of knowledge we have and craft them into elegant, repeatable solutions.
  • Reliable – I want my co-workers and customers to know that they can depend on me. This is a little different than being the go-to-guy or “Mr. Fixit”, as I don’t want to be the superhero that people always look for to save them from their data problems. As Tom LaRock describes in his book, I want to be Mr. Right, not Mr. Right Now. (If this doesn’t make sense, read his book. Really.)
  • Professional – This is one that I feel like I struggle with. I want to improve how the people around me see me from a professional sense. For many years, I was that guy who just wanted to sit at his desk and write code, to be left alone by the outside world. That’s a very career limiting goal, honestly. If you dress and act like you want to be left alone and not noticed, you will be left alone and not noticed. I do want my managers to notice me, I want my coworkers and customers to respect me, I want to rise above. This quantifies into a lot of little things, like dressing a little nicer, making sure I show up to meetings on time, taking on some additional projects.

These adjectives, more or less, form the core principles for my career. No matter what, this is who I want to be. Everything else in my career will build on this, and while I’ll be far from the perfect DBA, those around me will know what the can expect from me and what kind of resource I will be.

Watch for part two in a couple of days!

Performing your presentation

Sep 27th, 2011
by Mike Fal.
No comments yet

If I asked you when was the last time you went to an awesome rock show or movie, I’m betting that not only do you remember the day, but probably also remember how excited you got. Maybe it was Rush, getting you to move to the beat and sing along with the lyrics, or Captain America, cheering while he took on the Red Skull. I’m sure we all can think back to some artist that got us excited about their art because they put their heart and soul into their performance. Now what if I told you that giving a presentation isn’t really that much different?

For those unaware, I am a musician as well as a database administrator. I studied Bass Trombone performance at the University of Colorado at Boulder and have played in several jazz bands, orchestras, and chamber groups over the years. Sometimes it was a large gathering, other times we probably could have taken the audience in a fight. Every one of these was great, though, because of the rush I got playing music for people and sharing with them some of what I felt when I got to play.

Recently I’ve started doing SQL presentations, trying to build that professional development thing. I’ve enjoyed it and had a reasonable amount of success(well, no one’s thrown rotten fruit at me yet), but it struck me how similar giving a presentation is to a musical performance. I’ve found that just live I’ve tried to share the excitement I feel about music with an people who come to listen to me, when I give a presentation I’ve got the chance to share with people something that I found within SQL Server that’s cool and fun (in a geeky sort of way).

If you look at presentations you have given, I’m sure you can think of the parallels of preparation and practice, both of which take so much of a musicians time. The time spent building slide decks, researching minutiae, and talking in front of a mirror with a stop watch are so very much like a musician studying a score, practicing etudes, and doing breathing exercises. Most of an artist’s life is spent getting ready for that performance. It’s often lost in the mix is done on stage that really brings a song or a show to life.

I want you to think about that last great rock show or movie you went to. You know, the one that had you dancing in the crowd, cheering the hero, or singing along with the band. Musicians find ways to reach out and involve the crowd, so that their audience doesn’t just feel like they’re listening to a show, but that they’re actually a part of it. This is where the magic is, and if you can capture that in your presentation, your success will soar.

“But Mike!” you say, “We’re just talking about the dull stuff. No one’s going to bob their head to query plans, right?” Untrue. After all, the reason we work in this industry, that we participate in the community, and that we present to groups because it’s fun and gets us excited. The folks coming out to these events share that excitement, we just need to tap into that as presenters. It’s this magic quality that I’ve been working on in my own presentation style, so I canengage my audience and break down the wall between me and the people sitting in the room. It’s not easy and I know that there’s a lot that I can still learn here, but these are some of the things I’m trying to do:

  • Lighten the mood. Sure, we’re seeing a lot of dry stuff with databases, but find ways to make it fun. It could be humor or handing out candy for good questions, but try to loosen people up.
  • Get the dialog going. We always expect the audience to ask questions, so it’s uncomfortable when they look at you stone-faced. Typically, people aren’t asking questions because they’re afraid to be the first one. Get past that by asking the audience questions. Once your group realizes that this is a two way conversation, questions will start flowing.
  • Don’t be afraid. After all, people have come to the presentation to hear you. And they’ve come to hear you because they are interested in your topic and you do know what you’re talking about. If you have that confidence, it will project through and engage your audience.

Presenting really is another performing art, and I think if you approach it like an artistic performance, not only will your abilities as a presenter grow, but it will be more fun to boot. It’s hard for me to really put in to words the rush I’ve felt after a great performance, like when I played the Pines of Rome or Count Bubba, but it’s a feeling that can’t be beat. That’s what’s great about presenting, is I have gotten the same rush getting up on stage in front of PASS user’s group. So while most of us can’t shred like Satriani or sing like Tori, we all have the ability to share our passion for SQL Server with people who are just as fired up to learn about it. Revel in that, it’s a feeling to few people get to have.

Dumb Questions

Apr 1st, 2011
by Mike Fal.
No comments yet
“Can I ask a dumb question?”

Anyone who works with me for a short period of time will hear this tumble out of my mouth.  I can’t tell you the number of times someone launches into a 5-10 minute explanation of a really cool concept and giving me that “I have a cunning plan” look when they finish.  However, because I didn’t have that one thing in my head they figured was obvious, I end up having to ask a couple questions to get myself on the same page.  It’s never a big deal to fill in those gaps and the opposite party is usually happy to provide the context, but I do have to ask those questions.

Assumption: The Mother of all Screwups

The problem is with assumptions.  Whenever we communicate with each other, we have to make an assumption about what the other person knows.  Unfortunately, a lot of times those assumptions are wrong.  Remember the ill-fated Mars orbiter where there was a mixup between the imperial and metric measurement systems?  While we all smack our forehead and say “D’OH”, it’s pretty obvious that this is the result of one side making assumptions about the other side’s knowledge.  If someone had questioned the basic assumptions of both sides, they might have saved that $125 million orbiter, but instead, the two teams ran off on different tracks because they didn’t want to appear dumb.  (How how do they look now, right?)

I know we all get frustrated when the Level 1 support tech asks us if our network cable is plugged in or that we haven’t kicked out the power cable, but these are exactly the kind of questions we need to ask when troubleshooting database problems or building requirements for a project.  The reason for this is because asking the dumb questions helps establish a baseline starting point for figuring out the problem.  After all, when someone comes to us saying “the system is slow”, we don’t want to bash our heads with IO stats or memory pressure when all we had to do was deal with one blocking query.  We wouldn’t know about that unless we asked the right questions to start our troubleshooting.

So tell me a little about yourself

The best approach is to dealing with this is to teach yourself to reduce the number of assumptions you make.  Easier said than done, right?  What really helped me was an exercise a former boss/mentor had me do early on in my career.  It’s pretty simple:  In one paragraph (no real limit on sentences or words), describe your work to someone who has no idea what you do.

Seems easy at first, but think about it for a second.  Let’s break down the following sentence that I might use:
“I administer and maintain SQL Server databases.”

Already in this sentence we have several assumptions about the listener.  First, that they know what a database is, and they know what maintenance and administration is for SQL Server.  Chances are most folks don’t, so we would then have to explain those terms to them in a way they would understand.  We don’t need to get overly complex, but provide the listener a basic grasp of what we’re talking about.

The end result is that this exercise puts us in the mindset of someone who may not have the same knowledge or experience as we have, thus getting us to restructure our thinking and presentation in a way that covers the entire context of whatever idea we’re presenting.  It also gets us to start evaluating our assumptions based on our audience.  We’re always going to make assumptions, but what we want to do is make them in the context of our audience.  Speaking to a group of DBAs?  Yeah, leave out that stuff about relational theory.  Talking with IT infrastructure dudes?  Chat with them a bit about database file layouts and managing I/O contention.  Oh, monkeys from Kenya?  Throw ’em a couple of bananas.

Duh!

So whether we’re asking ourselves or someone talking to us, it’s always good to get those assumptions straight.  Sure, we all pride ourselves on figuring things out.   That’s why we’re in this business, for the joy of solving that process that no one else could.  But it never helps us when we get lost on that wild goose chase because we made the wrong assumption.  Save yourself some time and a lot of headache, make sure you’re on the same page with those you work with, and ask some “dumb” questions.  It never hurts.

Newer Posts →