When we started building our classes for next year, we started by following our own advice. We wrote detailed attendee biographies defining exactly who should attend, what pains they were facing, and how they would use the training to solve the pains when they got back to the office.
We’re Guilty of Profiling
We got really detailed with the attendee bios – how many years they’d been working with SQL Server, what topics they were comfortable with, what topics they hadn’t even seen yet, what kinds of user group sessions they’ve attended, and more. Then we boiled down the attendee profile to a single sentence for each class:
How to Be a Senior DBA Class – You’re a DBA who is ready to advance to the next level in your career but aren’t sure how to fully master your environment and drive the right architectural changes.
SQL Server Performance Troubleshooting Class – You’re a developer who needs to speed up a database server that you don’t fully understand.
I love this kind of profiling. For example, with the DBA class, we want the attendee to read the sentence and go, “Wow, that’s me – I’m a DBA and I don’t feel like I’m driving the architecture changes we need. In fact, I think the entire company is the one driving me, dictating what we’re doing, and I don’t agree with the direction we’re taking. How can I turn things around so that I’m the master of our database strategy?” So many DBAs feel like they’re constantly behind the 8-ball, being reactive instead of proactive, and they’re not happy about it.
With the performance troubleshooting class, we want the reader to say, “Whoa, that’s me – if I don’t get this app running faster, nobody else is going to do it for me, and I don’t even know where to start. I’ve tried adding indexes, I’ve tried adding NOLOCK, and I know how to run Profiler traces, but it doesn’t feel like we’re making real, significant progress.” Most of the developers I work with aren’t suffering from a lack of information – they’ve got an overwhelming flood of information, and they’re not sure which parts to believe and which parts to prioritize.
Then We Thought About Our Clients
We went back through our client findings from our SQL Critical Care™ sessions, and we categorized them into three piles:
- Shops with a loner DBA totally qualified to become a senior DBA, but just didn’t have any in-house mentoring
- Shops with developers who were facing performance issues, but couldn’t justify a full time DBA (and many of these happened to be software vendors or software-as-a-service companies)
- Shops where neither applied
The last day of our SQL Critical Care™ sessions is a set of customized training modules that cover how to get fast relief for their SQL Server’s pain points. We looked at the most common pain points for each of these categories, and then built the module list for our public training:
How to Be a Senior DBA Modules
Here’s some of the modules we picked, and why:
Architecture Design for RPO/RTO – most solo-DBA shops don’t have enough variety to really get exposed to all of the different HA/DR options. We talk about the real-world pros and cons of each method so you can get a sanity check about whether you should build a cluster, use log shipping, or jump into AlwaysOn AGs.
The Secret Meaning of Performance Counters – you don’t have enough time to gather every metric and read the tea leaves to figure out what it means. We feel your pain; we have to rapidly performance tune slow SQL Servers too, and we’ll share our favorite counters and shortcuts.
What Every Senior DBA Must Know About Failover Clustering – this is the single most common high availability feature that we end up recommending to clients. It had a horrendous reputation years ago due to complexity and shakiness, but it’s better these days – as long as you follow some important rules.
Pushing Boundaries: Stories from the Field – You can learn real-world solutions from some of the crazy outlier clients we’ve got. We’re talking thousands of databases per server, tens of terabytes in a single data file, and over 100k batch requests per second, and yet there’s tips that can help you with your “normal” servers.
SQL Server Performance Troubleshooting Modules
How to Think Like the Engine – yes, you can buy a video version of this class for $29, but we still use a condensed 45-minute version of it to kick off our troubleshooting class because it’s so important to get you into the frame of mind of SQL Server’s internals. We’re going to be talking about indexes, wait stats, sargability, and other related concepts throughout the following 3 days, so we’ve gotta get you started off right.
Why NOLOCK Isn’t Enough – you’ve already peppered all your queries with NOLOCK, but you’re still facing performance problems. Picking the right isolation level can make all the difference, but you need to know how to plan for it and test it.
X-Ray Glasses for SQL Server Indexes – did you pick the right clustering key? If you didn’t, how is it impacting performance? There’s a lot of advice out there about whether you should swap out GUIDs as your clustering key, and we’ll show you how to get the right answer for your app.
Developer’s Guide to Dangerous Queries – when you’re looking at T-SQL and a query plan, how can you tell if it’s harmless or horrific? It’s not enough to just look at estimated costs, either. You’ll learn how to spot the queries that are really giving the SQL Server engine fits, and how to reshape them.
Data-Driven Index Changes – after you’ve changed indexes, how can you numerically prove that things have gotten better? How do you know when to stop? We’ll give you tools to document it quickly.
The Result: Our 2014 Class Lineup
We spent hours planning out the modules, setting how much time we needed per module, putting them together around break schedules, and making sure they flowed together well. I’m really surprised by how much work this takes to do it right!
We went live with our training class pages, and then recently updated ‘em to make it more clear how the scheduling works. Go check it out now and let us know what you think of the updated pages.