This week at the SQLBits conference in Newport, I’m teaching an all-new all-day session called Dev-Prod Demon Hunters: Finding the Real Cause of Production Slowness.

It filled up initially, but they’ve opened up more seats for it, so if you’re interested, there’s still time to join! Attendees get a free Fundamentals & Mastering 1-Year Bundle. Register now for SQLBits, or if you’re already registered, email contactus@sqlbits.com to get into my workshop.

I’ve already written about how I designed the session’s strategy. My overall strategy was to set up 2 SQL Servers, then step through several different queries, each facing a different reason why they were fast on one server, slow on another server. For example, we might face issues with parameter sniffing, different statistics on each server, and different settings on each server.

Now, tactically, how do I teach each specific lesson?

There are a bunch of ways teachers can communicate a topic, like:

• PowerPoint slides
• A process checklist, like my D.E.A.T.H. Method from Mastering Index Tuning
• Live hands-on demos in SSMS, stepping through a script or writing it on the fly
• Demos, but done via stepping through slides or recordings
• Handouts (like the 8KB pages I use in How to Think Like the Engine)
• Physical objects (like I did with my 20-minute fragmentation demo at Bits or my statistics with playing cards demo)

Or, perhaps one of the hardest ways: give attendees an already-built tool that does the work for them. I’ve done this in the past when I unveiled sp_BlitzFirst at the PASS Summit (then called sp_AskBrent, and since renamed), live for the first time in front of the audience, springing it on ’em.

Giving them a tool is hard because:

• You really gotta write the entire session first as the specs for the tool, because the tool has to deliver on what the session training was supposed to be all about
• You gotta write the tool – although these days with Claude Code, that’s way easier
• Then you gotta rewrite the session based on how you accomplish the goal using the tool

Building a tool is also hard because I’m basically automating myself out of some work. If I tell you how to do something really complex, then I can sell hours of training material on that, and you walk out of that class feeling like you learned a big quantity of information.

You don’t necessarily work faster that way though.

The more I worked on the Dev-Prod Demon Hunters workshop, the more clear it became that we, as an industry, really need a tool to make this easier. Before building the tool, I’d written out a giant troubleshooting checklist telling the audience all these places they needed to go to investigate these performance-killing demons. The better the session became, the more fleshed-out this checklist became, and it just isn’t realistic to expect performance tuners to look at:

• sys.configurations
• Database-scoped options
• Trace flags
• Query plan contents to see which histograms were used for estimation
• Histograms for all of those statistics to see if they’re different
• Last actual query plans to compare wait stats, spills, CPU metrics
• Different indexes & indexed views present on each server
• Different hardware capabilities
• And oh yeah, parameters used to compile the plans

So onstage Wednesday, I’ll unveil the tool for the first time and teach the audience how to use it. See you there!