THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Adam Machanic

Adam Machanic, Boston-based SQL Server developer, shares his experiences with programming, monitoring, and performance tuning SQL Server. And the occasional battle with the query optimizer.

  • SQLCLR Performance Session at TechEd US

    I am super-excited to visit New Orleans next month for Microsoft TechEd; it will be my sixth time speaking at the show.

    My session takes an in-depth look at some of the techniques I've developed for using SQLCLR modules -- and some of the great performance gains I've been able to achieve.

    Hope to see you in NOLA! If you're not attending the show, the video will be available on demand a few days after I give the talk.

  • More Fun in Atlanta: Parallelism at SQL Saturday 220

    May 18, SQL Saturday returns yet again to the Atlanta area. At this point I've become a bit of a regular at Atlanta's events; this will be my third one in a row. The team that puts them together is amazing, and produces top quality, super fun and educational days every time. Plus: Taco Mac.

    Friday, May 17, the event is running a few pre-conference seminars, and I'll be delivering one focused on parallelism in SQL Server. This is an updated version of the seminar I delivered at the 2010 PASS conference; you can read Kendra Little's review of that day on her personal blog, littlekendra.com.

    To get full information on the Atlanta seminar, visit the EventBrite page for the event: http://surfmulticore.eventbrite.com/

    Any questions? Let me know in the comment section.

    Hope to see you there!

  • Capturing Attention: Writing Great Session Descriptions

    keynote2One of the best ways we can differentiate ourselves and further our careers is to get out of the office… and onto a stage. Presenting can give you name recognition; open doors to new opportunities; help you gain a deeper understanding of technology (teaching a topic often forces you to learn it at a much deeper level); and for many people it's simply a fun and satisfying pastime. Each year there are dozens of speaking opportunities available to you: brown bag talks at your workplace, local user groups, online (virtual) user groups, community events, and conferences, just to name a few.

    Virtually every speaking engagement, no matter how large or small, has something in common: attendees want to know, in advance, what is you're going to be talking about. They want to know whether they should spend their valuable time watching you, watching some other presenter, or perhaps staying at home and catching up on some sleep. And attendees will make this decision based upon an all-important document, the session description.

    I've been speaking publicly and running events for just shy of 10 years now, and in that time I've read thousands of session descriptions. Some were decent, some good or even excellent, and most were very, very bad. I've also seen a lot of potential speakers--many of whom had extremely interesting topics and content--get rejected by events because they made basic mistakes in their session descriptions.

    Writing a great session description is hard work. There's no way around it. But it's work that you need to do if you want to become an accomplished public speaker, especially at competitive events like large conferences. I like to think that I've done pretty well in this area, so in the interest of reading much better descriptions at upcoming shows, I'd like to share what I've learned over time: what matters, and what doesn't, when it comes to describing your sessions.

     

    Overview

    To begin with, what is a session description? I struggled with this one a bit; I wanted to talk about abstracts, titles, and levels all in one go. I decided to group them together under the umbrella name "session description." For the rest of this post, when I refer to that term I'm talking about all three parts. When I want to talk about only one of the components, I'll refer to it separately. Let's do that now.

    An abstract is a paragraph that is supposed to describe what you're going to talk about in your session.

    A title is a small number of words that are supposed to describe what you're going to talk about in your session.

    A level is a number that's supposed to help guide who should (and should not) attend your session.

    Another definition is also in order, and that's for the word great, which I've used in the title of this post. Greatness is, naturally, highly subjective. So for the purposes of this post I'll define a great session description as one that, for the correct people, captures their attention, whets their appetite, and makes them actually want to see you talk. That's kind of the point of the whole thing, right?

     

    enrapturedYour Audience and The Real Goal

    Before you begin working on your session description, it is important to realize what it's going to be used for. Your session description is for attendees. It's for the event organizers. And it's also for you. It has three purposes in life! These are not necessarily conflicting purposes, but you should weigh each of them carefully before writing.

    Attendees will use your session description to decide whether they want to attend your session.

    The organizers will use your session description to decide whether to give you a speaking slot.

    And you can use your session description to set expectations and keep yourself constrained.

    Your session description is, first and foremost, a piece of marketing collateral. You are selling a product: your session. You must first sell it to the organizers. Then you must sell it to attendees. Then you must deliver what you sold. If your text underwhelms you will fail to get the chance to deliver or fail to attract an audience. And if you oversell you will end up creating promises that you can't keep or risk attracting an audience that may not appreciate your work.

    Sales is all about understanding the needs of the people you're selling to, and solving their problem. To sell to the organizers, try to understand the mission of the event and fill appropriate gaps. To sell to attendees, try to understand the audience you're targeting, and write a session description that will help them. These two things are not at all independent of one another. Submit sessions to events that appeal to the attendees you hope to speak to; there is no real benefit in attempting to get yourself booked for inappropriate venues.

     

    You Are Not Your Audience

    Remember this always: most normal people attend technology events on the premise that doing so will make their lives easier by helping them learn to do their jobs better. Most people who work for a living do not care about technology for the sake of technology. They want to solve problems at work so that they can collect a nice paycheck and enjoy life outside of work. Most people are not at the event because they're ubergeeks. Most speakers are ubergeeks and forget this. If you're reading this you are probably not normal.

    What does this mean for your session? As a presenter, you're much more likely to have a successful run of things if you target the majority of the potential audience, rather than a small niche group. This means helping all of the "normal" people. Don't get me wrong; these may be very technical people who are advanced technology users. But you won't attract them with pure geekery. They don't want to check out your cool technology, no matter how cool it is, just because it's cool. You need to appeal to their sense of purpose.

     

    Tell a Story

    How do you appeal to your target audience? Easy:

    • Figure out who they are
    • Figure out what problems they need to solve
    • Help them understand that you know who they are
    • Help them understand that you appreciate their problems
    • Help them understand that you can help them solve their problemsdragon

    In other words, relate to your audience, and let your audience know that you relate to them. People like hearing from other people who share similar backgrounds and experiences. And people like hearing stories. Humans have been listening to stories for tens of thousands of years. It's how we're wired. Weave a compelling story and people will want to come and listen to it.

    A great session description is a small story. It's a prelude to the larger story that you'll tell later in your presentation. It's the dust jacket on a great book, or the trailer for a new movie. Each of the three component parts should work together to draw the audience in, get them interested enough to want to keep going, and leave them wondering how the main character is going to escape the fire breathing dragon. A truly great session description will leave each member of your target audience with the understanding that he is the main character, and the fire breathing dragon is the problem he faces at work each week. Accomplish that and audiences won't be able to stay away from your presentation.

    A common question asked by new speakers is "what should I speak about?" (Alternately phrased, "what should I write a session description about?") The answer, truth be told, is that it really doesn't matter. Or at least it shouldn't matter. Choose topics that you know well, are passionate about, solve a problem for you, and, most of all, about which you can tell your story. Chances are excellent that other people out there feel the same way (or your great session description will compel them to feel the same way), and you'll have no trouble finding an audience.

     

    Your Session Description and the Relative Importance of its Component Parts

    Earlier I introduced the three component parts: The title, the abstract, and the level.

    In theory each of the component parts would be digested together by your audience (attendees, organizers, and/or you) and considered as a single piece of work. In reality that's not what happens. Each of the component parts has its own relative merit, depending on what stage of the game your session description is at.

    Here's how things usually work:

    You, if you're like most speakers I know, will spend some time writing the abstract, then throw in the title, and will hastily tack on the level as an afterthought.

    The organizers will judge you on the title and level (based on what they need for the event) and if sufficiently interested will take some time to read the abstract. Let's assume that 80% of the abstracts get read at this stage.

    The attendees? Depending on the event, many of them will never see your abstract at all, and may not see the level. If you're the only presenter at a user group one evening, most of the attendees will probably at least have the chance to read your abstract. But, you know, TL;DR. People can't be bothered to read a big paragraph full of, like, words.

    The bigger the event, the worse it gets. The majority of attendees decide where to go based on the little printout or booklet they receive when they show up. These usually contain a schedule in a grid format, with only room enough for session titles. Usually levels don't make it to that schedule, and some events don't even include the speakers' names. That means that the entire decision is based on those few words in your title. I would estimate, based on interactions I've had, that only 25% of attendees ever bother reading abstracts.

    The title is the only thing read by everyone, guaranteed. It is, therefore, the most important piece of your session description. The abstract is the next most important, and the level the least important. That said, you should determine the level first. Why? Because the level drives the language used throughout the rest of the description.

     

    Levels of Confusion

    Session levels are, on the best of days: stressful, vexing, misinterpreted, mostly worthless, improperly used, and entirely subjective. Most attendees don't understand what they mean, most speakers don't understand what they mean, and most event organizers don't leverage them very well. The central problem is that a topic that's really difficult for me ("level 500") may be dead simple for you ("level 100"). So what's the point?

    Session levels don't have to be completely useless. They can help you figure out who your audience is supposed to be, and help you properly target these people by using appropriate language.

    confusedMost events--at least in the Microsoft space--use five levels. 100 is supposed to be for the most basic stuff, and 500 for the most advanced stuff (some events, like Microsoft's TechEd show, max out at level 400). Personally, I compress things down and try to focus on three basic levels:

    Level 1: Material for people who don't know much about what I'm talking about (a.k.a. level 200 or so)
    Level 2: Material for people who've used what I'm talking about but aren't experts (a.k.a. level 300 or so)
    Level 3: Material for people who want in-depth details on what I'm talking about (a.k.a. level 500 or so)

    Each level determines not only the content I'm going to present, but also drives the terminology I'll use in how I describe things.

    Consider a talk on SQL Server AlwaysOn. Both the session description and the presentation itself should be aligned for the audience target.

    At Level 1, the talk would describe the basics, starting with what the terms "high availability" and "disaster recovery" actually mean. Perhaps a brief high-level review of various technologies that solve these problems, and a look at how AlwaysOn tackles some of the key areas. The problem this talk would helping the audience solve is how to make sure that databases and their data are available whenever users need them. The story is a tale about technological advances and how easy it can be to keep the data flowing, even in the face of disaster.

    At Level 2, deeper and more in-depth language would be used. How do "availability groups" work, and what general architectural choices should be made? What are the pros and cons of "synchronous" vs. "asynchronous" commit modes? The problem in this case is understanding the complexity of actually using AlwaysOn. The story is about connecting features and options to real-world use cases.

    At Level 3, focused and specialized language is applied. Both the session description and the talk could reference "listeners," "quorums," "replicas," and so on, without any need for explanation. At this level we're usually targeting fellow ubergeeks, so there may be no real problem we're helping to solve. But--as always--it's very important to tell a story to help engage your audience.

    In each of these cases, the appropriate language should be used in both the title and the abstract as needed. This enables each component part to communicate something about the level to the reader--without the reader ever having to actually read some arbitrary number.

     

    Designing Your Title

    So you've decided that you want to do a talk on the brand new, supercool, game changing feature that's going to be released next month. We'll pretend that it's called "Hekaton." (Sorry, but it's not really going to be released next month.)

    To recap, the goal of your title is to:

    • Reflect upon the appropriate audience level
    • Draw in the correct audience
    • Create enough excitement to make them want more

    The average session title submitted for SQL Saturday events (based on a quick perusal of the archive) is around 5 to 7 words long, and that's probably not enough. One of the biggest mistakes I see new speakers making is thinking that a short and succinct title is great. So they submit sessions with titles like:

    • "Hekaton in SQL Server v.Next"
    • "Hekaton for OLTP"
    • "Using Hekaton for Faster Transactions"

    The problems abound...

    1. These titles all use a code word, Hekaton, which only certain—and very specific--attendees will actually know. And they're probably not your target audience, because most normal people don't know the term. (Again, "normal" refers to non-ubergeeks, i.e. people who have a life, i.e. the people you probably want to reach.) At the average conference, attendees can sit through maybe five or six talks each day. So committing to a mystery topic? Think about it this way: If you're looking down at your schedule grid and you see one of these sessions, with a term you don't know, and it's up against a session that appears to solve a problem you do have, which option are you going to take?
    2. These titles feel vague and too general. If someone already knows what Hekaton means, chances are good that he won't bother attending these sessions, because he won't be likely to learn anything new. Furthermore, these session titles don't appear to help anyone solve a problem, with the possible exception of the last one. And that one sounds a bit like it's going to be a sales pitch.
    3. These titles are boring. Seriously. I fell asleep while writing them. If your title bores me, chances are good that your talk is going to bore me. And I don't like being bored. No one does.

    So what do we do here?

    First of all, since this is a brand-new feature that still uses a code word, this talk can't possibly be advanced. Even if you've been in a special early adopter program and have in-depth knowledge, there probably won't be an audience for you. So this is going to be a beginner-level talk, and the code word has got to go. Hekaton is an in-memory database solution designed to help speed up transactions. Can you pull a something from that description to explain the feature in just a few words?

    Second, you need to clearly identify the problem you're going to help attendees solve. Which attendees have problems with transactional latency? Probably those with lots and lots of concurrent database users. And it's probably a good idea to help the audience identify itself as it reads your title.

    Third, you need to get these attendees interested enough to either read your abstract or--for the 75% who won't read it--actually show up at your session just on the merits of the title. This means adding a bit of verve: showing some emotion, exposing your excitement, displaying your personality. Something a bit non-technical to indicate that this session isn't going to be nap time.

    Putting it all together, we can come up with some pretty decent titles that do a much better job:

    • "In-Memory Solutions for Massively Concurrent Database Dilemmas"
    • "100,000 Users and Going Strong: In-Memory Transaction Processing Done Right"
    • "From Cessna to F1: Moving Your Heavy OLTP Workload to Memory and Beyond"

    The code word has been eliminated. The audience can identify itself (those with "massively concurrent" databases, those with lots of users, or those with heavy OLTP workloads; all the same audience, just different ways of addressing them). The titles project a problem and hint at a solution. And each of these titles reads like a human actually put some thought and effort into them. (Well I think so. Nothing like painting a target on my back!)

    The key to all of this? Relate to your prospective attendee. Don't bore them. Help them. And don't be afraid to use a few words to get there.

    As an aside, there's this thing called title case. It's a set of rules for how to capitalize your title, and you should learn it. Failing to properly case your title makes you look like a total amateur.

     

    Writing Your Abstract

    At this point you've identified your attendee target, established a level, and drawn up one or two potential titles. (Write a few of them if possible; don't constrain yourself!) Now it's time to write the biggest portion of the session description: the paragraph-long abstract.

    First things first. All of the rules already described apply here. Tell a story. Use appropriate language for your audience target. Don't be dull.

    A well written abstract should expand upon, and complete, the narrative that the title started. It's the same message, but you have a lot more room in which to deliver it. When I read an abstract I look for organization, flow, and depth. All things that can help me decide whether the session is worth my time. If your abstract is disorganized, doesn't convey a starting and end point, or isn't at the right level, it's going to translate into the audience thinking the same about your talk.

    The biggest sin when creating an abstract? Failure to even try. I've read countless single-sentence abstracts, especially those submitted to small community events. If you can't spend more than 30 seconds writing your abstract, how can I trust you with 75 minutes of my time?

    Don't do this:

    Attend this talk to learn how to use Integration Services in SQL Server 2012 to help with common ETL tasks.

    Did I mock this up? Kind of. I just grabbed a real SQL Saturday abstract (on a different topic) and changed the words around. So yeah, this is essentially real, and every time I see it I cry a little bit, because no one should have so little enthusiasm about his topic and an expectation that he's going to make any audience care. This abstract probably won't fly at SQL Saturday, and it definitely won't fly at a conference. Just don't do it.storyteller

    So what should you do?

    1. Reflect upon the title. Re-state the problem, but in more words. If possible, refer to the audience. Draw them in.
    2. Describe how what you're going to talk about is going to help address the problem. Give them a hook.
    3. Conclude, re-stating the problem and re-affirming the hypothetical solution. Seal the deal.

    A good abstract should, in my opinion, be at least five or six sentences long. Not too long, mind you--you're not trying to write a book--but long enough to thoroughly set expectations.

    Start by reaffirming that the reader is the correct reader. For a beginner-level SSIS talk similar to the one indicated above, I might begin by describing a familiar scenario:

    You have loads of data sitting in flat files, Access databases, and Excel spreadsheets. How are you going to get it all into one centralized database?

    Now, hopefully, some readers are nodding their heads. They're saying, "you're right, I do have loads of data sitting around in various forms. And I really am having a lot of trouble getting it into the database." Now I've drawn in my target audience. I've reminded them of their problem. And I haven't used any jargon; remember, it's a beginner-level talk.

    Also notice that I am directly addressing the reader ("you"). This is done very much on purpose: I want to reinforce that my talk is for my target audience, and that I'm thinking about and talking to my target audience. I'm not writing this abstract for some random group of people I don't know and don't understand. And it's certainly not for me (or the "royal we"). I'm writing this abstract for a very specific group of people I want to help.

    Next we get into the hook, the section designed to make readers interested in your solution for their problem. The solution, in this case? Integration Services, which, in theory, is a great way to tackle the problem. But why is it great? Tell the reader.

    SQL Server Integration Services (SSIS), first introduced in SQL Server 2005, is a comprehensive tool designed to help ease all of your data loading headaches. In this session you will learn the basics around how SSIS is designed and how to manipulate both the logic and flow of data in your load processes. You will see how simple, yet effective, the SSIS user interface can be, and the ease with which even complex problems can be tackled.

    Now I've answered several questions for the reader:

    • "How am I going to solve my problems?" By using Integration Services.
    • "Well I'm running SQL Server 2008, not 2012. Can I still use it?" Sure you can. It was added to the product way back in 2005.
    • "What are you going to show me?" How to use the Control Flow and Data Flow. Oh wait, I didn't say that in the abstract. That's because it's an abstract for an audience that hasn't used SSIS, and those are jargon terms. Instead I mentioned that you can control logic and flow of data. I didn't even use the term ETL, because I want to target the absolute beginner. Anyone with a basic understanding of databases will understand what I'm getting at. Anyone who is knowledgeable in SSIS is going to read this abstract and immediately know that this talk isn't for them. And that's the goal.
    • "Is it difficult to use?" No, it's "simple, yet effective." I said so right in the abstract!

    In addition to answering these questions, I've kept most of the tone active. Active voice is one of the keys to a great abstract. It tells the reader that there is value to be had here, that this will actually impact his job and his bottom line, and that he shouldn't expect to attend and sit there, mouth agape, drooling and waiting for the bell to ring.

    I could leave the abstract as-is at this point and call it a day. But I like to end on a really positive, upbeat note. I want my reader to walk away excited by the prospect of attending my session. So I seal the deal with a conclusion that restates and ties everything back together.

    There is no reason to allow a data mess to ruin your day; after attending this session you'll have the necessary SSIS knowledge to easily extract data from virtually any source, transform it into whatever shape you need, and quickly load it into the database of your choice.

    If I've done everything right, the target audience member has finished reading and is saying "wow... that's exactly what I want to do."

     

    What Not To Do in an Abstract

    Over time I've noticed a few things that don't quite work:

    • Bullet points. Bullets are a great way to organize information into small digestible chunks. I've used plenty of them in this post. I'm even using one now to talk about why you shouldn't use bullet points. Oh, the irony. Anyway, the fact is that once you submit your session description for an event, you usually have no control over its formatting. And events botch the formatting all the time. Usually abstracts are compressed down to a single paragraph, so I recommend that you write your abstract as a single paragraph. Bullet points will tend to get rendered into something like this:

    This is my abstract about some cool new technology! I'll be covering such issues as - Using the technology - Installing the technology - Making friends with the technology - Harassing enemies with the technology - Formatting and line breaks using the technology This technology will change your life so attend today!

    • Using your own name in your abstract. Some people like to say things in their abstracts like "In this session Steve will show you why it's great to be a farmer." This works, in very limited cases, but most readers are going to say "Steve? Steve who?" They're going to think you're a deranged egomaniac, and they're not going to want to attend your session. If you've read this far you know that I like to think about the normal people; the ones who aren't plugged in to the community 24x7, because they have something better to do with their time. They probably don't know who you are, even if you include your last name. Sorry.
    • Insulting the reader. Never, ever, ever assume that you're the smartest person in the room, unless you're alone in the room. And be very careful with assumptions about your target audience. Sometimes I'll see abstracts that say something inflammatory, like "if you're a .NET developer creating a data model, you've no doubt screwed up several key aspects." While this may be true in your mind, and might even be true in reality, what you're doing is alienating the reader. A better way to phrase this would be something like "due to various differences between the platforms, .NET developers attempting to create a SQL Server data model may encounter a number of tricky situations." Now the reader can think back, realize that he has hit one or more of these, and become interested in your content. And that's a win.

     

    speaker_on_stageThe Aftermath

    If you've written your session description with only 15 minutes left before the event closes its submission period, you're pretty much in the same boat as everyone else. Oh, and you're doing it totally wrong.

    The very first thing you should do after you complete your work? Read it yourself. And then read it again. Read it slowly and carefully, word by word. You will find a typo. You will find a grammatical error, or a phrasing problem. If you don't, you're not looking hard enough. And run it through a spell checker. There is nothing that says "careless" more than a glaring error -- and, again, a glaring error in the session description is indicative of lots of glaring errors in the actual talk.

    The next thing you should do is to pass the session description around to some people you trust. Preferably one or two people who are in your target audience, to tell you whether you've created something of interest. Preferably one non-technical person, to screen it for jargon and do a second copy edit. If the non-technical person is just a bit lost, that's okay. If the non-technical person is totally lost, chances are most technical people will be, too. Clean it up.

    If you're writing in English and you're not a native writer, find a native writer and have him proof your work. Neither event organizers nor attendees care about why your abstract is full of grammatical errors. You probably write in English a lot better than I can write in your language, and I have massive respect for you, but you're still out of luck if your work can't be properly understood by English language audiences.

    After that, paste the abstract into the web form, hit Submit, and ... wait.

    Submission for larger events is a painful process. You put your abstract in and sometimes have to endure 90 or more days of wondering before you get your answer. Oftentimes the answer is nothing more than a "yes" or a "no." It's okay to ask for an explanation if you've been rejected, but it's also okay for the event to tell you that they don't have time to provide one. If you're going to start speaking regularly, prep well, build up a nice thick skin, and get ready to endure some rejection. Don't worry. Keep practicing, keep trying, and you'll get there.

    Of course you also have to write the presentation. And as you do so you absolutely must use the session description you wrote. You've set attendee expectations; make sure your actual session will live up to them. Your presentation should cover everything you said you were going to cover and, if your session description was properly worded, not much that you didn't mention. Naturally, writing the session is an entirely different topic for an entirely different blog post.

     

    Summary

    A great session description is a short yet compelling story designed for a very specific reader. The reader is the protagonist, his problem is the antagonist, and you are the narrator, helping the reader through his quest for glory. Know your target audience, understand its problems, help solve them, and your session description will be wildly successful. Remember that most readers only look at a very small part of the story, the title, so make sure to spend plenty of time there. And remember to always keep things moving and interesting; there is nothing worse than a boring story.

    I'm sure many of you have opinions that differ from what I've expressed here. I look forward to hearing from you in the comments section below. Likewise, for those of you who have questions I may not have covered above. Finally, I would like to invite readers to post their own abstracts for public criticism. (Constructive!)

    Thank you for reading, and I’ll see you on stage!

  • Itzik Ben-Gan in Atlanta: May 13-17

    This year Data Education is offering a few more classes with Itzik Ben-Gan, the world's foremost T-SQL instructor.

    Our first offering has just been announced: Atlanta, May 13-17.

    Neither Itzik nor his class needs much introduction, but click through for a full outline and other details.

    We think that Atlanta is a great city, with an amazingly vibrant SQL Server community. Hope you'll be able to join us there!

     

    By the way: if you're joining the class stick around town for a SQL Saturday event that is taking place, coincidentally, on May 18.

  • [New England] SQL Saturday #203: April 5-6, Cambridge MA

    SQL Saturday returns to the Boston area this April, with what is certain to be an exceptional speaker and session lineup. (The actual schedule will be posted soon, but in the meantime you can see the submitted sessions.)

    The free event ($10 if you'd like to eat lunch) will take place on Saturday, April 6. Highly recommended for anyone in the area who is interested in bettering your database skills!

    Friday, April 5, as a lead in to the Saturday event, I'll be delivering my popular full-day "No More Guessing!" seminar. This seminar teaches a solid, proven performance troubleshooting methodology designed to help you quickly find the actual root cause of performance problems. Full information is available on the registration site.

    This seminar has sold out at events like PASS Summit and SQLBits, and it is being offered in Boston at the discounted price, so book early to avoid disappointment.

    Huge thanks to Mike Hillwig for taking the lead on putting together this event. Looking forward to seeing many of you there!

  • [New England] Mark Souza on Big Data and Cloud at NESQL

    This Thursday, January 17, at New England SQL Server we'll be featuring Mark Souza, General Manager of the Data Platform Group at Microsoft. Most of you are probably familiar with that name; he's the guy who founded the CAT team, and he's been in a number of key roles in the SQL Server organization for the past several years.

    Mark's topic for Thursday is Big Data and Cloud at Microsoft. The talk should be an interesting look into how the company is approaching these key areas.

    If you're in New England and aren't already a member of New England SQL Server, you can sign up here. RSVP is required to attend our meetings, and we will send out the invitation e-mail on Tuesday morning.

    Hope to see many of you there!

  • Query Tuning Mastery at PASS Summit 2012: The Video

    An especially clever community member was kind enough to reverse-engineer the video stream for me, and came up with a direct link to the PASS TV video stream for my Query Tuning Mastery: The Art and Science of Manhandling Parallelism talk, delivered at the PASS Summit last Thursday. I'm not sure how long this link will work, but I'd like to share it for my readers who were unable to see it in person or live on the stream.

    Start here.

    Skip past the keynote, to the 149 minute mark.

    Enjoy!

  • Query Tuning Mastery at PASS Summit 2012: The Demos

    For the second year in a row, I was asked to deliver a 500-level "Query Tuning Mastery" talk in room 6E of the Washington State Convention Center, for the PASS Summit. (Here's some information about last year's talk, on workspace memory.) And for the second year in a row, I had to deliver said talk at 10:15 in the morning, in a room used as overflow for the keynote, following a keynote speaker that didn't stop speaking on time. Frustrating!

    Last Thursday, after very, very quickly setting up and getting sound and video checks, the rest of the talk went surprisingly smoothly. My deck--a brand new version created specifically for PASS--helped me get across the message I wanted to communicate, my demos ran without any failure, and my jokes didn't drive too many people out of the room before the end of the talk. I even received a round of applause when I managed to take a 26 minute query plan and, using a few query rewrites, deliver the same exact data in 9 seconds. That, I have to say, was pretty cool.

    Here's the abstract for the session:

    Query Tuning Mastery: The Art and Science of Manhandling Parallelism

    As a database developer, your job boils down to one word: performance. In today's multi-core-driven world, query performance is very much determined by how well you're taking advantage of the processing power at your disposal. Are your big queries using every clock tick, or are they lagging behind? And if your queries are already parallel, can they be rewritten for even greater speed?

    In this session, you'll learn to take full advantage of SQL Server query parallelism. After a terminology review and technology refresher, the session will go deep, covering T-SQL patterns that allow certain queries to scale almost linearly across your multi-core CPUs. You'll see when and why the optimizer makes a parallel plan choice and how to impact the decision. Along the way, you’ll manipulate costs and row goals, challenge generally accepted tuning practices, and take complete control of your parallel queries.

    Since the talk was being broadcast live on "PASS TV," I had Paul White join me at the front of the room to moderate questions delivered via Twitter. This worked out reasonably well and I hope to do something similar in the future. Huge thanks to Paul for helping out -- and for giving me a really ugly scowl when one of my jokes fell totally flat.

    Demos for the talk are attached. Let me know if you have any questions.

    Thanks again to everyone who watched, either in person or at home. I had a blast. Hope you enjoyed it even half as much as I did!

  • CloudSeeder: CLR Stored Procedures For Creating CPU Pressure

    Sometimes, in the interest of testing various scenarios that your server might encounter, it's useful to be able to quickly simulate some condition or another. I/O, memory, CPU pressure, and so on.

    This latter one is something I've been playing with a lot recently. CPU pressure in SQL Server creates all sorts of interesting side-effects, such as exacerbating waits and making various other conditions much easier to reproduce.

    In order to make this simpler, I've created the attached CLR library. This is a simple pair of stored procedures:

    startSeeding takes two arguments: The first parameter is the number of threads you'd like to create, and the second is a bit, indicating whether or not the threads should be affinitized. If they are, the threads will run preemptively, and the CPU pressure will be of the external sort. If they are not affinitized, the pressure will be of the internal sort, and you'll be able to see SQL Server scheduler contention. Of course you can run the procedure two or more times and create a mix of threads, if that's what you'd like to do.

    stopSeeding takes no arguments. It attempts to cancel all of the threads that have been started.

    "Installing" the script is easy. Create a database on a server that has CLR enabled. Make the database trustworthy to bypass CLR security restrictions. And then run the script to create the objects. The code was compiled for .NET 3.5, so this should work on either SQL Server 2008, 2008R2, and 2012.

    Be careful about how many threads you create. It's amazing how quickly things can get out of hand. Start small. Trust me on this.

    On that note, I make absolutely no guarantees that this won't crash your server, or worse. As a matter of fact, that's kind of the point!

    Enjoy, and let me know if you have any feedback, feature requests, or whatever.

  • SQL in Boston -- Red Gate Style

    You might have heard of Red Gate's famous SQL in the City events: free, full-day educational events where you can learn from Red Gate's own evangelists in addition to various MVPs and other guests. With just a tiny bit of marketing thrown in for good measure (don't worry, it's not a daylong sales pitch).

    Red Gate is doing a US tour this fall, and I'm happy to note that my fair city of Boston is one of the stops... and I am one of the speakers.

    The event takes place on October 8. I'll be delivering a talk entitled "The Ten Commandments of SQL Server Monitoring."

    I've not yet received all ten commandments, but my tablets are initialized and my stylus is at the ready. I'm sure I'll have some good information to share with you come October.

    Hope to see you there!

  • Excellent Job Opportunity: SQL Developer in Boston MA

    Want to do interesting, in-depth SQL Server development work for a great company?

    If the answer is yes, you should drop me a line immediately. Send me your resume at [my first name] @ [the name of this site].

     

    More information:

    This job is working on a data warehouse for a financial services company in Boston, MA. I cannot publicly mention the company name or say much about it, but if you e-mail me a resume I'll be happy to share more information. What I can say is that it's a solid company with a great reputation in the industry, and a fantastic place to work. The position is located in Boston, MA, and either requires that you live here or travel here (at your own expense) on a fairly regular basis. The company would prefer to hire fulltime employees, but there may be room for a contractor -- e-mail me and we'll see.

    The project itself is to work with a small team of dedicated database developers, on a project very core to the company's mission. There are a lot of interesting challenges, there is a lot of work to be done, and the project is a very high visibility endeavor. The team is small and the project is somewhat loosely managed, so team members are expected to be the kind of people who can drive themselves forward, set their own goals, and make progress without a whole lot of hand holding. If you're the kind of person who is a self-starter and loves to learn, this is an environment in which you can really flourish.

    Task-wise you'll be expected, depending on the day, to do some database design, some ETL, and usually a lot of T-SQL development. Performance is of paramount importance and the company is looking for people who have good to excellent understanding of SQL Server internals and can handle complex query tuning challenges. If you're the kind of person who gets excited when Paul White writes a new blog post, you'd be a great fit.

     

    I can't say anything more here; if you're interested, drop me a line and I'll be happy to chat with you either via email or over the phone. I think this is a great opportunity and I hope some of my readers will want to give it a shot.

  • Your Transaction is in Jeopardy -- and You Can't Even Know It!

    If you're reading this, please take one minute out of your day and vote for the following Connect item:

    https://connect.microsoft.com/SQLServer/feedback/details/444030/sys-dm-tran-active-transactions-transaction-state-not-updated-when-an-attention-event-occurs

    If you're really interested, take three minutes: run the steps to reproduce the issue, and then check the box that says that you were able to reproduce the issue.

    Why?

    Imagine that ten hours ago you started a big transaction. You're sitting there waiting for it to finish, and it's running, and running, and running. At some point, you notice that the drive with the transaction log has filled up, so you create a second log file. And the transaction is sitting there running, and running, and running. Is it still doing work? Or did it catch the low disk space issue and start rolling back? Wouldn't it be great if you could actually answer that question? Are you surprised to learn that you can't answer that question?

    SQL Server currently has a few DMVs that are supposed to tell us the status of a given request, transaction, and so on. These DMVs are unreliable in the vast majority of situations. That means that we are unable to answer important questions like, "is my transaction still doing any work, or did it die three hours ago?"

    The SQL Server team needs to fix this. End of story. Please vote and help me convince the powers that be to do the right thing.

  • SQL Saturday 111: Manhandling Parallelism - Demos

    Another year, another fantastic Atlanta SQL Saturday. Hats off to the team that created the event for delivering a top notch day for the attendees.

    Thanks to everyone who attended my "Query Tuning Mastery: The Art and Science of Manhandling Parallelism" session. Demos are attached.

    Enjoy, and I'll see you at the next one!

  • Data Education: Great Classes Coming to a City Near You

    In case you haven't noticed, Data Education (the training company I started a couple of years ago) has expanded beyond the US northeast; we're currently offering courses with top trainers in both St. Louis and Chicago, as well as the Boston area.

    The courses are starting to fill up fast—not surprising when you consider we’re talking about experienced instructors like Kalen Delaney, Rob Farley, and Allan Hirt—but we have still have some room.  We’re very excited about bringing the highest quality SQL training to the middle of the country.

    If you’re interested in taking one of the courses (or more! multiple registration discount!), you're in luck: just enter the special discount codes for SQLblog.com readers:

    Without further ado, the course descriptions (full outlines at DataEducation.com) … hope to see many of you soon in a Data Ed classroom!


    SQL Server 2005, 2008, and 2012 Internals and Query Tuning (May 7-11; St. Louis, MO): Kalen Delaney is back with her blockbuster internals course, now with information on SQL Server 2012. In this world-renowned five-day course, students will learn how to take a long, hard look at the SQL Server relational engine. After better understanding what’s happening internally, students will get the opportunity to investigate how internals can affect how you set up your databases for maximum performance and reliability. Query tuning within SQL Server 2005 and 2008, as well as parts of SQL Server 2012, will be discussed in depth.

    (This course is geared toward both SQL Server DBAs and developers with some experience with application development and architecture.)

     

    Advanced T-SQL Querying and Reporting: Building Effectiveness (May 14-16; Chicago, IL): You know this one will be good if MVP Rob Farley is flying all the way from his native Australia to our classroom in Chicago. This three-day course is a journey through the more advanced side of T-SQL, designed to help you create queries that are simply more effective. Rob Farley takes his students on a road trip of unlearning bad habits of querying and reporting, and into a deeper understanding of what makes a query effective. Common student feedback for this course includes “You’ve made me want to go back and rework every query I’ve ever written” and “I didn’t realize how much I didn’t understand about even the fundamental parts of T-SQL.”

    (The T-SQL taught will be primarily for SQL Server 2012, but most of the principles taught will also apply equally to SQL Server 2005 and SQL Server 2008.)

     

     

    This is Mission Critical: High Availability for SQL Server 2008 and 2012 (June 18-20; Boston, MA): This course is another perfect example of learning an in-depth topic straight from one of the world’s biggest experts in that area. In this three-day course, Windows, clustering, and SQL Server high availability/disaster recover expert Allan Hirt will dive into new features and enhancements within SQL Server 2012 (as well as 2008), including the enhanced multi-site failover clusters and AlwaysOn availability groups. Windows 8 Server and Server Core will also be discussed as they relate to highly available SQL Server deployments.

    (This course is perfect for SQL Server DBAs eager to get an early understanding of SQL Server 2012 and what is means for creating and maintaining mission-critical database systems.

     

     

    Let me know if you have any questions about these or other Data Education course offerings.

  • SQLbits London 2012 - Demos

    Thanks to everyone who attended my sessions last Friday and Saturday at SQLbits! It was great to meet many new people, not to mention spending some time exploring one of my favorite cities, London.

    Attached are the demos for each of the two talks I delivered:

    Query Tuning Mastery: The Art of and Science of Manhandling Parallelism
    As a database developer, your job boils down to one word: performance. And in today's multi-core-driven world, query performance is very much determined by how well you're taking advantage of the processing power at your disposal. Are your big queries using every available clock tick, or are they lagging behind? And if your queries are already going parallel, can they be rewritten for even greater speed? In this session you will learn how to take full advantage of parallelism, from a developer's point of view. After a quick terminology review and technology refresher the session will go deep, covering T-SQL patterns that allow certain queries to scale almost linearly across your multi-core CPUs. Alas, not all T-SQL queries can go parallel, so you will also learn to watch for those things that can restrict the query optimizer's decisions. Along the way you’ll learn to manipulate costs and row goals, challenge generally accepted tuning practices, and take complete control of your parallel queries.

    ... and ...

    Query Tuning Mastery: Workspace Memory Internals
    As SQL Server professionals, we often think of memory in vague, instance-level terms: buffer pool, procedure cache, Virtual Address Space, and so on. But certain tasks require a more in-depth focus, and query tuning is one of them. Large, complex queries need memory in which to work--workspace memory--and understanding the how's, when's, and why's of this memory can help you create queries that run in seconds rather than minutes. This session will give you an in-depth understanding of how the optimizer makes its query memory decisions, with lots of tips and tricks along the way to help you guide the process for top performance. If you work with large queries and are serious about achieving scalability and consistently great performance, you owe it to yourself to attend this session.

     

    Enjoy!

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement