I never thought a government agency would teach me a life lesson. That was until I had a long drive to a client site and pondered the FCC label you see on electronics, motors, and the like…

I was listening to my Zune Pass music in the truck driving to a client a couple hours away. I don’t have an auxiliary input on the truck so I use an FM transmitter. While stuck in traffic, I wondered if I was harassing anyone’s favorite station and that got me thinking of the warning you see everywhere. That got me thinking, The FCC has it right! Why can’t we get it right more often?

That warning:

Relationship Advice From the FCC

Let’s Define Interference

Lest someone think I mean we have to put up with a dangerous situation at home or at work, I’m not suggesting that. But let’s just replace interference with “flak” or “offense” and we can probably replace “undesired operation” with “wounded pride” or perhaps “loss of productivity” or something…

“(1) this person may not throw harmful flake, and (2) this person must accept any flak received, including flak that may cause a wounded pride.”

So What Do I mean?

I mean if we look to the planks in our own eyes before pointing out the speck in someone else’s eye, to borrow from the Bible (Mat. 7:3 paraphrased), we’ll be onto something. If we care more about the interference we are throwing out into the world and less about the interference we receive we’d be happier. We’d get along better with SAN administrators, DBAs, Developers and maybe, just maybe, even Project Managers.

If someone tells me that my FM transmitter is stepping over their favorite radio station, the manufacturer of it is supposed to work to prevent it. I don’t know if the law passes to me, the owner, but if so, I am supposed to make it so that is no longer the case. But… If I am driving down the road listening to a favorite song and someone drives by the other direction listening to their death metal on an FM Transmitter on the same frequency, I just have to deal with it. My device (like theirs) is supposed to receive interference and just deal.

Wouldn’t It Be Neat

If the world operated that way? If we operated that way more consistently. Next time I am discussing something that is escalating into anger/offense/etc., this FCC law tells me that I’m supposed to accept that and look to make sure I’m not adding fuel to the fire. To make sure I’m not stepping on their toes (frequency) and if so? I am supposed to work on fixing my side. They may never fix their side but that isn’t my first concern under this law. My first concern is what I’m doing to others.

I think if we all followed that advice we’d find an ability to work a bit better together. We’d seek to change others by changing ourselves first. I think we’d really be surprised at the results, too.

Imagine a workplace where it was a little tougher to offend colleagues, a little tougher to be offended. Where we didn’t let pride turn lessons learned meetings into blame-storming sessions and we all worked for the best interests of each other and the task at hand.

That’s it. I’ll be back on the posting bandwagon soon. Since I decided to work for myself, I’ve been busier than I had imagined I would be in the first few weeks . I’m starting to get some hints of consistency and breathing space and I can get back on some technical posts and the series on learning from real disasters I introduced a while back.

Quick Disclaimer - I mean we should strive to follow the FCC advice above as best as we can; there are definitely situations in personal relationships and work relationships where it’s time to let the FCC (management, spouse, etc.) know that the other party has been totally negligent with their duties. If a dangerous situation exists, if bad decisions are being made with no input being received, etc. we have a duty to speak up but hopefully we’ve done our part and kept our interference low.

I get to tell you an embarrassing story and I get to kick off a series of posts I’ve wanted to do for awhile now. Why? Because it’s “meme Monday” Check out Tom LaRock‘s post about the topic and the idea he came up with a couple months back.

This week Tom asked us to talk about a “Dumb SQL Question” we’ve asked or wanted to ask. I am twisting the topic a bit and will talk about a question I was once asked (a really good question, if only a bit late). I’m also going to talk about a disaster causing attitude. In fact, I am going to start a weekly (or more frequent) series of posts on lessons from disasters. I’ll focus on aviation disasters and see what sort of improvements we can make in our day jobs as a result. This is a topic that interests me to no end – learning lessons from others’ (and my own) mistakes – In fact I had a really fun time interacting with the audience at the SQL Rally sharing a presentation of such lessons (The title of that talk, Iceberg, Dead Ahead! is a bit misleading, it was all aviation).

All of the posts in this series will be categorized as “DisasterLessons“ and I’ll get to a proper introduction and all later in the week. Consider the ending of this post a quick preview.

But on to that story, first…

Pride Goes Before Destruction, A Haughty Spirit Before a Fall

Let’s go back about 9 years. I’m a few years into my SQL Server career. I know some stuff but mostly I didn’t know a lot – in fact I still don’t know (or appreciate) what I don’t know yet. But I knew a bit more than “the new guy.” He was a VB developer, a talented, smart and experienced guy. He’d been around about 5-6 years more than I had in the industry but hadn’t done much SQL yet. It was my job to train him on some of the aspects of the job. We worked for a software vendor. We had some pretty prestigious clients whose names you’d know instantly. In fact we had a tremendous market share in this particular industry. Well we did some DBA work, some database development and custom SQL work for clients whose needs ran outside of the typical “out of the box” functionality. We were doing a day time dial-in (and I mean dial in) to our biggest client. They were the client whose money trumped all other clients. We added new features because this client said “jump”. We were doing some cleanup work for them….

I was proudly showing this new (and older, more experienced, more talented) colleague all about SQL Server and our product. I was probably showing him how well I could navigate Query Analyzer and write a query on the fly. How well I had mastered our data model and really stupid table names and relationships. I forget what we were doing but we were changing a flag or column value for a large table (maybe it was customers, or companies that had done business for/with this large client of ours). They had typed values wrong for a few of the customers/companies because of a bug and it would be easier for us to fix them with a script. I was so busy talking and probably showing off that I went ahead and quickly typed up that query. To keep it simple let’s say the query looked like this:

UPDATE PoorlyNamedCustomerTable SET SomeColumnTheCustomerCaresAbout = ‘some value that is right for these 5 rows’

I had my keywords in caps, my indentation was sharp looking. I think I even had to do a join for the update to grab some info from a relationship table that linked people and companies. Everything looked nice. I clicked Execute.

At that same moment I clicked execute this colleague threw out today’s question or maybe it was a statement. Either way, my stomach must have landed in our shipping department a floor or two below us when he said that one word in that questioning tone of voice -

WHEEERRRRE?!?

All that flashed through my head was something like a mixture of “Oh, Crap! The Customer! This is a day time change! I have to call them!” and

