Category: Professional Development

Apr 15 2014

SQL Server First Aid

10884793236_16744ca395_mIf you take basic first aid, say a CPR course, you’ll learn a handy mnemonic for the primary assessment you have to make, A-B-C. That breaks down as Airway, Breathing, Circulation. Is there an open airway so they can breathe? Are they breathing? Do they have circulation, a pulse, are they alive in short. I recently took a two day course on wilderness first aid (on top of CPR training and first responder training and basic and advanced first aid training and Scout training and Scout first-aid training and I’m sure I’m forgetting some) that added to that, D-E. We now have Disability and Environment. In short, just how responsive is the person or do they have the possibility of spinal issues? What’s the environmental situation, lieing on cold ground, in the rain, on a boulder, in a crevasse, etc. And that’s just for the primary assessment. Then there’s the secondary assessment.

I’m not going to attempt to regurgitate the class here (go here if you’re interested). But it got me thinking, could we come up with a primary assessment for SQL Server that is also predicated on simple concepts that we could use to focus our assessment when dealing with SQL Server issues? The obvious answer is yes, but then, how well will it work? I’m pretty sure the shockingly simple, while simultaneously complex, ABCDE for assessing patients went through a lot of rounds to arrive at the current version. So, here’s my idea. I’m going to do a pass at this. I’ll lay out my first thoughts on coming up with a primary assessment, and then, I’d love to see others take it and run with it. Maybe we can turn it into a WIKI or something. But I can see it as a foundation for a more systematic approach.

Let me lay a few ground rules. First, this is the primary assessment. This is the “let’s see if we can keep this person alive” moment. They may have tons of cuts and scrapes and messed up hair and horrible taste in clothing. We can get to all that later. Right now they’re laying on the ground and we need to determine if they’re napping, getting ready to start screaming, unconscious or just dead. So, let’s keep that concept in the front of our brains as we think through what we need to get the patient/server away from FTD (“fixin to die” I love the black humor that EMTs and police have) to either completely alive again or at least limping along. No query tuning (as much as I love it) or questioning people’s database design choices (as silly as they may be) or even finger pointing (yet).

Second, let’s try to stick within the mnemonic as much as possible. So ABCDE. If we determine a need for an F & G as part of the initial checks, fine. And, we have the whole secondary checks to do so there can be any number of fun mnemonics or other memory devices or whatever. But we’ll leave that for the nonce. Primary checks.

Here’s my first pass (I’m skipping survey the scene, the real first step, maybe that’s wrong, let me know):

A: Availability – Can you ping the thing? Is there a network around it that is online such that you can get to it at all? If you can’t, chances are no one else can either.

B: Basic Connectivity (yeah, it sucks, see above) – Can you log in? Can you use the DAC? You can see the server, yes, but can you get to it?

C: Circulation (sucks even worse) – Are there blocked processes (yeah, it should be “B” but that doesn’t feel like the right order to me)? Are you able to query the system and get a response?

D:  Database – Are the databases online? Are there issues around databases? Did you run out of space on the log or data file?

E: Execution – Are we looking at some sort of query issues? Permissions, performance, etc., that is affecting general availability.

Yeah, I know. This is pretty weak stuff. I’m absolutely just putting thoughts into words and letting you see the process as it unfolds. Remember, as a DBA, chances are very good that you’re a first responder. You need to know what to do. Show me where I’ve gone wrong. Feel free to write your own blog post in response. Create a presentation with this idea. I don’t care, just let me know what you’re doing with it so I can try to update and expand on the idea. Could we incorporate existing resource such as this awesome book? Anything and everything. This is an open idea that I’m passing on to see if it has legs. I think it might, but then again, I couldn’t believe that everyone didn’t own an Axim.

Apr 14 2014

Sharing a Good Idea

I posted earlier about my experiments with Microsoft Curah!. (yes, technically the period should follow the exclamation since the exclamation is part of the name, not the end of the sentence) Evidently people actually read this blog because it inspired Stephen Bennet to start putting together his own curations and collect them on his blog. I think that’s a pretty interesting idea. I might try it myself (after I get back from SQL Intersection). Stephen’s Curah! so far.

Oh, and I kind of dislike the name. Curah! Just typing it I feel like I should be excited except I’m not. Anyhooo…

Apr 04 2014

