Art of the DBA Rotating Header Image

Musings

2013 in review, 2014 in anticipation

As is my custom, I want to blog about what I did last year and my goals for the upcoming year.  Since I have more “regular” stuff to blog about, I figured I’d sneak this in on a Friday just to get it up here.  :)  The primary reason I do this is that which gets measured, gets done (hat tip Buck Woody).  2013 was a pretty eventful year, but I didn’t quite get everything I had wanted to.  So let’s look back at…

2013

Speaking – Did pretty well here.  I met all my goals as well as actually speaking at the 2013 Summit.  I love presenting and now it’s a matter of building new presentations.

Blogging  – Not quite an epic fail, but this one was not a passing grade.  I basically blogged regularly through to about March, then fell back to my sporadic pace.  I didn’t even blog for about 3 months over the summer.  I’m very disappointed with myself and can do better here.

Certification – This was a success and was a lot easier than I had anticipated.  I sat down to take four of the five exams cold to evaluate where I stood and ended up passing them.  The one I had to study for (and I knew this going in) was the Data Warehousing exam (70-463).  Pretty happy here, but now it’s a matter of finding other options for certification.

I know a lot of folks have a dim view of certs.  I agree with the premise, that the exams and certifications (mostly) are no substitute for real world experience.  The fact that they can be crammed for removes some of the validity.  But at the same time, I think that they can be a valuable barometer for someone’s knowledge.  I fall in Glenn Berry’s camp here, that certifications are like extra credit.  If I see a cert on a resume, I won’t assume knowledge of the subject matter, but it at least shows me the candidate was willing to make an extra effort to improve themselves.

Secret Project – Ok, this more or less flopped.  Basically, I wanted to either write a book or build a pre-con for database monitoring because I feel there’s a real gap out there.  These are still on my slate of things I want to do, but I did not get that done in 2013.  Boo me.

And that was 2013.  I’d give myself a B for the year, mostly because while I whiffed on some of my goals, I also managed to go beyond on a few things.  In addition, I’ve made some career choices and moved things in that direction.  Which now brings me to….

2014

Several of the goals will be maintenance or the same.  I want to maintain on the presenting, so we’re looking at at least 4 SQL Saturdays and a Summit submission.  Blogging needs to be once a week.  This is a real stretch goal, because it’s harder than it looks, but I need to strive for it.  These two items are the base foundation my career grows from, so I need to keep that foundation healthy.

New stuff for 2014 will be:

  • I’m trying to move my career more towards being a data architect.  So for that goal, I will write more posts on general data concepts and higher level planning.  There will still be plenty of administrative stuff, but I need to broaden my blogging scope.

  • I also need to start reading more on cloud computing, modelling, and larger design concepts.  Right now I’m reading Domain Driven Design and my goal is to read 1 book a month on a related topic.

  • I will identify and start working towards a new certification path for design and architecture.  Not sure what this is, but I’ll have something identified by the end of March and start working on it the rest of the year.

2013 was a year of change in my life.  Not earth shattering change, not seismic shifts, but a definite redirection in my aims.  2014 will be solidifying my plan and starting down that path.  My biggest challenge will be sorting out the things that are new and uncomfortable from those that are the wrong direction.  The question I will continue to ask is “Does this move me in the direction I want to go?”.

 

T-SQL Tuesday #41: The Hook #tsql2sday

Bob Pusateri(@SQLBob) is this month’s host for T-SQL Tuesday with a topic I definitely can relate to.  Bob asks bloggers to talk on their presenting experiences:  how they got introduced to it and why do they keep doing it.  Since I’m right on the heels of giving my Server Core talk at SQL Saturday 197, it’s perfect timing.

To put my presentation experiences in context, let’s first talk a bit about some of my performance philosophy.  I’ve written about my musical background before and how it relates to giving technical talks.  One of my chief theories of performance (and art, for that matter) is the requirement of an audience, that art is not really art until you have an audience to appreciate it.  It’s all well and good for me to practice and play by myself, honing my skills and rehearsing pieces, but none of this becomes music until there are people to listen to it and hear my message.  Art is about communicating with that audience, sharing something of yourself through your performance.

This is a philosophy that directly translates to the presentations we give in the SQL community.  The main driver is for us to share our technical knowledge with our peers, to create and education conversation with those who do what we do.  For many, it’s intimidating to present when you think you have nothing to share.  When we realize that we can teach our audience something new, it’s an epiphany of what our impact can really be. This was exactly the “hook” that got me into presenting.

