So, this blog post has been banging around in my head for a couple of days now, and I finally just had to type it all out and give up on brevity. This was kind of a big deal for me, and I wanted to record all the things that led to its fruition.
So here’s my SQL Saturday #67 recap:
SQL Saturday Chicago 2010 was my first PASS event. I had already been attending my local, Nashville SQL Server User Group meetings, but I’d not been to any other SQL community events. Since that time, I became a part of the Nashville SSUG leadership committee and we hosted our own SQL Saturday in Nashville this past August. I also attended SQLBits 8 in York, England (which was awesome!) and wrapped up the year with PASS Summit (also awesome) in Seattle. You could say I’ve gotten the bug. I love attending training events, not just for the opportunity to learn, but to catch up with friends that I only get to see at events like these.
After the PASS Summit, I was really inspired to do some of my own presentations. One doesn’t get a degree in Special Education without having the heart of a teacher, and I knew I had a lot of good knowledge to share. I saw it as an opportunity to pay forward all the mentoring I’ve received. So I got to thinking about what my first presentation might be.
As I was going through my rather dog-eared copy of Professional SQL Server 2008 Internals and Troubleshooting, I flipped back to the very first chapter, an overview of SQL Server internals, and an idea was born. I had this crazy analogy floating around my head that tied all the working parts of SQL Server together with preparing a meal. I made a few rough notes, so I wouldn’t forget the gist of my idea, and then life took over again, and I didn’t really go back to it.
Fast forward to February of this year. I had read Scott Berkun’s Confessions of a Public Speaker, and decided that maybe this whole public speaking thing wasn’t so impossible after all. Then, the call for speakers for 24 Hours of PASS came open about the same time as SQL Saturday Chicago. So I typed up an abstract for my SQL Server Internals overview and submitted to both, fully expecting to be rejected.
In the meantime, I started training for my RKC workshop in April (think black belt test for kettlebells). Now, all of a sudden my life was consumed with training, so session submissions quickly evaporated to the periphery. As a result, I was almost relieved when I didn’t make the cut for 24HOP. Granted, I was disappointed, but I felt over committed, as it was, and didn’t need to add developing a presentation to the list. Then, I get an email from Ted Krueger [blog|twitter] saying I’d been selected to speak at SQL Saturday Chicago.
I kind of freaked out. Not really in a bad way, just in a “Can I really do this?” sort of way. Well, I felt really honored to be selected, so I thought I better figure out a way to make this work, and I accepted the invitation. I quickly discovered that lots of folks believed I could do this, and with that support underpinning the effort I began to write a presentation.
Once I got my material together, I practiced quite a bit, mostly on the dog. I also gave the presentation to my co-workers at a “lunch and learn”. I’m really glad I did that, because it gave me the opportunity to field questions and get feedback from a friendly, yet unbiased, audience. My dog, of course, thinks I hung the moon, so his opinion isn’t terribly objective. =)
At this point I knew I had a few things to tweak, so I made some changes and dug a little deeper into some of the topics that might require more technical answers. I have to stop here and thank Paul White [blog|twitter] and Benjamin Nevarez [blog|twitter] two super smart guys who helped me clarify some of the finer details of my presentation.
Armed with the knowledge that I had done my due diligence in preparing for this presentation, I headed off to Chicago. As usual, there was a lot to do to help the SQL Saturday team get ready for the big day, so I jumped right in and started working. It wasn’t really until I walked into the speaker prep room on Saturday that it hit me: This SQL Saturday is different. I remember feeling a bit like an imposter and had to shake off the idea that I didn’t belong in there. I went through my slide deck one last time and decided that I was ready to go.
I had the last session of the day, so I had some time to kill. So, Erin Stellato [blog|twitter] and I sat in on Aaron Bertand’s [blog|twitter] session on what’s new with SQL Denali, and then I listened to Erin talk about baselining for performance tuning. We enjoyed our lunch while listening to the WIT panel talk about encouraging the next generation of IT professionals, and after lunch, I went to Jes Borland’s [blog|twitter] session on capitalizing on social media outlets to build your professional network. It was her first SQL Saturday session also, and, as expected, she did a stellar job. Way to go grrl_geek!
So now it was my turn! There were a few butterflies, but not as many as I thought there would be. I had a little issue with the projector. The display was slightly crooked and I couldn’t get it to straighten out, so I had to ignore my OCD tendencies and roll with it.
Wow, the room was almost full! There were several other really good sessions running at the same time as mine, so I was excited to have a pretty good sized audience. There were a few faces I knew, but lots I didn’t. Then, all of a sudden it was 4:00, so I reminded myself that no one was there to see me fail, and started the show.
I’m cruising along, feeling pretty good about the delivery. I set up my analogy with a story, and now we’re digging into the heart of the working parts. We get to the section where I start talking about the buffer pool and how its size is determined by your minimum and maximum server memory settings, and I get my first question. A fellow asked me to explain what the memory settings meant. It took me a second to formulate an answer, but it felt like hours and I let it fluster me a little. Note to self: you are allowed time to think! You don’t have to spit the answer out immediately.
So, I answer his question and then he asks me what his minimum memory setting should be. Well, there’s a classic “It Depends” answer if ever there was one. So, instead of asking him to talk to me after the session, I made the rookie mistake of trying to fully answer his question. The problem was that I never saw the light bulb go off for him, so I kept trying to answer his question. Another note to self: You might not see the light bulb, it’s okay.
Here I have to give a big shout out to Nicholas Cain [blog|twitter] who was in the audience. He saw me glance his way with a “How the heck do I handle this look” and he jumped in to redirect the conversation. I’m still not sure the guy had the answer he was looking for, but we certainly tried.
So I’m finishing up the middle section where we talk about update queries and the added steps involved with write-ahead logging and I’m ready to segue into the last section where I dig a little deeper into the processes that handle data changes like checkpoints and the lazy writer. I set this section up by reviewing the ACID principles of relational databases.
Now, I thought this was safe, well agreed upon material. No real room for opinion here. Well lo and behold; I strike a nerve with someone in the audience over the definition of consistency. I had explained that consistency meant that the data had to follow the rules. For example, foreign key relationships must be maintained, meaning child rows couldn’t be without parent rows. Constraints couldn’t be violated; if a column is marked NOT NULL you must put a value in, etc. Well, that’s when things got weird. A guy sitting in the back row says, quite forcefully, “No! You’re wrong. That’s not what consistency means. It means that one user cannot have a different view of the data than another user.”
At this point, I’m shocked by how rude the guy was, and as I’m standing there trying to formulate a response, several of the audience members told the guy that he was mixing up consistency with isolation. They were right, but he continued to argue, and the audience continued to try to help him understand.
It wasn’t until afterward that it occurred to me to bring up the READ UNCOMMITTED isolation level to show how dirty reads proved the error in his logic. But that point aside, I wasn’t really sure how to gracefully agree to disagree with this guy, because he wasn’t going to budge, and I could tell the audience was frustrated and ready to move on. I must say I was glad to have people I knew in attendance, because it was that little bit of silent encouragement that jabbed me into action.
I made a joke about how we all at least seemed to agree on the definition of durability, and since the next slides pertain to maintaining this characteristic, perhaps we should move on. Whew! I got past that obstacle and the session finished right on time with a few more questions answered and a seemingly satisfied group of attendees.
So what did the audience think of my first presentation? I got twenty speaker evaluation forms, none of which had any truly negative comments. There was one person who was bothered by the projector (which I totally understood), but still thought the material was good and another who thought my opening analogy could have been shorter. The rest of the comments were really positive. There were several “handled difficult audience well” comments, and my two favorites: “Christina explained some very hard core SQL topics in a way novices could understand” and “Very original! Handled yourself very well.” All evaluations marked that I had met or exceeded their expectations. So overall, it sounds like I accomplished my mission. Folks learned something about SQL Internals that hopefully will help them better understand things like why memory pressure is bad and why we’re told that transaction logs should be on their own disks.
After the session, Nic suggested that all first time speakers should have backup, so to speak, at SQL Saturdays. I agree. I probably would have muddled through nonetheless, but it was nice having the moral support in the audience, and also a second set of eyes and ears. He was able to confirm my impression that the grumpy old man was definitely out of line and atypical for most attendees. It was certainly the first time I had ever seen someone behave rather belligerently in a session and I’ve been to a lot of sessions.
Overall, it was a really rewarding experience, and I will definitely do it again. Crowd control will get easier, and if I can survive the grumpy old man in the back row, I can handle just about anybody.
Thanks to the SQLSaturday #67 team for giving me the opportunity to speak, and making it such great event, in general. I’m already looking forward to next year.
Lastly, I need to thank Kevin Kline [blog|twitter], Joe Webb [blog|twitter], and Louis Davidson [blog|twitter], fellow members of the Nashville SSUG leadership committee, who have been quietly and not-so-quietly pushing me to step up my game. Thanks guys! Hope I made you proud.