What I wanted to do (but couldn't because I had to save face )

probably something along the lines of “Young grasshopper, your teacher has become the student” He got to see my troubleshooting skills and customer service skills at work. Probably with a healthy dose of panic and wounded pride thrown in. Customer ended up fine and we had a good one word joke that has lasted through the years we’ve known each other but yeah… That was a pretty dumb question. Well not the question but the fact it had to be asked.

Disaster Causing Attitude?

Had I been a bit slower on hitting F5, I bet the timing would have worked differently. His question would have instantly made me say “oh you nummy” and I would have added the appropriate WHERE clause. Here was a new guy unafraid to ask the person assigned to him as a trainer a question that, well, could have been construed as insulting or embarrassing. In a cockpit that ability is crucial. On a technology team that attitude is also pretty important. You can’t be afraid to ask a “tough” question of a colleague/superior/PM/manager/etc. When I fly on a plane, I want the first officer to feel comfortable asking the Captain, “WHEREE?!!” if he or she does something silly.

In aviation, cockpits didn’t always work this way, though. In fact it wasn’t until a number of accidents pointed out a problem with too much respect for the chain of command, titles, seniority or hierarchy that a new flight crew training methodology called Crew Resource Management (CRM) was established.

Briefly – CRM abolished the notion that the Captain was the one and only authority. Before CRM, questioning the Captain was seen as a high insult. Mentioning something of concern wasn’t necessary because the Captain was all seeing and all knowing. CRM really worked to put all on an equal footing when it came to responsibility for the safety. Leadership training aspects helping senior crew members and Captains to listen and respond to advice, suggestions, questions was big. Training on how to communicate assertively and be bold enough to state a concern or potential problem was big for all parties.  CRM was the natural response to the acknowledgment that human factors were behind most accidents in the aviation world.

“Where?!?” “How’s the Fuel?”

In a pre-CRM world that person being trained would have likely kept his mouth shut – “Mike is training me, he must know what he is doing”. In our case he was a bit too late but the impact was easily mitigated by a restore to a new DB and some quick joined updates with no impact. In aviation the pre-CRM mentality caused unfortunate accidents.

Take United Flight 173, for example. Basically this flight had a landing gear indicator issue. The flight crew spend too much time troubleshooting beyond their checklist and too much time focusing on cabin preparations and being absolutely sure that they were going to try to land. After nearly an hour of troubleshooting and preparations that should have taken half that time at most, they made their approach to land. The only problem? They hadn’t enough fuel to make it and crashed, 10 people were killed, another 24 were seriously injured. While many factors contributed to this accident (and we’ll get to them all as we go through this series), the one we care about here is summed up in the NTSB findings -

“The failure of the other two flight crewmembers either to fully comprehend the criticality of the fuel state or to successfully communicate their concern to the captain.”

If you read the Cockpit Voice Recorder transcript from this flight you can hear a couple really passive references to fuel. Almost as though they could have been said, “Hey uhh Captain, sir, we ahh don’t want to bother you and it’s probably nothing, I mean you know what you’re doing but the fuel situation is well, do you think we’re okay? ahh nevermind, sorry to bother you.”

United Airlines subsequently became the aviation’s industry first implementer of CRM. It’s now mandatory training in the aviation industry as well as many others.

The takeaway from United 173′s passive fuel warning (and my colleagues lack of fear to question my stupidity) -

If You See Something, Say Something (Stolen from the Department of Homeland security’s Orwellian posters)

It’s that simple. If you believe something is wrong, may be wrong or could go wrong – Tell someone. Don’t be afraid of being the one to put the brakes on the project. Don’t be afraid to be the one that gets laughed at during lunch because you misunderstood something. Because maybe, just maybe, your concern is valid and the project you save could be your own. You could spend your weekend having fun instead of picking up pieces from an implementation gone wrong. If you were wrong, so what, at least you paid attention. If you were right and said nothing? Well then you just screwed up that chance to be part of a successful team.

Subscribe to my feed to come back next week (or maybe later this week) when I properly kick off the DisasterLessons series and go through some of the attitudes and actions we talked about in that SQLRally presentation and work together an idea of what the series will look like.

I really like presenting. I’ve blogged about some tips for others thinking about starting before. In those posts, I share how I started out terrified of speaking in public. One of the reasons I am enjoying it to date? Good feedback. Don’t read that as “positive” (though there has been more of that than I’ve expected!), but helpful feedback.

I’ve been meaning to write this post for awhile now (since helping plan and execute SQL Saturday 71). Seeing some recent frustrated posts from two individuals I respect. Two SQL Server MVPs who both speak and blog regularly. One was Aaron Bertrand, the other Allan Hirt. Their posts were reviewing feedback from SQL Bits (Aaron’s | Allan’s).

A common theme emerged – “If you are going to fault me in the points, TELL ME WHY!” . To that point, I say – Right On! But… I wonder is it the attendee’s fault or is it the Organizer’s fault? Now I don’t know the SQL Bits questions, I know the ones used at the PASS events. I know the ones used at most events. For those?

It IS The Event Organizer’s Fault!

I really hate the questions PASS asks. They are a bunch of 1-5 scaled questions that aren’t necessarily that helpful for a speaker alone. They allow space for comments but they don’t ask any open ended questions designed to solicit feedback.

Numerical ratings are tough. On one hand they are important so you can have one scale to rank speakers by. They are good for people who want to see where on the poor, fair,good, better,best scale they are (either for a quick ego stroke, confirmation to keep speaking or a not so subtle way to suggest another approach). On other hand – They are meaningless…

If someone comes to one of my sessions and gives me a 2 on a 1-5 scale or a 3/4 on a 1-10 scale, that doesn’t tell me why (unless it was a specific question like “please rank the speaker’s knowledge on the subject” but even there it doesn’t tell me what it was that caused the ranking) the ranking was so low. It doesn’t tell me what I can do to improve.

The line those two blog posts took was a good one and a good reminder for us all as session/training attendees – explain your scores (good and bad). But… I think the organizers can do more.

I’m not saying that my questions at SQL Saturday 71 were the right questions. I am not saying that I’m an expert on soliciting feedback, but I know people need to be prodded. So I have a plea to all you event organizers out there -

Ask Better Questions!

Yes. Still ask your numeric ratings questions, just replace some of them with questions that require writing. I know, not everyone will fill them out and just circle numbers. Those people will always exist and some people will just be critical and leave no comments,it’s just how some operate. But… A lot of people will provide useful feedback.

With that disclaimer that I’m not saying this is THE way, maybe looking at the questions asked (and the rationale behind them) at an event I helped organize will let the SQL community at large think of better questions.

What did I ask on the SQL Saturday 71 Feedback?

“How would you rate the overall quality of this session?” -  The only numerical rating. I could have asked more on a scale but this is the one that is good to see on a scale, the rest of the questions on typical session feedback aren’t so useful on a scale only. Even this one alone isn’t terribly useful if you want to get better.

“What is the best idea from this session that you plan to use?” - It’s why we speak. We want to help people learn a skill, behavior or grow in some way. As a speaker, this lets me see if the goals I had when setting out on this presentation were met. It also lets me see if there is a trend towards one point and maybe I can split that off into its own talk.

“What Could be done to improve the overall quality of score?” - There is probably a better way to ask this. Maybe even adding a question (our session feedback sheets were half sheets, to save on budget and paper) about “what idea will you probably never use?” But anyway, back to this question. This is gold for me as a speaker. There may be some tough things to read here. That is fine! I want to be better each time I speak. I want to get my ideas out better each time. This question allows an otherwise “polite” person to have an excuse to be constructive. It is begging them to write something other than “Great job!” or “Nice” which are useless comments. As you see in my feedback review from my SQL Saturday 71 talk, I learned a few things from answers here.

“Overall Comments” – I’ve heard that some people like to be verbose . This allows them to be. Maybe something else was on their mind that wasn’t covered by a question.

My Point

Just a few questions and the answers to them do a lot more to make me a better speaker than 6 scaled questions with optional comments that never seem to really provide much constructive feedback.  Please start asking questions like that. In the meantime, I’ll enjoy reading Aaron and Allan’s posts

When I re-read yesterday’s blog post on troubleshooting steps, I felt guilty. Instantly. Why? Because I had failed to mention something to you in that post and failed to follow advice I just gave in my SQL Rally presentation. *In my own defense, I did mention that one of the bullets I used in that presentation was hard to type – “We need to move away from ‘do as I say‘ ”

I’ll come clean with it here, just don’t tell anyone…

That Starter Replacement I Was So Proud Of?

It didn’t have to wait until I had my family stuck in the truck. It didn’t have to wait until I had three kids ages five and under getting cranky strapped into their seats on a (apparently rare this year) hot New England day. Nope. If you read that post, you’ll notice I gave a quick tell when I said, “They agreed and added, ‘starter problems almost always start intermittently, probably was better in winter because of how the metal moves’….”

See It?

I started having odd issues long before it got to the point where one of the factors in my decision to replace it myself in my driveway was the fact that it was stuck here. I had stutters, situations where it felt like the starter motor was running longer (like I was grinding my keys after start), etc. I mentioned it in passing to a garage while it was in for other service in the fall, they couldn’t reproduce it (it was incredibly intermittent) and we dropped it.

So What?

Had I dug deeper, maybe brought the starter someplace (do they still test components like starters?) or just had a shop replace it (of course it would have cost more money and I wouldn’t have that satisfaction of getting my own hands dirty), I wouldn’t have had to break out the troubleshooting skills in a pinch. I wouldn’t have had to hassle the family, move car seats and kill 30 minutes of an otherwise good day for planting the lilies we were off to pick up.

For Our Day Jobs…

Troubleshooting skills are critical. I was clear on that in the previous post and all the referenced posts. Shoddy troubleshooting breaks servers, increases downtime, stresses everyone else out and kills customer relationships. So we need to really put some effort into better troubleshooting skills. BUT… We also need to be great at keeping on top of maintenance and best practices during the “rest” of the time.

Especially as DBAs… We’ll need good troubleshooting skills at some point in our careers. Even if we did everything perfectly, never missed a beat, kept our instances well oiled and tuned, we’d still have to fix some problem sometime. Why? Because we get blamed for it so it’s in our interests to show off our troubleshooting skills from time to time   But Seriously… We’ll have to fix problems from time to time. Let’s do our best to reduce the times we have to do urgent troubleshooting, though. Okay?

We can do things like test our restores, verify our backups, check database consistency, perform routine maintenance, check the vital signs of our instances and look for variances from those baselines, be tough with what we allow to wind up in production, lock down our production servers, do code reviews, etc. Really.. Just stay on top of the instances.

You may find something wrong that isn’t critical today (like my starter last fall when it started the odd behavior). I guess I’ll leave the final choice of handling up to you, though –

A.) Whoa… I was scared for a second there, looks good now. I’ll check it out sometime and watch for it again.

or

B.) Whoa. That could have been much worse and it may be much worse next time… Let’s have a look at why that happened and verify it won’t again…

I’ll give you a hint -  A is less expensive, quicker, easier, and feels right, today. B gets to be a lot more expensive, longer to figure out, more difficult and feels pretty miserable once the circulating fan blades make their destined contact with the solid waste in the future…

So I’ll leave you with the general thought I had in a recent SQL University contribution – How are your instances doing? Do you even know what they look like anymore? Go visit them, say hi to them and ask them how they’re doing.

If you can’t troubleshoot, you can’t work with me (if I can control it anyway). When I am interviewing you I am judging your troubleshooting skills as much as your SQL Server knowledge – if not more depending on the role. I’ve blogged a bit about troubleshooting (Methodology, Trusting Empirical Evidence) and wrote a SQL Server Central Article on it.

A couple weeks ago I almost threw out my shoulder patting myself on the back after replacing the starter in my truck. Up to that point the most complicated thing I’ve done to a vehicle is changed a battery, tire or fuse. I’ve changed the oil once or twice (in my lawn tractor…)  I won’t spike the football by talking too much about the fix here but I wanted to talk about the steps that brought me to the realization that I was going to be changing into my dirty clothes and lying down under my truck for a couple hours. Those steps followed the methodology I discussed before and effective troubleshooting has been on my mind as I prepare for my SQL Rally presentation on Professional Development (Iceberg, Dead Ahead!)

The Journey:

I Identified The Problem 

Out with the old..

I’ve had some intermittent issues with starting but jump starting, waiting or jiggling wires (not a proper methodology but a good quick step each time I had an issue) solved it each time. Well the day it looked serious I had the whole family in the truck (even moved the infant car seat over from minivan) for a ride to pick up flowers to plant. My first reaction was problem solving (rushed problem solving). That looked like sighing, rushing, jump starting, jiggling, tightening battery terminals, etc. It was messy and shotgun like. My wife gave me that look and I knew to stop and move everyone to the van for our trip.

This let me troubleshoot a bit more slowly and carefully later in the day. Here’s what I did:

• Think – How does a truck start? The 100 level of it (where I am) is -  the key turns and, if the battery is good & transmission is in Park or Neutral (and truck knows it), electricity flows through the battery to a starter. That starter spins fast and starts the engine. So electrical flow is critical, some switches and relays are critical. Fuel helps, I hear.
• Rule Outs – I ruled out the issues in order of “obvious problems” and easier to fix:
  • Fuel – Engine wasn’t even trying to turn over, just clicking. Starter wasn’t spinning the flywheel.
  • Battery – Tested, no issues. Terminals looked fine, connection tight.
  • Fuses – Fine
  • Relays – Starter relay had same number as some others. Swapped them, same sounds.
  • Wires/Cables – Connection from battery to starter was good
  • Key – I was pretty sure there was no chip in mine, but used a spare to be sure.
• Analyzed Evidence -
  • I had ruled out many components. Really all that seemed left was the starter. Thought through rule outs and couldn’t rule it out without changing.
  • Probable cause – I was thinking starter now.
• Verified – I am not mechanically inclined s0 I verified my direction
  • Internet – Found a few trustworthy sites describing starter issues. Symptoms matched, rule out steps matched and sites agreed. Still, it’s the internet…
  • Parts Store – Paid a visit and told them what I had done and what I was thinking. They agreed and added “starter problems almost always start intermittently, probably was better in winter because of how the metal moves”
• Decided – I was going to sink the money on a starter. If it worked, it was likely it. If it didn’t I’d return/resell and call a “consultant” (tow truck to garage)

Researched Solution

• Level of effort – Could I do this myself? By all accounts, yes, if you can follow directions, wires and spin a ratchet.
• Instruction – Looked for some quick training. I wanted to know some basics (What does a starter look like for instance… what tools do I need.. What precautions should I take, etc.)
• Tools – Verified I had the right tools (Socket set really)

Decided To Fix

• Critical – I wanted to get this running, needed to for work.
• Had a backup plan  – Tow truck, AAA, Wife’s family members who are mechanically inclined
• Go/No-Go – Couldn’t see any reason to not try. I Didn’t even have to lift truck and worry about it slipping off jack/jack stands. We were a Go.

Fixed

• Got Dirty – Spent a lot of time under the truck finding exact location of starter.
• Traced wire to starter – Did that by following the starter wire from battery I had read about and tested earlier.
• Found bolts, found ratchet, made them meet
• Brought it down – It was difficult to access.. I had to take fender off, an unexpected diversion with components I didn’t know how to work with (little plastic pop screws, broke a few before I figured it out)
• Replaced It – Disconnected old one (pictured in this post), hooked up the new one and put it in the right spot.
• Hooked up battery – (I had disconnected it before starting – made sure I was not working on live system… Always bad when you mess up in live)
• Tested it a few times and ways – Mainly because I liked the sound of my truck starting and the look of my blackened, greasy hands turning the key
• SHIP IT! Problem solved.

Lessons For Next Time

I asked myself about what I could do differently next time -

• Could have a few more tools for next time
• Should have researched proper way to remove/replace fender fastener clips

So?

That’s really it. All of those steps are how we can solve any problem. When I ask that unrelated problem question or open ended “how would you deal with complaints of a slow SQL backed app?” I am looking for something logical, step based and calm. Something along the lines of these steps generally -

1. Gather Initial Information
2. Keep Thought Involved
3. Rule In/Rule Out Causes Methodically
4. Verify Your Understanding and Assumptions
5. Propose Solution(s) Accordingly
6. Carefully Test Proposed Solution  (if you can)
7. Implement Fix
8. Test and Verify Fix
9. Learn for Next Time

And do all of that while remaining calm and keeping a picture on the big picture.

This week was DBA Week At SQL University. We’ve seen two great posts from Robert Davis, a couple posts from me and some input from DBA Coach LaRock.

Today we’ll lighten things up. It’s Friday so let’s close our notebooks and have a classroom discussion about our attitudes and learning. There are all sorts of DBAs out there. Reluctant ones (“you can spell SQL – you are our new DBA now in addition to the duties we originally hired you for”), Great ones (Tom LaRock wrote a book, DBA Survivor, about how to become a Rock Star DBA), Development ones (they yell at themselves all day long), and the list goes on. But… No matter what kind of a DBA we are, I think we can do better than we do in a few areas. Maybe I’m off but I’m going to go there anyway.

Ready? We’ll start by talking about some attitudes to grab and ditch. While we look at some comments that could be on a DBAs Kindergarten progress report (I am not excluding myself and in the same way I normally do when getting all preachy on professional development topics, may I remind you that I am talking first to myself here?)

Does Not Play Well With Others

Sometimes we DBAs are known as being arrogant, egotistical, opinionated, paranoid, no saying jerks difficult to work with. This shouldn’t surprise you, it doesn’t me. Part of it comes down to the fact that, if we are a good DBA, we feel a burden to protect the data we serve. We feel like everyone else is out to mess things up (and sadly a lot of time, it doesn’t take years of therapy to see why we might feel this way…) and we have to take a hard line. That’s okay. When I give that “Where do I start?!” presentation one of the points I drive home is data advocacy. I use a little hyperbole and comment about how we are the only ones at our companies that care about the data in these databases. We are the only ones who care about protecting it. I know that isn’t always true but some days it feels like it. Regardless, that is how we should feel, I think. We want to protect our databases. We know whose hide is on the line when problems arise (There are those who say DBA stands for Default Blame Acceptor I think it is for this reason that our first position is sometimes “No” and why our developers think it stands for Don’t Bother Asking), we know that if we can’t ensure our databases are recoverable, with integrity, available and performance that our weekends and holidays just got axed. I like to also think it is because we care about doing a quality job every time.

So regardless of the background and rationale behind it, we have this reputation. I’ve earned it in the past, unfortunately: Ask the poor developers I sent reply all’s to earlier in m career. Ask those in go/no-go or code review meetings where I’ve taken on the persona of Sir Walsh, protector of all things data and swung my two handed sword for the knees. Ask those people I’ve taught to give up on eating fish instead of teaching them to fish earlier in my career.

So… What are we going to do about it? How can we keep our business relationships positive while still fulfilling the duties of high protector of the data in our charge? Some thoughts -

• Check Your Motivation – Is it to be right? Is it to cover your butt? Or is there a deeper motivation? There probably is but it gets lost to often. Find the more healthy motivation that drives the same end results. In my case, I want to protect the databases I am responsible for. I want to do the best job I can. If I think of that instead of “I want to be right, I want to shut down access, slow down fast releases to production, etc.” I accomplish the same goals more efficiently and less snarkily.
• Teach – You know… It was until my adult life (and recently, at that) that I learned that the goal in throwing a basketball into the hoop is to aim for the hoop. I always thought that the goal was to bounce it off the square in the backboard into the hoop. I was always horrible at basketball. I still am no Tom LaRock but now that I actually know the goal, the angle of my shots are much different and I even get a few in from time to time… No one taught me that. If I was out there playing with you and you’ve been playing for awhile you wouldn’t likely give me that tip. It’s too basic…Mike’s been around for a third of a century, he must know about that already… You would have been wrong though. So… Don’t Assume that everyone knows what you know! There are people who know more and people who know less. Instead of turning into an unapproachable jerk, remember where you were once and do some teaching. Setup some brown bag lunches, offer to help and review code constructively. Explain to the PMs and Management what your concerns are and why they are.
• Explain  – Arbitrary best practices are annoying. Especially if they don’t make sense at first. If you are prescribing it, there is probably a reason, you didn’t just make it up on your own. So provide reference and learning material on these rules. If you did just make it up then reference your blog post about it
• Ask yourself what you are doing wrong… I heard this one from our Pastor before we got married. I don’t do it as often as I should in many situations but it is a principle that works just about everywhere. When it comes to debatable/arguable points, ask what you are doing wrong and what you can do to make it better. Instead of focusing on -them- (Vendors, Developers, Management, Project Management, etc.) and all they are doing wrong ask yourself what you are doing wrong. Change it. Even if they don’t. You’ll find more people change by you changing than you trying to change others.