It was March 2011.  I had recently read Brent Ozar’s (@BrentO) landmark post: Rockstars, Normal People, and You.  I wasn’t sure about presenting, but I’d figure I’d give it a bash, so I reached out to the Denver User Group to see if I could sneak in for a slot.  After initially being told that my first chance would probably be something in the summer, I got a call from the VP of Events to see if I could give a short talk for the March meeting.  Apparently, the regularly scheduled speaker had to cancel and the group needed someone to fill in on short notice.

I had about two weeks.  In retrospect, that is a TON of time, but as a new speaker I felt like I was cramming last minute for an exam.  I put together a short presentation on database security, built around this cool extended stored procedure I found: xp_logininfo.  The night of the meeting came along and I went to the podium to warm up the room for Doug Lane(@thedouglane) with my “dinky, little presentation” .  The 30 minutes flew by, I think partly because of my nerves and I talked quickly, but everything went fine.  My demos worked, no one laughed at me, and my biggest sin was not speaking up so the back of the room could hear me.

Then came the “hook”.  As I was packing up for the evening, Tom Norman(@ArmorDBA) came over to talk with me.  Tom’s been a regular at the user group for a while who has given his own share of presentations.  To this day, I remember what he said:

“I’ve been a DBA for over twenty years.  You taught me something new tonight.”

Needless to say I was flattered, but it took a couple days to sink in.  When it did, it hit me: these were people that benefited from my performance, an audience that enjoyed my performance.  I was able to take my technical knowledge and mold it into something more.  Two years later and I’m a regular speaker in the mountain west area as well as VP of Events for the Denver group.  I’ve had the opportunity to speak at SQL Rally and many other SQL Pass events.  Presenting has been so much fun and it’s opened countless doors and started numerous friendships.

I want to thank Bob for giving speakers a chance to share their experiences.  My biggest hope is that we can encourage those who haven’t started speaking to do so.  If you’re reading these T-SQL Tuesday posts and you haven’t given a talk yet, go talk to your user group right now.  The SQL community is always looking for speakers and, whether you believe it or not, you have something I want you to teach me.

Getting Tooled

This week Tom LaRock(@sqlrockstar) tweeted a question, followed by a full on blog post and survey, asking folks if they installed client tools on their servers.  My answer was pretty blunt:

 

This got wrapped up in a larger discussion about whether or not installing client tools is appropriate, with some strong (and not necessarily wrong) opinions on either side.  I confess I didn’t get involved, mostly because I find it hard to have a serious discussion in 140 character snippets.  So now I’ll blog about it! 

I’m the kind of DBA that is a “jerk”.  I say no a lot and prefer, in production, not to take any more action than absolutely necessary until it’s proven that the action will do no harm.  I don’t get off on it nor do I enjoy giving people the hand.  I’m just…..careful.  We’ve all been burned and it’s my responsibility to make sure that we’re protecting the company’s assets, both data and the systems that data lives on. 

The problem with client tools is they can create avenues for danger.  For example, if I install SQL Server Management Studio and the Sysinternals tools, I’ve created a way for a local administrator on that server to log in to my SQL Server as an administrator, even if it wasn’t my intention to grant him that access.  This can be extremely useful (such as a situation where you do lose your SQL admin logins), but there’s inherent risk there.  Other tools can create similar risk, so my view is to try and reduce this risk by minimizing client tool installs. 

Another problem with client tool installs is that client tools take resources away from SQL Server (or other processes that the server is hosting up).  I know, I know…we live in an age where RAM and CPU are plentiful, but I still get protective of my stuff.  These are MY toys and, since I’m a jerk, I hate sharing.  By restricting client tool installs, I proactively prevent this sort of sharing and keep folks out of my sandbox. 

Thirdly, by putting client tools on to server, I provide a crutch for those who feel they have to do all their work directly on the server.  This is a bad practice, even if you have resources.  You’re not just taking stuff away from SQL, things you could also seriously damage something without even intending to.  Accidentally shut down the box?  Easy.  Delete or corrupt critical files?  Piece of cake.  I often think of working on the server as playin around in the middle of a minefield and why put a tool I need in the middle of that minefield?  If the tool isn’t installed, there’s no reason to log in to a server, so it doesn’t even become an issue.