Speaker of the Month, April 2014

I’m really enjoying picking a speaker of the month. It forces me to sit through a lot more sessions at the events I attend. I had been getting rather slack about attending sessions. It’s easy to get caught up in networking so much that you’re not taking advantage of the learning opportunities. This month we’re on to the East Coast to pick a speaker from the Boston SQL Saturday event. The talk was called, “What I Wish I Knew Before Becoming a DBA.” The speaker of the month is Mike Walsh (b|t).

Mike’s session was just a general discussion about the job of being a DBA. He didn’t get into a lot of technical detail. Instead it was like a conversation with your friends talking about personality traits, work/life balance, restore plans, all good stuff. I especially enjoyed the emphasis he placed on practicing our skills. It’s not enough to know how to do a point in time restore, you need to actually run through it a few times so that when the CEO is standing in your cube, you get it right. I also enjoyed the concept Mike put out that DBAs are advocates for the data. He suggests that a DBA should think that “developers want to mangle the data, vendors want to steal it and managers want to lose it.” I think that’s probably unnecessarily harsh, but it gets the point across. I enjoyed when Mike put little faux SQL statements on the board for a topic. It communicated the point while still being fun. Many of his slides were bare, almost Spartan, but they worked well with the general discussion format that he took.

In fact, I enjoyed the spare slides so much, that when he introduced some pictures, it felt kind of jarring and I thought it took away from the approach he had been building on pretty well. Also, maybe a few extra slides would help the situation. Sometimes Mike would get on a topic and stay there for a while, but his talk would stray a little to far afield from the topic listed on the screen. Having a few more slides might help there. Also, some of the topics tended to meander a tad. While I really did enjoy the conversational style, I think Mike would only benefit from a little tighter focus on the subjects at hand.

It was a session well worth attending. The people in there seemed to enjoy it as well. I’ve no idea where else Mike is speaking. I don’t see anything on Lanyrd or on his blog. Keep an eye out for him and check out the session, especially if you’re just getting started as a DBA.

Mar 07 2014

Speaker of the Month, March 2014

This never gets easier. I was able to attend a bunch of sessions in the last month from a number of speakers that I’d never seen before. A lot of them were good, very good. In fact, I’d go so far as to say I think the general level of speakers within the SQL Server community is improving. Which means we’ll all need to up our games. I also saw several that I’ve seen before because I always learn from them. In short, my cup runneth over. Anyway, the person I picked this month, well, I’d never seen him present before. But, I have hung out with him. He’s got this incredible, fast, sharp wit and he’ll protect you from dangerous objects in orange. I’m picking Mark Vaillancourt (b|t) and his session Danger: The Art and Science of Presenting.

I’m so glad I went to this session. If I learned nothing else, it’s that I have a gut because I present. You see, a fight or flight emotion, which takes place in front of people, tends to spike insulin, leading to increased fat storage. If I just stopped presenting, I’d be skinny again… well, skinnier. But, let’s focus on Mark’s session. You see, he wasn’t kidding when he said Science in the title. There was tons and tons of discussion around the science of presenting, mostly focused on how you, as a presenter, are dealing with this situation, methods you can use to control your breathing, your focus and all that sort of stuff. Yes, he talked somewhat about good practices on slides & such, the Art aspects. But the main focus was on the science and it was fascinating. Instead of the approach so many people take towards a session on presentations, “Here’s how you do it,” Mark gave us a lot of detail on how the process of presentation works. You can figure out how on your own from there. I love the breakdown on the topics between self perception (figuring out how you’re doing), self expression (figuring out how to get across what you want to get across), interpersonal (how to deal with your audience), stress management (figure that one out), and decision making (literally, thinking on your feet as you present). Mark chatted up the crowd before the session. He had amazing delivery, which you’d have to in order to make a session like this work, and his wit was on display throughout, although it was very controlled and focused and never overwhelmed the presentation. I really got a lot out of attending the session.

My feedback has two points. Mark really didn’t repeat the questions. It was a very small room, but people can be so quiet and if they’re talking away from you, you may not hear what they say. This one is so hard to do (it’s one of my own goals to improve my presentations), but it’s vital. Second, Mark’s funny. He put bits of humor in the slides with pictures and titles and he cracked jokes as he presented. Again, this in no way hurt the delivery. It enhanced it in every possible way. But, for a lot of his humor, he stopped and quickly explained what the joke meant. I’d say, have less obscure jokes that don’t need explanation, or just let them stand. Those who get them, great. Those who don’t oh well. It’s not going to enhance the joke to the people who get it and the people who don’t won’t laugh at the explanation. But that’s all I’ve got. It really was a great presentation.