Doesn’t Seem To Want To Learn

Sometimes you have someone who doesn’t want to learn. Be it a developer, a vendor or a project manager. But you know what? Sometimes isn’t motivated to get better. I know, perish the thought! I am not saying we need to make our one and only goal in life to learn more about SQL Server and the DBA trade but a lot of us can do better than we do. There are User Group meetings, conferences, SQL Saturday events (that are free), webcasts, etc. out there. Attendance is sometimes pitiful at these, especially when you consider how many work in the profession and have the time in the area. Make an effort to grow and learn. Challenge yourself to get to the next level. This isn’t a mandatory skill but if I am doing your job interview, you aren’t getting the DBA job, even a Jr. DBA job if you show no desire to learn. I’d honestly rather hire someone with an okay skillset and a grasp of logic and process and a strong desire and interest in learning. Just about every time, too.

Afraid To Ask For Help

SQL Server is huge. There are experts in small sections, there are Microsoft Certified Masters who know a lot about a lot more but even they aren’t experts in every aspect, no one person can be. Don’t be afraid to ask for help. There are a ton of people out there in the SQL community wanting to help you. A TON of people. More than other technology areas I interface with. The vast majority of them have one simple goal – to share and watch you grow. Regardless of where you stand on political and economic fronts, the SQL community has adopted the trickle down knowledge mentality and found it works. Those with the most knowledge share a lot in various formats (blogs, speaking for free, paid courses, webcasts, white papers, answering questions on forums, etc.) and that sharing causes more to share and that sharing causes all boats in the harbor to rise together. Start out on SQLServerCentral, SQLServerPedia and the #SQLHelp hashtag on twitter (yes, twitter! A great way to interact with and learn from the SQL community). In a nutshell, remember: If you aren’t growing in the community of SQL Server users, it is entirely your fault… I am serious. With all the help resources available, your growth is yours to ignore.

That’s it. DBA Week (and my long posts with it) is over at SQLU. Well this week anyway, check out the schedule and see other DBA related weeks coming up.

Some Related Posts

I’ve hit the poor dead Professional Development horse a lot here. You can subscribe to my feed for future posts and check out some related Professional Development meets Technical Career with some of my favorite posts like:

• Bill Clinton Wasn’t Impeached For… – A reminder that we need to “own it”
• Prepare For The Disaster Before The Disaster… – Good lessons from this winter
• Plan To Fail Or Don’t Expect To Succeed… – Let’s be honest – you are going to fail. Do it right.
• Day Job Lessons From The Garden… – We like providing for ourselves as much as we can on our land. I think a lot while tending the gardens, including this lesson learned from using the wrong tool and no gloves while digging a trench…
• One Man’s Trash – I learned an important lesson from the staff at my town’s dump that needs to be transferred to our careers.

Welcome to the third day of DBA week at SQL University. On day one, I kicked off the “back to basics” journey I’ve chosen for fellow students with my post reminding you that you’re only as good as your ability to restore. Microsoft Certified Master Robert Davis brought us a good reminder on Day 2 of some mechanics around restoring and backing up. Our coach, Tom LaRock, also gave us some good reminders earlier in the week. Today we are going to continue in a lesson that steals thunder from myself and a presentation I really enjoy giving to new or reluctandt DBAs – As a DBA Where Do I Start while we focus on the fact that SQL Server is not like theRonco ST3001WHGEN Showtime Compact="> Ronco Rotisserie Chicken –

it isn’t…

Set It And Forget It

This is a drum I beat a lot. Not because I enjoy its sound. I beat this drum because I often see the results of the “Set It and Forget It” mentality. I am often called in for a cleanup in aisle 32767 because someone, somewhere in the early life of a database thought you could just install SQL (but they make it so easy!), drop a database on there that is critical to the company, pat themselves on the back and walk away to tackle new challenges. I beat this drum because I hear things like the following (true quote from a large ERP system vendor, by the way) quo

SQLChicken Agrees - SQL Server Isn't Set It and Forget It

te from vendor:

Oh! You’re on SQL. I wouldn’t worry about index rebuild jobs or statistics updating, just keep auto update stats on. SQL shops are easy, anyone can walk in off the street and play the role of DBA!

Sure it is a bit of a paraphrase but the main points are 1.) He really did say the part about coming in off the street and 2.) He was dead serious about not doing any index or statistics maintenance. Ever.

I’ll let you cut this class now, if you want – Do you ever talk to your SQL Server? Do you ever just ask it, “Hey, SQL instance, how’s it going? You feeling alright?” Do you do you look at the logs? Perform Index Maintenance? Take Benchmarks? Basically, do you love your SQL Server instance? If you keep saying “YES!” Go ahead. You can play a flash game again. If you felt a little lump in your throat because you know your SQL Server instance is sad, lonely and set and forgotten then keep reading – there is no time like today to restore that relationship. Forget about apologies… Actions speak louder than words and that is what we’ll focus on. Actions like -

“How are you? I know we haven’t talked much lately”

Spend some time on your SQL Servers. They’ve been working hard all this time for you and you can’t even remember the last time you just stopped and asked it how it felt. That’s a good first step, no? You don’t have to go out and spend a lot of money on it (though if you have the budget, consider a monitoring tool! There are several out there at great price ranges). Jump onto SQL Server Management Studio (if you are using SQL Server 2000, nicely tell your server you’re thinking of a newer model). Expand Management, Then SQL Server Logs. Double click on the current log and have a look around. What do you see? Any problems? Look them up and get them taken care of. You hopefully see backups being taken (look at the homework for a tip here), if you don’t you might want to stop reading here and go back to my first post of the week. Want to make this relationship work? Make a new habit – Do this every day – take a quick look at your log for the entries since the last day.

Want to automate this? Sure you can automate things, roll your own monitoring process, etc. I would say don’t waste your time, just buy a SQL monitoring tool that has support teams, development teams and keeps up with SQL Server releases so you don’t have to change your code when you upgrade. 

“Can I help you with that?”

Your SQL Server does a great job all by itself. That doesn’t mean you can’t take an interest in it and offer to help it run better – We need to make sure we are maintaining our SQL Server as we move forward. I have a standard set of maintenance tasks I run on SQL Servers I own or inherit. These tasks do things like -

• Recycle The SQL Server and Agent Error Logs - Sounds silly and useless but it sure saves time when trying to open an error log for troubleshooting purposes when you don’t restart your instances often. (Learn about sp_cycle_errorlog and sp_cycle_agent_errorlog)

• Maintain Your Indexes – I use Michelle Ufford’s Index Rebuilding/Reorganizing script (don’t let the baby picture scare you. Keep reading). Basically the goal here is to ensure that your indexes are doing the best job they can – they can become less helpful over time due to index fragmentation. Get in the habit of performing regular index maintenance (how regular will depend on your environment, pick a time of lower – or no if possible – activity)

• Maintain Your Statistics – Statistics are updated “automatically” by default when a certain amount of data change on the underlying table causes them to be marked as invalid. If that amount of change hasn’t happened, they will remain valid and won’t be updated. This could be good (updating statistics after each row of change would have a negative impact on your system) but it could also be bad (you may never hit the percentage of rows changed but they could be enough to have new statistics make a difference in query execution). These statistics are, in a nutshell, used to help SQL Server determine how best to access the data for a given query. If they are not accurate enough, the approach chosen by SQL won’t be the best it could be. I like to update statistics about once a week for most databases. Choose a schedule that works that balances lower periods of activity or no activity with update and data change frequency to update your statistics.
  

• Clean Up Back Up History – Each time you take a backup in SQL, a record of it and its location is stored in your MSDB database. This is there mainly (only?) to make life easier for you if you chose to do a restore through the GUI – your backups would already be listed for you. This history can grow over time to the point of slowness with the restore/backup dialogs and bloat in your MSDB database. Clean this up on a regular basis. Denny Cherry posts about a way to do that here – though pay attention to my warning in the c comments and don’t go for cleaning up a half decade of neglect all at once.

• DBCC CHECKDB – Corruption kills. The only thing worse than corruption in a SQL Server database is corruption when you forgot that you’re only as good as your ability to restore and you have the lack of backups to prove it. Running regular consistency checks is a good way to find corruption before your users do. Hopefully you’ve ensured you are following the SQL Server IO best practices, virus scan best practices and treat your server well. Corruption can still happen. Running DBCC CHECKDB won’t prevent corruption but it can let you know about it or a trend towards a serious problem a lot earlier than waiting for symptoms to show up. Read Paul’s post from a survey about performing this check and then get working on scheduling a job to do it, don’t be that DBA.

“Are we growing closer?”

How can you know if things are going bad if you no longer have any concept of what normal is? Maybe you forget that first time you saw your SQL Server? You forget what things used to be like when you were both younger and more fit. Your SQL instance has had a lot of baggage added to it, its databases are bigger now. How is it doing? How much longer does it have? It is good to watch how things grow over time. Perform periodic benchmarks! Even if you just use the PAL tool as I described in a previous post and grab some performance data every month, quarter or even year, it helps to see how things are going. You can’t know you are having a deviation from normal if you don’t have a normal to compare to! One side benefit of going with a monitoring tool? Some provide a means for capturing benchmark information quickly.

“You can talk to other people”

But with all of the neglect you’ve given your server, I think no one will fault you for approaching it with the attitude of a paranoid control freak. Alright so maybe this one doesn’t work with the whole real world relationship thing where trust is important. I guess what I am getting at is – do a security audit. Find out who else can talk to your server and hunt them down and… verify that they should have access and at the level they are at. Make sure security best practices are being followed. When I think of SQL Server security I think of my friend K. Brian Kelley who happened to blog a lot about securing SQL Server for this semester at SQL University. Since you are starting to do all these nice things for your server you don’t want someone else to come in and undo all the love you’ve poured into your server. Make sure they can’t or at least only those who are supposed to can.

“Watch out for the parking lot perfume robbers!”

If you really loved your server, you’d help watch its back for all in the world trying to get it. So maybe there really aren’t perfume wielding bandits waiting to render you unconscious at the mall. There are software vendors waiting to do something similar to your SQL Servers! Well okay, maybe that isn’t their intention but sometimes it happens. You don’t have to spend long in twitter to find a victim’s advocate spouting off about how it happened to a SQL instance of theirs. Do some due diligence. Ask your vendors some questions before they move in on your environments. Otherwise you might have a mini rant of your own someday while frantically looking for your backup files.

Quick Homework

This post was quite long. I could have kept going but I think you get the idea… SQL Server isn’t a set-it-and-forget-it application. It requires care and checking on. So the homework is easy -

• Implement Database Maintenance - We talked about some above. Ola Hallengren has a great set of scripts to do much of this. Brad McGehee blogged about Ola’s scripts here as well.
• Check Your Logs – Even if you are just manually looking at your SQL Server error logs daily for now, that is better than being blind.
• Review Access – Just take a look at who has access to your servers. Does it make sense? Do their permissions make sense? Follow up on the ones that don’t.
• Look at Monitoring Tools – Like  I said, there are a lot of vendors. I’ve worked with a few and have my preference. Others have theirs. You can ask about it on twitter or ask me in an e-mail for thoughts on a few of the ones I’ve used and like. Let your server talk to you for a change

I’ll keep Friday’s post smaller so feel free to subscribe to my blog’s feed if you want more DBA Week learning. Also don’t forget to look for Robert Davis’ post on Thursday.

No chickens were actually harmed in the making of this post (real or @SQLChicken)

I am happy excited to be helping MVPs and fellow User Group Leaders Adam Machanic, Grant Fritchey and Tom LaRock plan a Saturday of free (unless you want to donate a totally optional $10 to help offset costs) learning for the Boston (and greater New England) SQL Server community.

The four of us have been actively planning SQL Saturday #71 Boston  for April 2, 2011. We’ve been doing a lot of talking, soul searching and debating and we ended up deciding on making a

Change Of Venue

Now before I describe the new venue, let me tell you that the Microsoft campus at Jones Road in Waltham is a fine location. I’ve been there many times for many events but we draw a heavy SQL Server crowd in New England and we pack the place to an often uncomfortable level. We have had some excellent sponsors sign up with us and as a result we’ve decided to look at a location that allows the larger crowd to be more comfortable. We’ve also gotten rid of some of the headaches that plague organizers of these events (food contracts, delivery, setup, buying and replenishing drinks, parking concerns at tight venues, etc.) with this change.  Where are we going?

Adam and I just got back from a tour of the venue and the final discussion before entering the official contract (so now it is just a matter of signing on the dotted line) and I am too excited about the location to hold off on the post.. So we are going to be moving to

The Babson College Executive Conference Center

The location has worked with us on the rates, will be providing a group rate discount on the (built in) hotel at the center and will have setup staff, kitchen staff, etc. available to make this an excellent SQL Saturday.

What Do We Get?

• Spacious Meeting Rooms – This is a conference center and we will have rooms of two styles. One style will be traditional conference center meeting rooms seating 35-240 people (for the raffle and keynotes/welcome) with most rooms at the 50-75 person size. The other style (3 rooms) is a multi-level ampitheater/classroom style with aeron chairs, desks and great AV. These seat between 45-75 and if we overflow a room we can have more chairs brought in. Check out their photo tour.
• Continental Breakfast – There are little nooks built in throughout the conference center. At each of these there will be a continental breakfast setup in the morning.
• Continuous Snacks – At these nooks there will be constant snack food, soft drinks, hot coffeee, iced coffee stations and other goodies for attendees walking between rooms.
• Excellent Vendor Space – No more crowding all the vendors onto one outlet in an overly cramped or hardly trafficked location. Here we will have our Gold and most silver vendors in strategic locations where people will be congregating/walking through (including a table right outside of the lunch room). Other vendor locations will still be central to all attendees and at a place where they have to walk through/around.
• Hot Lunch (Fresh from the kitchen) – There will be a buffet setup in a dedicated cafeteria. We will have entrees on the buffet that are for vegetarians or non vegetarians alike. It will likely be a pasta main course of some sort with a choice of protein to go.
• Time To Network – No more grabbing a slice of pizza and rushing to a vendor session or spot of floor to sit. We’ll have a full cafeteria that can fit us all with enough time to get food, network and chat during the lunch break.
• Vendor Sessions BEFORE lunch – We are still finalizing the schedule but it is looking like we will have our vendor sessions in the regular session rooms before the lunch begins. This means our Gold sponsors get fuller attention, people aren’t leaving right after lunch and missing vendors. It also means the sponsors can go eat with the rest of the attendees or man their tables during lunch.
• Hotel Built In – Coming to speak? (Speaker submissions are due by Friday 2/18/11 end of day so get it in now if you haven’t!)  Coming from out of town to attend? why not stay at the built in hotel? Parking is in a garage at the center, the rooms are clean, safe and nice. There will be a group rate (still working that out) for the SQL Saturday event and the rooms all include a hot breakfast (hopefully there will be Bacon). There is a lounge serving food and drink open at 5 each evening for hotel guests also. No more driving to the center or waiting for a shuttle, just roll out of bed, down an elevator and into your room and you can start speaking.
• Help – The staff at the conference center have the rooms setup and broken down. They setup the registration tables before we get there with our attendee bags. They have AV extras available, staff to move chairs as needed, etc. This means we can focus on providing a great event, making sure schedules are running properly, etc. instead of rushing around for food, drinks, plates, napkins, etc.
• Networking – Not just at lunch but the whole design of the center (the courtyard, the lounge downstairs for after the event if you want, the time for lunch, the snack wings, the spacious lobby, etc.) is setup for you to chat with other people who do the same kind of work you do. Great time to exchange business cards, get to know others in the area and make lasting connections.

It isn’t just the location

Take a look at the speakers who have submitted so far. We have some top name speakers interested in coming to visit Boston in April and speak, unpaid, about something they are passionate about. Lots of MVPs, lots of known community names, lots of talent and knowledge. This will be a day packed full of learning and growing and I am really looking forward to seeing the SQL Server community in New England treated like Kings and Queens through the learning and the environment we are striving to create. My only fear is we are setting a bar to try and afford to reach next year

We are also working on a fun event for the speakers. Not details yet, we want to make sure we can work it out but if it works out it will not just provide food and conversation but some fun memories for you. Tom is working some details out on that and we are crunching numbers to see if it can happen. I think you’ll like it.

This isn’t free -

We have a lot of excellent sponsors stepping up to the plate in big ways and I think the venue change will really be a benefit to them as well. You’ll see their logos on the event bags we hand out. You’ll see them on signs, in mailings, speaking during the vendor sessions (and many sponsors are sending experts to give community sessions not about their product also) and manning tables. You’ll get to put raffle tickets in on some really nice giveaways. You’ll get to have a relaxed lunch with good food. This event is very much not free and we’ll have to cap the number that can show up (still too be determined on the exact number, we have flexibility here) so you have to sign up today. We will have to turn away walk-ins and need to be able to get a somewhat accurate head count for the conference center closer to the event. If you want a free day of learning that will boost your career, go to our site and sign up now before we have to implement the waiting list. Also when you are here, visit the sponsors. These are people who care about helping put on great events like these and they have a lot of interesting products and services to offer.

While still borrowing from the titles for my series on why you should blog and some tips on how you could get started blogging I want to follow up to my earlier post on why should be speaking with some tips on how you can get started.

Hopefully you read the first post and have decided to give presenting a shot. Even if it is to coworkers in a brown bag lunch setting, it is great to see you wanting to share your knowledge with others. It’s one of the things that makes the SQL Server community so great.

In this post, I hope to give you some tips that have worked for me, some links to resources that helped me out and maybe answer a point you are still a little nervous about. This isn’t going to be an exhaustive list but the points are the ones that helped or would have helped me. Please add your tips own in the comments if you have something  that works for you.

• Don’t worry about it – I touched on this a lot in the why post. Remember the audience is likely to start out on your side, they are there to learn, they saw your abstract and want to hear you speak on the topic. You start out in the neutral (at worst) or win (at best) column when you get in front of most groups.
• Topic selection – I touched on this a bit in the last post also and Joe Webb left a comment with a blog post he has on topic selection and abstract preparation. Read his post. Biggest point to me is pick something you are interested in, know about and feel comfortable talking about.
• Where? Start local. I started by giving talks to developers I worked with on performance minded development. I went to local User Groups and SQL Saturdays after that. I felt comfortable enough to submit to the SQL PASS Summit for 2010 and was accepted as an alternate (and ended up being asked to speak at the last minute). I am one of the selected speakers for the SQL Rally in the Professional Development track also. Remember what I said in the first post – I am that shy kid who failed communication class, the one who refused to talk in meetings and when forced to my voice trembled with fear. I am really excited to be heading to the SQL Rally to present, what I hope will be, a fun and important topic. I got there by starting small and building confidence.
• I use a blanky – Seriously. My logitech wireless presenter clicker thingy is my security blanket. It keeps at least one hand from fumbling aimlessly (well sometimes they still fumble). It gives me the ability to walk around and interact with the crowd through body language and position.
• Speaking of moving and “interacting” bodily – I don’t care how nervous you are. If you stare at your slide deck with a closed stance towards the audience and talk to your shoes or the ceiling, you’ll lose that friendly crowd I told you about. I have seen really smart people give presentations like this and it kills any interest usually. Have a non verbal dialog with your crowd through-
  • Keep your body open – You can look at a slide deck or whiteboard a minute but when talking have your face and body towards the audience. Closing yourself off (showing your shoulder, shrinking into a ball, etc.) is what you do when someone is about to attack you. You are telling your audience that they are attacking you and you are scared. Face them. Have a welcoming posture and attitude.
  • L-l-l-l-look at people – Now I don’t mean stare one person down. I don’t mean constantly scan eyeballs like you are seeing other people for the first time. While you present your points make meaningful eye contact with your audience. Stay with one person for a complete thought before moving on.
  • Talk to your allies – Sometimes someone will zone out and the eyes look lizard like when someone is in that about to fall asleep state while in the audience. Sometimes people will look frustrated. Don’t waste your eye contact there. Find those who are showing you interested body language. Find the people with good questions and interaction. Find the people you talked to before the presentation. They are even more on your side and it’s okay to spend a little more eye contact there for a confidence boost.
  • Work the room – Speaking of the above point – Don’t just get to your room, nervously fumble through your slides, gulp water and avoid eye contact with the crowd until your presentation starts. You’ll look nervous, scared and unapproachable. Just the kind of person folks don’t want to give their attention to. Come prepared already and say hello to folks. Be real – Be You! If you are a joker, then  joke around;  If you are serious, ask some questions of folks and learn about them; etc. Basically get to know your audience and let down your guard and let them get to know you.