This is one of many reasons I’m so high on Server 2012 Core.  By the very lack of its GUI, a lot of people will shy away from tools.  And the tools are there, but let’s be honest with each other here:  Most of us Windows folks love our dialog boxes and ‘Ok’ buttons, our drop ‘n drag paired with right clicking.  Command line interfaces are an anathema and we will avoid them as a preference.

 I get it, though.  There are plenty of valid reasons why you would install those tools.  It can speed up troubleshooting and there are certain things that can only be done from the machine itself.  Plus, if your box is secure, you can reduce the risk of having those tools out there.  I would argue that, even with the box secure, minimizing your client tool installs will reduce your risk even further.

I challenge folks to really, REALLY ask themselves: Do you really need use those client tools on the server?  In most cases, you probably don’t.  And if you don’t need to use them on the server, then why are you installing them in the first place?

Matters of Opinion

The common creed of I.T. and data professionals is “just make it work”.  Commonly we’re tasked with crazy problems, weird situations, and difficult challenges and we just get our heads down and get the work done.  It’s not often that we look up and plan beyond the current project or task.  We’re a cog in the machine, a smaller piece of a larger process, focused on getting the work done that we can control.

It’s a position we often struggle with.  How can someone come to you with a half-baked solution?  Something a user doesn’t fully understand even though they insist that “this must be the problem”?  I know I’ve been there, asking myself these questions while gnashing my teeth and shaking my fists at the sky.

Stepping up

The unfortunate truth is that these situations, like many other problems, are somewhat of our own making.  It’s a matter of trying to ride the proverbial tiger instead of trying to cage it.  The fact of the matter is that very few people, especially at a management level, understand database technologies the way we do.  If they do, it can make our lives a little easier, but typically we in the trenches will know more about the new features and limitations of our platforms.

How do we leverage this to our advantage?  By becoming thought leaders at our jobs.  Our management needs to plan to leverage new technologies and want answers about capabilities and options in order to find a way forward.  Do they go to the cloud? Should their databases be hosted on physical or virtual servers? How can we improve system response?  We can answer these questions, but can’t wait around for someone to ask us.

Resource of Record

How often do you talk to your managers about what you could do?  Information they’re looking for?  Opportunities for improvements that you can provide, either through current or new elements of your platform?  Our managers only know what they know, so we need to educate them by getting in front of them and sharing our knowledge with them.

So how?  If you’re one of the many professionals following the advice of Brent Ozar(@BrentO), you’re already well on your way.  Blogging?  Make sure your boss is reading your blog, so that he’s aware of what you know and are thinking.  Presentations?  Make sure your management is aware that you’re speaking on technical topics and what those topics are.  Building your personal brand is as important to your current job as your next.

You also need to have an opinion.  Sure, we live by a creed of “it depends”, but when someone asks as “how” or “why”, we should have a good answer for them.  Physical or virtual?  Cloud or on site?  Should this index be added?  As thought leaders, we need to provide more than just options, we need to provide answers and the knowledge to back those answers up.

Throughout my life, I’ve had this concept of “having the initiative”.  Basically, it means that I try to take control of situations, not letting them take control of me.   This is very much in that vein.  By advertising my knowledge to those around and above me and selling my expertise, I become the first stop for a question instead of a second or a third.  If you were the first stop, what would do that for you?

Looking Forward

Last time we met (ah, such a wonderful time), I did a once over of my accomplishments for 2012.  While I was pleased with the results, we must remember that career development is an ongoing process.  With 2012 in the review mirror, it’s time to put my 2013 goals to paper.

Speaking

I’m not going to lie, I really enjoy presenting.  It’s addictive and makes me think the tests are right(ENTJ, by the way).  I pushed myself to the edge on this last year by speaking at 5 SQL Saturdays, 2 Virtual Chapter meetings, a handful of user group meetings, and Rally.  This was a good stretch, so no reason not to match it.  In 2013, I will aim to:

  • Speak at 4 SQL Saturdays (and I’ve already got 3 on the books, which will be number 4???)
  • Submit to speak at the PASS Summit.
  • 3 chapter presentations (a mix of virtual and “meat-space”).

Note, I’m just submitting to Summit.  I have no illusions about this one, many people tried for years before they were accepted.  I need to get my foot in the water and start beefing up my presentations to Summit quality.  No, I won’t be doing Bob Ward(@bobwardms) or Adam Machanic(@adammachanic) level stuff, I’m quite happy in the 100-300 range, but I feel there’s a real need for that sort of stuff in the community and I plan to bring my A game.

Blogging

Ugh.  Blogging is what I struggle with.  Not that I don’t have things to write about or I dislike writing, it’s more that I dislike making time to write.  It feels like homework (and it is, after a fashion).  Blogging, however, is a GREAT way to get ideas out of your head and self-document your work.  To that point, I plan on:

  • Blogging once a week.  (ALWAYS commit to a regular schedule)
  • Continue to focus on automation and monitoring.
  • Blog about my server inventory and automated restore testing processes.

Certification

In general, I’m in the camp that certification doesn’t necessarily prove competency.  Many of the smartest people I know don’t have any certifications at all.  However, I agree with Glenn Berry(@glennalanberry) that self-acquired certifications (i.e., you didn’t go to a boot camp) show a willingness to go the extra step, much like community involvement.  Also, having them doesn’t hurt your resume, an overall net gain in almost any case.  My plan for 2013:

  • Get the Microsoft Certified Solutions Associate (MCSA) by June.
  • Get the Microsoft Certified Solutions Expert(MCSE): Data Platform by end of year.

Seeeeeeeeeeeekrit Project

Wow, how’s that for vague?  That’s intentional, as I don’t want to let the cat out of the bag, but I want to put this to paper to hold myself accountable.  Basically, I had a really cool idea at this year’s Summit and I really want to go for it.  Keep your eyes open for more on this throughout the year.

It’s Gonna Be HUGE

As you can see, I’m loading up on 2013 like a starving man at an all you can eat buffet.  It’s exciting and intimidating, but most of all, it’s achievable.  Nothing on this list is out of my reach.  Also, many of these things fold into one another, such as my presentations meshing with my blogging meshing with my seekrit project (ah HA!  Parallelization!).  I’m ready to take it all on, ‘cause it’s gonna be awesome!

A Look Back

The end of 2012 has arrived, despite the best efforts of the Mayan calendar.  It’s been quite a year for me, with a lot of ups and some downs, but overall pretty pleased with where I am regarding my career progress and community involvement.  For those of you who were around this time last year, I had laid out a series of goals for this year.  In order to keep myself honest, I thought it would be appropriate to hold myself to those goals.

Adjectives

My first goal was to get people to associate me with several adjectives.  For review, these adjectives are:

  • Smart
  • Creative
  • Reliable
  • Professional

Considering a lot of the comments I get from friends and colleagues, I’m pretty happy with my progress here.  I’ve had co-workers tell me that I’m looked to for creative approaches to solving problems, both using current and new aspects of SQL Server.  Many people, both in and out of my job, look to me for help and advice.

My biggest struggle, though, is still being “professional”.  I wear my emotions on my sleeve and sometimes that gets away from me, particularly when there’s friction between me and others I work with.  I need more focus in this area, but I also need to keep the other adjectives on my mind.  I’m on the right track here and need to keep moving forward.

Speaking

This is where I had my biggest accomplishments.  My goal was to speak at 4 SQL Saturdays and SQL Rally and, fortunately, I managed to do all that plus an additional SQL Saturday, several virtual chapter meetings, and a handful of user group presentations.  All of these went very well and I got plenty of great feedback.

What I’m most proud of was my SQL Rally presentation: Eating the Elephant – Understanding and Implementing SQL Server Partitioning.  I had a full room with 100+ people in attendance and got positive feedback from most of the audience (though I did get one guy saying he found a great place for a $3 Coke).  I was nervous right before I started, but once I was “on”, things went very smoothly.  I really want to thank folks out there in the community for their support, because without them I wouldn’t have gotten so far.  It can only go up from here.

Focus

I’ve only had moderate success with getting focused here.  Certainly, I have learned a lot more about automation and monitoring in SQL Server.  In reviewing my blog posts over the year, I’m definitely happy with what I’ve written on regarding this.  But I could have done more.  I think my biggest disappointment is how I didn’t blog nearly as much on this topic as I could have.  I have more ideas on my head and I need to be more disciplined about putting them to “paper”.

Summing it up

Self-evaluation is a huge part of personal growth.  We need to set measurable goals for ourselves and then periodically check where we are against those goals.  If I were to grade myself for 2012, I’d probably rate a B.  I should have blogged more, but made great progress with speaking and self-learning.  I have definitely have stretched myself professionally and feel positioned myself well to take things further.