Mark posts upcoming presentations on his blog, but I don’t see any listed currently. He’s not listed on Lanyrd (and if someone has a better place to record upcoming events so we can all share them, I’m open. Until you supply me with an alternative, we should be using Lanyrd, and no, I’m not getting cut backs or anything). Anyway, congrats Mark. All the cash, gifts, slaves and other associated paraphernalia traditionally associated with this award are winging their way towards you now.

Feb 27 2014

Let’s Talk Query Tuning

I spend quite a bit of time writing about query tuning on this blog. I’ve written (re-written and am actively re-writing) books on query tuning. But what I like most is talking about query tuning. I love giving sessions at various events on different aspects of query tuning, but, what I like the most is spending a whole day, trying to do a complete brain dump to get as much information out there as possible. Sound attractive? Then I’ve got a great deal for you. Come to Louisville on June 20th, 2014. We will talk query tuning at length. You have a specific question? Let’s get it answered. Then, the next day, we can all go to SQL Saturday 286 there in Louisville to get more learning and some serious networking. What’s not to like?

Feb 25 2014

Approachable? Sometimes.

Deservedly so, I got called out for a bit of attitude I displayed in a recent blog post: Time for a Quick Rant. Steve Hood took the general attitude of “Do this or I will beat you” to task in his blog post The Approachable DBA.

Granted, my little rant was primarily done tongue wedged immovably in cheek. But I was reflecting an attitude that the gods know I’m guilty of and that I think way too many DBAs are guilty of. Actually, I think developers are just as guilty. And sysadmins, san admins, support desk people, QA, the report writing team, those people supporting the data warehouse certainly, the SharePoint team, and that poor lady who got stuck being the Deployment manager.

That attitude? I don’t think you heard me the first couple of (eight thousand) times I said this, so I’ll say it a little louder… with emphasis… at length… weapon in hand (figuratively, of course).

I have never, ever, put my hands on someone in anger in the workplace. I don’t threaten people in the workplace either (there was that one time, but that guy had it coming). But I am guilty of the extended and repeated rant. While it might actually be cathartic for me, it doesn’t help anyone else at work. More importantly, it doesn’t help you with your leadership position at work.

Leadership? Most of you just held up a sign to ward off evil. “I don’t want to move into management.” No. That’s not what I mean. I mean leadership, not management. Why do we go off on these rants and tears? Speaking for everyone (’cause I can, my blog, my rules), we want to be able to positively influence the decisions made within our company and we’re right (most of the time, or, well, often enough), so when we have to deal with concerns like, “Hey, that restore you ran left off a row” we launch into what is practically a canned recording of “Restores are a bit-by-bit copy of the database at a given moment in time. I can’t possibly have missed a row. How many times do I have to tell you? Look, here’s how it works…” And we’re off.

Where was I? Oh yeah, leadership. It’s not about management. It’s about having influence, setting direction, getting things going the right way. In order to really do this, you can’t just bark at people and figuratively shove them around. You must be approachable. In order for them to hear you, they must listen to you. If all you are is shouts and threats and rants, you will not be able to lead.

I think Steve is right. There has to be a level of approachability that we have in order to establish the trust we need to put ourselves in the place we need to be to make a positive impact. Just don’t ask for access to production again, or I’m getting the hose out.

Feb 05 2014

Book Review: The Phoenix Project

Let’s get this straight right up front, the thought of reading a novel that’s about IT is so repellent, so repugnant, just so horribly wrong, that it’s kind of hard to fathom why I would even attempt it. What’s even more difficult for me to fathom is how much I enjoyed this book. Which is a novel. About IT. I can’t figure it out. Maybe I need to start reading more IT novels… no. Let’s hope that’s not actually a thing. On with the review…

