Eddie's SQL Server Blog

The next Louisville SQL Saturday will be held on Saturday, July 21. (Full details here) This time, the event planners have added FOUR full-day pre-conference seminars on Friday, July 20:

• A Deep-Dive Into Waits-Based Performance Tuning by Eddie Wuerch
• Leadership Skills for IT Professional – Kevin Kline MVP
• Practical Self Service BI With PowerPivot – by Bill Pearson – MVP
• SSIS – Live it, love it, Learn it – by Dave Fackler

These seminars are only $99 – a heck of a deal for a full day of training.

A Day of Waits

My seminar is basically the full-day version of the “Find Performance Problems by Reading the Waits” session I’ve run at several SQL Saturdays and last year’s SQL Rally. The most-frequent comment I received was that the session should be much longer so I could dig into the different wait types, provide more detail, and demonstrate examples of them occurring and different fixes for them. I always felt that myself, and I’m thrilled for the opportunity to spend a whole day on this.

So, with a whole day, what will be covered?

The Waits and Queues Method

We’ll start here, with an overview of Waits in general, and go over different ways of capturing Wait info, including new ways of going about it in SQL 2012. The seminar won’t be too 2012-specific; most of what will be covered is applicable to SQL 2005, 2008, and 2012. If you’re not using this approach to tune performance, then you’re flying blind. If you’ve looked at Activity Monitor and seen all those crazy codes like CXPACKET, PAGEIOLATCH_SH, LCK_M_IX, ASYNC_NETWORK_IO, WRITELOG, SLEEP_BPOOL_FLUSH, and so on, and wondered what they mean and what to do with that info, then this seminar is for you. Those cryptic codes are the key to finding and resolving performance issues with the least amount of effort.

We’ll also cover ways of examining disk I/O and CPU usage information, as these are also important to performance tuning.

On to the Waits!

The bulk of the day will be spent running through a long list of wait types, spending much more time than in the short session. For each of them, I’ll dig into what they are and what causes them. In most cases, I’ll have sample code so we can see them in action. Then we’ll fix the code/configuration/whatever is broken to eliminate the wait.

What You’ll Take with You

When you’ll leave this seminar, you’ll have:

• Scripts you can begin using immediately to start solving problems
• Scripts for setting up base lining and monitoring, and scripts to analyze the results
• A book with all of the information covered, that can be used to assist in performance troubleshooting
• Some new tricks in your trick bag for quickly and easily solving problems

Hope to see you in July!

Whoop! Just a few weeks to go until the next SQL Saturday in Chicago. If you haven’t signed up yet, you can do so and get all the details (including info on two different full-day pre-cons!) here.

I’m presenting, but in a first for me at a SQL Saturday, I won’t be presenting a technical session. Gonna be weird talking at a SQL Server conference without blathering on about latches. Although my session won’t be technical, it will be on a topic about which I’m rather passionate: building and delivering technical sessions. It’s in the last time slot (4pm), and I’m up against some great speakers with terrific topics who are presenting at the same time, but I’m still rather excited to be presenting this topic.

The Session

The session is called “Join Us! Getting Started as a Technical Speaker”. The target audience is folks who have either never given a public presentation, or have done one or two and are looking for additional tips from someone who’s done a lot of these and actually been through a fair degree of training on the matter. Or folks who have already seen the other stuff going on at the same time and wondering how long I last before I say “latch”. (I hear the current line is 17 minutes)

Here’s the pitch: have you ever watched a speaker at a user group or tech conference (such as SQL Saturday) and thought, “Hey! I can do that!”? Well, it’s not for everyone, but if you have the itch, I really want to encourage you to scratch it. Speaking is a blast. It’s rock and roll for nerds. And just like picking up an instrument and writing a song, although you could sit down and learn it all yourself, you’ll save a lot of time and effort, and get better results, if you take some advice from those who have gone before you. That’s where I come in. There’s a big difference between practicing in your room (or coding at your desk) and getting on stage.

I should warn you up front: getting more involved in the SQL Server community and presenting at technical events are both very addicting. In both cases, you’ll find a lot of folks who are very welcoming and way more than happy to help you get started. You may get stuck doing a duet of show tunes at a karaoke dive, but, hey, Jäger.

Here are some of the things I’m going to cover:

• Finding a venue to get started
• Picking a winning topic
• Writing a killer abstract
• Building your chart-topping presentation
• Preparation (practice, practice, practice!)
• Warm-up and pre-flight
• Nailing the presentation

BTW, never miss a chance to network or spend some time getting out of your shell and getting in front of a crowd. Even if you don’t attend my session (seriously, there’s some awesome sessions also going on in that time slot), don’t miss the afterparty. We’ve been promised #sqlkaraoke…

I hope to see you in Chicago on May 19!