This is an ongoing process, though.  Doing well in 2012 only means I need to stay on track and set goals for the next year.  There’s been a lot of thoughts floating around in my head over the past few weeks, trying to sort out what is both reasonable and measurable for 2013.  I should be ready to commit to those goals and share them with folks next week.

SQL Superstars

Michael Jordan.  Peyton Manning.  Joe Sakic.  Kobe Bryant.  Tom Brady. Andy Pettit.

Sports superstars. We watch them throughout the year, enjoying their athletic performances and last minute heroics.  Whether you love them or hate them, their abilities are amazing.  But there’s more than that.  We also watch as these special athletes also become a focus for their team, a linchpin for their team mates, a fulcrum upon which their organization’s efforts are leveraged.

I typically listen to the local sports talk radio on my way to work.  One day, the hosts were discussing superstar qualities, such as the ability to make plays and elevating the play of their team mates.  Since I was heading in to work, I started wondering how that translated to my job and if I was trying to bring these same superstar elements to the database court.  After all, I’ve always considered myself smart and able to handle any technical task in front of me, but being a true superstar is more than just being good, it’s also about being a leader and a force that drives the people around you to success.

I don’t think it’s quite that far of a leap from sports superstardom to the corporate world.  While we can’t do what these guys do (or get paid millions of dollars to do it), we can approach our jobs with the same mindset.  Here are some of the qualities that bounce around in my head and how the can be brought to our jobs:

  • Talent – Successful athletes all have some basic level of talent.  You don’t have to be the best, but you do need to be good.  I think all people in the technical field have this capacity, since we wrap our brains around some pretty involved concepts daily, so this is the easiest to attain.
  • Drive – It’s not enough to be ok.  It’s not enough to do the minimum.  Superstars are ambitious, want more, and strive to be the absolute best they can be.  For the technical field, this means we embrace the constant change, the continual learning, and the desire to find better ways to get our day to day work done.
  • Leadership – Now it gets harder.  Superstars realize that they’re on a team, and have to be a part of that team.  But true superstars step forward and lead the team, they set the tone for the people around them.  As data professionals this means we look for projects and weaknesses in our environments and improve them.   Don’t ask for permission, don’t look for approval, just lead.  Is there a better way to run your backups?  Do you see poor performance due to bad query or table design?  Where ever you see a place where something can be made better, lead the way and those around you will follow.
  • Make those around you better – Once people start following, you need to help lift them up.  Your team is only as strong as the weakest link and, as a superstar, it’s incumbent upon you to strengthen those links.  Maybe a teammate is struggling with escape characters in dynamic SQL or they have questions about creating a server side trace.  Whatever the case, withholding your knowledge or doing the work for them doesn’t help the team.  True superstars raise up those they work with, because they know that the success of the team is dependent on the ability of the team, not the ability of its superstars.

The work we do every day is a team sport.  We can be good as individuals, but we are rarely viewed as that.  Take John Elway and Dan Marino, two of the greatest quarterbacks of their generation.  In almost all cases, Elway is seen as the better quarterback because of his team’s success.  While he’s recognized as a proficient individual talent, the Superbowls he led the Broncos to set him apart.  That’s the key, that he led the Broncos.  His superstar status is more a result of what he did with his team than what he did by himself.

We want to have the same effect.  While there might not be a championship on the line, our own talents and abilities are enhanced by what we do for those around us.  These people might be team members, co-workers, or even the extended SQL community.  Note that a lot of the superstar SQL contractors we know (Brent, Paul, Denny, etc.) are heavily involved in sharing knowledge with the rest of us.  Their sharing makes us stronger, resulting in a better database community.

The next time you watch a major sporting event, look at how that team is being led.  Consider the superstars and what you can do to emulate them.  While we may not have the money, we can certainly have that same success by choosing to make their habits our own.

So about that time management…

Yesterday I read an interesting post by the inimitable Brent Ozar (b|t) on time management.  Good stuff, much of which I already do or try to do.  Shortly after reading it, I had a brief Twitter exchange with Brent and Steve Jones(b|t), essentially on whether or not these were just rules for consultants or if they worked for us corporate folks as well.  Personally, it’s been my experience that not only can you follow these rules, but that you really should if you don’t want to burn out and still accomplish your goals.