• Come prepared – I tend to do some of my most creative work under intense deadlines. I do wait until too late (for some) to take an abstract and turn it into the presentation I’ve been chugging through in my head. I always still leave time to prepare, learn my slide transitions and really think about what I want to say. I spend a lot of time on knowing what I want to say where and what the main point is for each section.
• Don’t memorize – You aren’t giving a speech written for you by a team of speech writers (and if you were you’d have a teleprompter anyway). You are trying to teach people something you know about (topic selection) and something you prepared for through research, study and crafting a presentation. Don’t read from note cards written in your brain! I have one presentation I’ve given a lot and it is different each time. Yeah I have some jokes that come out the same in most deliveries, that’s okay. The minor content changes each time, though. I mold my presentation to questions, audience response and puzzled looks and change how much I talk about each major point I wanted to make. I know my slide transitions and memorize what I generally want to say before switching the slide. Especially on my presentations where I have a lot of pictures as slides instead of words.
• Got feedback? – Seek feedback. I use speakerrate which is great when people give feedback. Looking at feedback forms (sometimes you have to bribe for feedback forms filled out). Ask friends (who aren’t afraid to be blunt with you)  to sit in a session. Ask others who share with the community to provide honest feedback. Look at it and look for the ones with comments (negative or positive). Find out what worked and what didn’t work and make adjustments if you believe they are warranted.
• Keep doing it – The first time I presented to non co-workers was at a SQL Saturday in Waltham and I was nervous. It didn’t feel great. If I wasn’t scheduled to talk later I don’t know if I would have kept going. The second talk I gave had more people and it went better. I decided to give a SQL Saturday in Charlotte a shot and got some really positive feedback (honestly surprised me) and I just kept plugging away.
• Have pride in yourself but no pride – Have pride in a job well done on the preparation and work like you want to really teach folks and be motivated by that. Let go of your pride in other ways, though. Learn from mistakes, learn from feedback and stay motivated by sharing knowledge with others and you’ll do just fine.

Again I could keep going but this is already pretty long. I’ll leave you with a couple books that were recommended to me and I’d recommend to you as they did help me and still do:

• Made To Stick, Why Some Ideas Survive and Others Die - I reviewed this book earlier. It is a great book that investigates why we can remember the details of an urban legend better than we can critical lessons we learned in school. They analyze the main points of ideas that work and stick and show us, as teachers, marketers, employees or presenters, how we can help leave sticky ideas.
• Confessions Of A Public Speaker – This is a raw look at public speaking from someone who has done quite a lot of it. He shares his stories (including some horror stories) and a lot of tips on how to be successful.

And Remember… Presenting is a lot of fun. It really doesn’t seem like that is possible until you’ve done it a few times and interacted with good material and a great audience (regardless of size). The professional development presentation I am working on that analyzes real world disasters for lessons to the IT field is one I am excited to give at the SQL Rally. Instead of being nervous while working on this one, I am excited to look at some disaster causing attitudes and situations and see people hopefully take something away from the conversations. It really does get fun.

Kind of like some previous common sense posts inspired by mundane tasks (Day Job Tips learned from the garden, a dump trip, etc.), I was hit with another blog thought today. This goes well with my post – Plan To Fail or Don’t Expect To Succeed.

The Illustration

There is a blizzard heading my way tonight. Actually as I type it is here with the snow picking and wind picking up.

Snow Is Starting - One of the wood piles

Pre-Winter was good this year – No storms to speak of until now. Some pretty cold weeks (1 cord of word done already) nothing bad. As a result, I’ve been slacking off with pre-winter chores (cleaning up yard, plastic sheeting around chicken coop run, piling last of wood, prepping driveway for plowing, etc.). I Saw the forecast and hit overdrive last night (Christmas night), Friday when I could (Christmas Eve) and then today (Playing with the kids after Church day) finally doing what should have been done for awhile.  Add on a last minute trip to Wal-Mart before church (when I could have been helping corral kids)  to get a new shovel, Heet for the Generator and gas that should have been bought already.

End Result? Pulled muscle in arm throwing wood around hastily, less time with kids on long weekend, added stress to holiday preparations, added stress for wife, not everything as I had hoped (couldn’t move a small maple tree I should have replanted this fall because its bucket is one with the ground and will soon become one with the plow in all likelihood) and other consequences.

Here Comes The Part When I Preach To Myself

You know the disclaimer I give here if you’ve read the other posts.. This is advice that applies mostly to me but may help you:

How ready are you for dealing with a disaster at work??

• Have you practiced your restores lately? (ever??)
• Do you know what your SLA for recovery is?
• Can you meet it?
• Do you have the environment and configurations documented?
• Have any checklists to help get you through disasters of different varieties?
• Those sprawling DB instances… Know who owns each database on them? Know how to reach them?
• Have you been keeping up with your skills? Do you have a network of resources and escalation points (MS Support? Twitter #sqlhelp hashtag? SQL Server Consultant you know and trust?)

How close are you to causing a disaster at work?

• Are you performing regular maintenance?
• Doing DBCC CheckDBs with it?
• Have a good monitoring application installed?
• If not, are you at least checking logs (SQL, SQL Agent and Windows Event at least) regularly?
• Do you have a solid code review and release process in place?

Carry On

That’s it. Don’t be a heel like me and wait until the last minute. You already spend enough time in the office. Don’t call your family to say you are going to be late, “eat supper without me”, because you didn’t avoid a disaster through proactive work.