The Phoenix Project is a story about a mid-level manager in a large company who has been running part of the IT organization that is a bit of a backwater, maintaining old big-iron systems, VAX, that type of thing. He gets called into the CEOs office and is made VP of IT Operations. But it’s a company that, from what I can tell, has done just about everything it possibly can do wrong in IT. It’s actually quite frightening to read through. I kept flashing back to some of my own experiences and some of the “interesting” choices made by the people running them. I won’t bore you with the entire plot. The gist of it is, things are awful, our hero goes on a quest, vanquishes a dragon and gets the girl. Well, anyway, the IT operations management version of a quest and a communications & process dragon and he was already happily married so there was no girl to woo, but hey, the good guys win, eventually. I won’t reveal anything else about the novel itself. Go read it.

The Phoenix Project is not simply a book though. This is meant to be an introduction to a concept. That concept has a name, frankly, one I hesitate to use because it outright smacks of catch-of-the-day marketing speak, but it does have a useful shorthand ring to it: DevOps. That’s right. This is a book about getting developers and system administrators and DBAs and support people and auditors to hold hands and sing songs. Well, or, just maybe work together in a more efficient and useful fashion. The thing is, it makes sense.

The book lays out all the issues that come about when IT & Devs don’t get along. Each side feels as if the other side is just simply out to get them. Weird rituals get established to hand off software between groups rather than working with each other right from the start of development. The book really rings true. You get a sense that the people who wrote it have been there, and done that, in regards to watching IT shops suffer. Fact is, they have. Gene Kim, Kevin Behr and George Spafford are IT pros and consultants. They’re coming from knowledge and understanding of the suffering that occurs daily within lots and lots of IT shops. They’re making an effort to reach out, to help out. The Phoenix Project is part of their efforts to grab the attention of as many IT people as possible.

It works.

I spent years at my previous job trying to do a better job interacting with the development teams (I’m sorry to say, to mixed results). But I recognized that was what was needed (even if I wasn’t the right person to make it happen). Since starting my other job, we’ve been even more aware of just how important it is for developers and DBAs and all the other IT specialists to find mechanisms to create a straight path from development to production. It’s something we have to do in order to make our businesses that we support more able to respond to the shifting business environment in a (pardon the word) agile fashion. It’s about working towards Continuous Delivery (another book I’m starting). It’s about, until we get a better word for it, DevOps.

This was a good read. It was also a quick read. I finished all 300 pages in about two days. I liked the characters and enjoyed the storyline. Yes, it’s a little simplistic at times. I also got extremely irked at the Yoda character on several occasions (mostly for acting too much like Yoda). No, it’s not SF, but you’ll know the character I mean. I also thought the villains of the book did a little too much mustache twirling. But remember, this is more of a parable than a novel. As a parable, it works. You’ll get the message, and I think it’s an important one for IT people to get.

Jan 20 2014

Time for a Quick Rant

This is an actual quote from what we can only assume is a functional human being:

The database is very big so we stopped taking backup’s.

Eight lords a leaping are you kidding me? Seriously! Seriously? By the Great Gu and all the Valkyries in Valhalla, you stopped taking backups of your PRODUCTION database because it was “very big.” And I’ll put down Brobdingnagian stacks of cash that “very big” in this case is probably 200-500gb or at worst 1-2tb. People, assuming you have enough brain stem intact to regulate breathing, you must know, you must by all the sparkly vampires in Twighlight KNOW that you need to have backups. Right? I mean, nothing ever goes wrong on this shiny marble we call Dirt, does it? No one would EVER just run a DELETE statement in production without a WHERE clause, would they you hairy bottomed tree climbing mouth breather? And I’m sure that, if it happened, you could just blow magic unicorn powder at the server in order to get the company’s billing list back, right? Because without that backup, you’re relying on the undivided attention, and total positive intent, of Odin and Freya to ensure that you never, oh, I don’t know, lose power causing the rocker arm on the disk to bash down repeatedly on the platter like Thor’s Hammer on an Ice Giant’s head, with similar results for your database. Until you have so much data that EMC hosts your company’s holiday party, for free, there is enough disk space, somewhere, to take a backup of your database.

Now, get out there and get it done. Don’t make me travel to each and every one of your places of work with the lead-weighted hickory learning bat to lay some education up side your beanie holder. Please, just take a backup.

I really mean it this time. Backup your database

I really mean it this time. Backup your database

Jan 08 2014

Sausage Making