Since my earlier rant kicked up a little dust, I feel I should follow up.

First, I was pleasantly surprised by the number of comments I received on Twitter. Some folks commented that they couldn’t leave a comment on the blog post itself. While that would have greatly enhanced the conversation, I’m fine with that. The last time I enabled comments, the site was overrun with spam posts.

Jen McCown (Blog) took the time to blog a full reply, which I appreciate. She offered some solutions to my problem of what to do about multiple events on the same day, with the same Call for Speakers cutoff date. This one really caught my eye:

“Better yet, is there anything wrong with getting a feel for the likelyhood of your being accepted? Meaning: Just ask.”

Well, there you go. That’s why I’m glad I blogged about it, and another reason the SQL community rocks. This simple solution was evading me. The weekend about which I was complaining has three events to which I’m basically nobody, except maybe as the guy who keeps singing “Piano Man” at Bush Gardens, and I’m kinda hoping they don’t make the connection on that one. Once I knock the idea around a little longer and whittle it down to two of the events, it will be time to make an introduction. Still it seems a little odd to tell folks right up front I’m on the fence about their event, especially given the voracity of one of the comments that follows Jen’s post.

As to the other points:

“What’s more, once a SQLSat’s call for speakers has gone on a little while, ask the organizers what kinds of session submissions they’re lacking. If you have more than one kind of session, you can be a real lifesaver to a planning committee that’s overrun with sessions of type A, and scraping the barrel for type B.“

That one plays well into one of those useful life rules: get outside your comfort zone. Ask me to talk about a variety of performance topics and I’ll just grab the presentation and run with it. If I don’t have one ready that I’ve already given at a user group or SQL Saturday, I’ll likely be able to have a serviceable session together in 10-15 hours, prepped and rehearsed. Ask me to talk about replication or XEvents or other things that I’ve done but by no means consider myself ‘presentation ready’, and you’ve dropped a challenge into my lap that will require a lot of research and preparation. There’s no way I could get out of it without learning new things, which is cool. Something I say to folks when encouraging them to start speaking: If you think you’re good at something, offer to speak to a room full of strangers about it. If you have any dignity whatsoever, you’ll spend a lot of time getting even better. Of course, that’s only for things I’d actually care to learn – it’s best to not ask me to do an hour on LINQ, nHibernate, or Entity Framework. I doubt a session titled “What the F*** Is Wrong with You People?” would go over well…

And the other suggestion:

“Solution 1: Pick another weekend. […]Eddie gave the example of four SQL Saturdays on one weekend. Couldn’t you submit to the most likely of those, and if it falls through, submit to another later in the year?“

Well, I’m going to do that anyway I go to a lot of these events. Last year, I spoke at nine SQL Saturdays, running pre-cons at two of them, and SQLRally. This year’s goals are 11 SQL Saturdays, running at least two pre-cons, and a slot at the Summit. This is both my hobby and a potentially important step for my career, but it’s primarily my hobby. I’ve made so many new friends and have so many great memories as a result of getting hooked on speaking that I don’t plan on stopping anytime soon. In fact, shortly after that weekend is a different type of the same problem. September 15 has at least three events in new locations for me; lots of new people to meet. But two weeks later, September 29, has two events in the U.S. (Orlando and Minneapolis), and I’m torn between them for the opposite reason – I know a lot of people at both of them, some quite well, from several events. Whereas September 15 is a strategic decision, September 29 is a personal one. For September 15, I’m choosing which event would be best for me to try and attend. For September 29, I’m choosing which one I will least regret missing, because I really want to go to both. Big difference. I’ll eventually pick one and submit abstracts. I’m reasonably confident that I’ll get picked up for at least one session. If I don’t then it will be too late for a slot at the other one, so I’d likely attend anyway, volunteer for other tasks, and let the planners know I’m ready to pinch-hit if there are any speaker cancelations.

My post was rather one-sided from the speaker perspective; Pam Shaw provides a great reply from the event-planner perspective.

To wrap it all up, I’d like to restate that I’ve never double-submitted, and have no intention of doing so. I needed to do a little thinking out loud – a personal blog post about a professional topic.

-Eddie

After losing everything in my blog, it’s good to finally post something again.

There’s a current debate happening on Twitter (well, I think it’s already done), and my take on it won’t fit in 140 characters, especially after including the @handles of everyone I’m copying. Thought I’d just blog a larger comment.

The debate centers around speakers submitting abstracts to multiple events that occur on the same day. These are in-person events; one person cannot speak at two SQL Saturdays on the same day.

There are a number of things affecting this from all sides:

1. SQL Saturday is a terrific event, and its popularity continues to grow. As a result, multiple cities will host this event on the same day (I’m looking at you, September 15).
2. Speaking at these events is a blast. Meeting everyone at these events is a blast. Getting felt up by the TSA sucks, but, hey, #firstworldproblems.
3. Planning and running a SQL Saturday is a LOT of work. Selecting sessions from all the abstracts and building an event schedule that provides a rewarding day for a variety of attendees is hard, time-consuming work. After going through that, getting snubbed by a speaker is a real kick in the shorts. It’s not just a matter of grabbing another session to fill the hole – if you specifically picked a session to ensure a topic was included (say, a new SQL 2012 feature), and balanced the other sessions on the schedule for that, then your pool of available non-selected abstracts gets very small.
4. Nobody likes to be told they weren’t the first choice, either as a planner or a speaker.

Having been both a speaker and planner, I get it.

Here’s my take as a speaker:

First, I’d like to say I’ve never submitted sessions for more than on event on any given weekend. I just can’t imagine the shame of writing the “thanks for picking me, but I’d rather go to the SQLSat in another city” email, should I get picked to speak in multiple places on the same day. I fear that day may be coming. I was passed over for the first two events to which I submitted in 2012. I don’t know why, but I can guess there were some good reasons for that:

1. I’m far from a first-time speaker. One of the stated goals of SQL Saturday is to grow the speaker community, encouraging local new speakers to step up and get involved.
2. I’m also still a regional speaker – there are places with people that know me and lots of folks will attend my sessions, but I’m just another name in many others. There’s no eval-reporting system in SQL Saturday. Many event planners have no idea how I perform as a speaker. Why should they roll the dice on me? (This is not a complaint about a lack of a centralized eval system – that would be a massive undertaking) Both of those events were in locations where I have never spoken.
3. I’m not an MVP. I doubt I’ll be one anytime soon. I’m a production performance DBA for a very large, very busy system. Meetings and work preclude me from paying too much attention to #sqlhelp and message boards during the day. My community involvement is rather limited to speaking on the weekends.

While I enjoy repeating at locations where I have spoken, I’m still trying to build up my personal brand. I want to speak at the Summit. As becoming an MVP is unlikely, I see my only options are to keep building my cred or put dick jokes in my session titles. I’m sticking with the former.

Enough preamble, let’s get back to the original conversation: speakers submitting to multiple simultaneous SQL Saturdays. Here’s an example of my dilemma as a speaker: September 15. There are three, possibly four events that day:

• St. Louis, MO
• Providence, RI
• San Diego, CA
• Austin, TX (still listed as a proposed date)

I have spoken in none of these cities. They all are compelling locations – I can’t decide which is better – St. Louis is closest and I’ve met some of the folks at other events, I haven’t presented in New England or Texas, and San Diego will let me catch up with the folks I met at the Huntington Beach SQLSat and continue presenting in that area. That’s four events I’d like to attend. Good kind of problem to have but I still need to decide. The three that are officially on the schedule all have the same closing date for the Call for Speakers, making it impossible to try to hit one, and then shoot for another if I don’t get picked.

So what do I do about September 15? I have three choices:

1. Pick one, submit abstracts to it, and stick to it. If I don’t get picked, I’m SOL for the weekend. By the time that event notifies me I’m not picked, it’s too late to apply anywhere else.
2. Submit abstracts to multiple events. If I get picked at more than one of them, I’ll have to pick one of them and trash my reputation with the rest.
3. Pass on the whole mess, book a flight to Mexico, and read the tweets on a beach with a beer.

Item #3 looks pretty good, actually.

This conversation was triggered by event planners asking speakers to cancel abstracts at other same-day events. Ballsy, but likely effective. To be fair, should I ever cross the line and double-submit, and you ask me to commit to you, then you damn well better commit to me. You may feel insulted by my submitting elsewhere, but please know that if I applied for your event, then I want to speak at your event. I’m not paid to do this, I’m not even encouraged to do so by my employer, and I cover all the costs myself. I apply nowhere casually. There are very few reasons why I would want to speak at one event over another on the same day – the only one I have right now is choosing Indianapolis over Sacramento because I’m part of the Indy team, and I won’t have to pay for a plane flight. Beyond that, the bigger pulls for me are personal cost and who else will be there.

After griping my way through this blog post I ought to get to a proposal. I can’t come up with an elegant solution, but at least I’d like to pitch something:

It all comes down to the closing date for the Call for Speakers (CFS). The first event on a given weekend that completes all of the paperwork and gets on the schedule as an official event gets the earliest CFS closing date. The next event must pick a CFS some interval behind that, like 7-10 days, to allow time for the first event to complete their selections and notify everyone. Not a great suggestion, not even sure it beats what’s in place now, outside of letting planners know that there will be speakers who simply like to attend SQL Saturdays, and when their events are on the same days as other ones, overlaps will occur.

-Eddie