First off, if you haven’t read Brent’s post, go read it.  I’ll wait.

<Time passes>

Cool, now that you have context, I want to basically give my thoughts on each of the rules and how I put them into practice in my own work day.

#1 Decide you want to be incredible – One of my favorite tweets from @FAKEGRIMLOCK is “BE SELF.  ITERATE UNTIL AWESOME.”  The first rule is really that simple.  You don’t have to change who you are, you don’t have tap into some hidden fount of knowledge…you just need to be yourself, awesomely.  This is something that can be done in a corporate job as easily as anywhere.

#2 Never budget less than whole day increments of time – Let’s not take this one quite so literally.  What I take from this is to devote blocks of time to my tasks and reduce distractions.  Whether it’s 4 hours or 2 or 8 (if I can get away with it), I use that block ONLY for the designated task.  Don’t multi-task, because it becomes harder to focus and get things done.  The key is to reduce/eliminate distractions.

Distractions come in many forms:  Meetings, on-call pages, emergency 20 hour conference bridges, people coming by your cube to chat, etc.  We can’t plan for them and they are probably the biggest threat to getting stuff done.  This is the balancing act, the biggest challenge for time management.  I’m actually going to steal some NoSQL terminology to outline how I approach this:

  • Map – Map out my time, schedule my work.  If I’ve got 2 hours, I plan to put 2 hours into a project.  Don’t work on anything else.  Keep in mind, sometimes the work is planning out your other work.
  • Reduce – Do work that reduces your other work.  Can you build better maintenance for your systems?  Can you communicate with people outside of meetings?  Take control of your time and put effort into removing the distractions that could disrupt you.

#3 Leave one whole day per week to do absolutely nothing – For me, this translates to one word:  disconnect.  We live in an a world and a culture where it’s easy to always be working, where we’re checking our email constantly, looking at alerts, responding to internal customers, monitoring our servers.  Why?  The world and the company will go on without you for a while, take a break for yourself when you need to.

IT has a reputation for burning people out, but I think that’s because people let the job control them instead of the other way around.  Take a break, breathe, and do something else.  Life is too short, you need to remember that we work so that we can do the stuff we enjoy.  Fortunately for many of us, we enjoy our work, but that can’t be the entire definition of who we are.  And if you’re working a job where your boss expects that?  Time to get a new job.  There are companies out there that respect the work/balance, go work for them.  You’ll feel better for it.

#4 Leave one more solid day to pounce on incredible opportunities – Not much else to say here, though I would add that incredible opportunities can happen inside your company, they don’t just come from without.  Also, some opportunities are self-generated.  An example from my work:  My job doesn’t have any formal SLA’s defined for the database team.  I saw the need and am driving that project.  My bosses and co-workers are taking note of my initiative.  Sometimes pouncing on an opportunity is simply being a leader.

#5 If the incredible opportunity runs more than a few weeks, it’s work – Maintain your balance.  When you take on additional projects or tasks, make sure they fit into the overall scheme that is your work/life pie chart.

#6 Say no early and forcefully to everything else – Much has been written about the necessity of the 40 hour work week.  Since we can’t do everything, at some point we need to be able to say “no”.  This is the hardest piece, especially in a corporate environment where you have a team that depends on you or management you want to impress.  However, you’re only human and sometimes work just isn’t going to get done.  This actually loops back to #3, because if we take on more than we’re capable of doing, everything else suffers.

Let’s not confuse this with neglecting what the company requires of us.  There are times we’re going to need to work on things we may not like (stupid SSRS).  What we need, as corporate employees, is the freedom to cry “uncle!” when there’s too much on our plates.  Sometimes it’s having a teammate take on that extra project, others it’s pushing out deadlines.  Really, all we’re trying to manage here is our overall workload so we’re not trying to do too much.

And if you’re working a job that won’t let you say “no”, that doesn’t trust you enough to accept a “no”, then maybe it’s time for a new job.  Just sayin’.

I think Brent’s rules are a great and hopefully this puts a little more perspective around them.  While my personal approach is worded differently, I think the main principles are the same.  What’s important is that there’s no reason why you can’t follow these rules in a corporate world, that these aren’t just for consultants.  Sure, you won’t follow them to the letter, but that’s not the point.  The goal is that too often we let our time manage us when it should be the other way around.  Turn that corner, take control, and you’ll find everything changes for the better.

(Yeah, cheesy end, but sometimes it’s like that.  Thanks for reading!)

Survival Monitoring

The IT world is a jungle. Countless threats lurk like predators, ready to devour us if we’re not careful. Seemingly benign events can quickly turn in to raging panic fests and danger lives everywhere that we’re not looking. To survive you need to be prepared and proactive. Unfortunately, many of us are thrown into this with little more than a pat on the back and a smile, as if we just got dropped out of a helicopter into the African jungle with little more than a pack of chewing gum and a pocket knife. Yet, we need to survive not just the next day, but the weeks and months ahead of us.

Because we need to survive, there’s some basic stuff we need to focus on in order to ensure our survival. It’s not everything we need to live happy, contented careers, but the minimum elements we need to watch in our environments to make sure we live to see the next day. If we were trapped in the wilderness, we’d first focus on shelter, fire, and food. In database terms, we need to first keep an eye on backups, services, and disk space if we want to make it to the next day.

Shelter from the storm

The most important item in a DBA’s life is backups. We can have screaming disk, tons of CPU, and all sorts of clustering, but that means nothing if our files get corrupted or the building burns down. Just like shelter in the wilderness is a place where we can always find protection, our database backups will always give us something to recover to.

Keep an eye on three things when it comes to your backups. First, make sure they’re actually occurring. Look to the backupset table in msdb for this, because it will tell you exactly when your backups are occurring, whether they’re log backups, fulls, or differentials. Next, where are your backups located? Backups won’t do much for you if they’re stored to the local computer and then that computer’s hard drive burns up or gets corrupted. Make sure that your backup files get to another location. Finally, make sure your backups work. Just because you take a backup doesn’t always mean that backup is reliable. Perform restores when it’s not an emergency to validate your backups, so you’ll know things will work when it’s an emergency.

Backups are your safety net. No matter what else happens, you should always have them to fall back on. It may not be pretty, but you’ll be glad they’re there when you need them.

Give me fuel, give me fire

Fire gives us the energy to get things done, whether it’s keeping us warm or being used to cook food. This is the same with your SQL Server services. If these aren’t running, your databases are down and your company is losing money. We can’t always prevent the interruption, but we need to be ready to respond when that interruption occurs. As DBAs we need to be proactive and watch our services.

Also, we can’t limit this just to the SQL Server database service. How many of you run SQL Agent jobs to perform your backups and maintenance? I know I do. If the Agent service is down, the databases will be working fine, but none of that other work is getting done. To boot, you probably won’t be getting any notifications about these jobs not running, so this will be one big blind spot.

We can’t take on faith that services will start automatically. Sometimes they stop for completely legitimate reasons. It’s our job to make sure they’re up and running and very few things are worse than that surprise call about something not running because a SQL related service is down (one thing that is worse is that we don’t have a backup, see above). Watch your services and you’ll sleep better and warmer.

How can you have any pudding if you don’t eat your meat?!

People got to eat. Once we have a place to sleep and fire to keep us warm, this is the next thing that we need to keep us going. For databases, this food is disk space. We could expand it out to CPU and RAM, but I’ve seen many a server that will limp along when these are consumed and stop stone cold when a file can’t grow anymore because the server ran out of space. If we want a happy database, we need to keep our database fed.

Primarily, watch the free space on your drives (wherever your files are stored), but also keep an eye on the free space within your files. You need to know when your files are going to grow and consume your space. The immediate survival goal is to make sure your server has enough disk to keep running, but you also need to monitor how that disk is getting so that you can be ready to add disk as necessary.

Getting by

Please note, doing all of the above doesn’t guarantee that your server will hum along happily. This isn’t happiness, this is survival. This is the bare minimum you want to do to ensure your company’s service and data. That’s the thing about monitoring: there are hundreds of counters and statistics you can watch, it’s up to you to figure out which of those are important. That’s why you want to start with the fundamentals first, or you could be putting your data, your job, and your company at risk.

I wanted to start with the overview of this strategy. Stay tuned my next post (might be next week or next Thursday, depends on my schedule), I will actually cover some technical solutions to this monitoring, some SQL and PowerShell scripts you can use to keep an eye on all of the above. If you want to get a head start, take a look at my post on backupset or look at Brent Ozar’s(b|t) sp_blitz.

 

Preparing for 2012 (part 3)

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!