For those who don’t know, I work for Red Gate Software. I’m not a developer, but I work directly for the development teams so I spend a lot of time with them. This week I’m over in the UK, where they are headquartered, meeting with the different teams and discussing our products, their future, issues with them, enhancements, and all the rest. Suffice to say, I’m excited by the future.

But the really fun bits are when you see behind the scenes stuff. Red Gate is pretty well known for polished, intelligent, elegant UI design (yes, they keep me away from that stuff). Behind those pretty pictures though is code. And our developers are just like your developers, smart, capable, skilled, but still learning. And it’s those learning bits that are the most interesting.

Now, I’m not going to tell tales and get myself in trouble (I’m just recording everything for the massive tell-all when they inevitably fire me, HA!). But what I’m fascinated by is the fact that, despite the incredible skill of the developers here, and they really are damned amazing, they are all dealing with loads of code debt. Don’t know what code debt is? Sure you do. Everyone has it. Remember that time you thought that you could massively improve performance and maintenance by using a single lookup table for all the database rather than a large series of tiny tables? Don Peterson (he doesn’t blog or tweet, he just is, like Chuck Norris) coined the phrase Massive Unified Code-Key table (MUCK) for this design. Remember the intense pain it caused you? Remember how you then had to live with that design choice for years and years? Yeah, that’s code debt. Well, we have it too.

The thing is, you have to pay for code debt in some way. TANSTAAFL always applies, right? So you pay for it through maintenance over time, or you pay to replace it, but it doesn’t go away. Well, we have code debt that we’re paying to replace on several tools, and I’m wicked excited to see it getting taken care of. I’d say it’s a sign of maturity that an organization is not only able to recognize the debt, but is able to determine that NOW, right NOW, is the time to get rid of what had simply been a long-term irritant. Far too often we kick the can down the road and worry about what to do about it later.

Your homework: Identify some piece of code debt that you’re currently paying off. Determine the amount of pain it’s causing you. Calculate if that pain is increasing or remaining constant (it’s almost never decreasing). If it’s increasing, when will that NOW moment occur for you that you will absolutely have to fix it? Got all that? Cool. Now present it to your boss and see if you can’t pay off a little of that debt. It’ll be a great test of the maturity of your organization.

Jan 03 2014

Speaker of the Month, January 2014

A whole new year. Cool.

I was at SQL Saturday DC, #233, at the beginning of December. I sat through several really good presentations. I could honestly give the award this month to any of the ones I took notes on, but I have to pick one person (although, not always, my award, my rules). So, speaker of the month for the brand new year is Konstantin Melamud (li|t). Yet another speaker without a blog. Maybe I should enforce my own rules at some at some point. <sigh> Anyway, I enjoyed Konstantin’s presentation. Let’s talk about it.

Performance Tuning – Index Optimization was an excellent presentation. Konstantin came at the topic very carefully. He started off with a knowledge level baseline, right at the start. I thought that was a pretty good idea. It let people level set from there. He then went through each index, provided a good definition of the index, then discussed information about it, tradeoffs, suggestions. It worked really well as a format for approaching the subject. He did things I wouldn’t necessarily have the guts to do, including doing a pretty good demo of full text search. Throughout the presentation he checked to see if the attendees had any questions. He even had a “I know more than you do” questioner who Konstantin handled professionally. It was a good presentation giving out good information (with an exception that I’ll point out below) that was really well presented. Konstantin’s delivery was very soft, quiet and comfortable. The way Konstantin answered questions and discussed the topic with people he demonstrated a great grasp of the topic. I’m sure people left the presentation and put some of his suggestions straight to work.

The stuff Konstantin could work on is the same stuff that many speakers (including me) need to polish. He didn’t repeat the questions. Even though it was a small room (packed to the gills, standing room only I might add), the acoustics were pretty terrible, so a question from a woman sitting directly in front of me was unintelligible. I’m sure people in the back never heard it. A few of his demos tanked because he didn’t reset after testing them earlier in the day. Understandable, but avoidable. He had one demo using clusters that basically implied the old saw that clusters are best for range data retrieval. I’d suggest changing that demo (and don’t trust me, talk to Gail about it). That’s about it. Like I said, a good presentation.

Once again, no way to determine where Konstantin is speaking next… Help me, help you… Where was I? But, I would absolutely recommend you track him down for a presentation.