This is one of them fancy-pants 360 videos, so if you watch the video on YouTube, you can move the camera around to see a nice sunny cruise ship deck.

Prefer listening to this via podcast? Good news! You can now subscribe to Office Hours on Spotify, Apple Podcasts, Podcast Index, Podcast Addict, Podchaser, and anywhere else fine podcasts are found.

There’s a huge list of common things that might be causing it:

• Parameter sniffing
• Different database-level settings like compatibility levels and cardinality estimators
• Different server-level settings like CTFP and MAXDOP
• Different hardware capabilities, like different numbers of cores available, memory grant sizes available, or TempDB speeds
• Different indexes or statistics on the two databases
• Different contents of the statistics or indexes, different sampling rates
• Different activity happening on the two servers, like blocking

And a whole list of esoteric issues, too. So how are you supposed to quickly narrow down the differences between them, identify which differences are the most relevant to your query performance differences, and prioritize them quickly?

You couldn’t – until now, with sp_BlitzPlanCompare.

How sp_BlitzPlanCompare Works

It takes 3 parameters: @QueryHash, @LinkedServer, and @CompareToXML.

Call it with a @QueryHash and a @LinkedServer, and sp_BlitzPlanCompare reads the query plans on the local & remote servers (including the last actual plan if available in sys.dm_exec_query_plan_stats), discovers what objects are referenced in the plans (tables, indexes, statistics, etc), and then digs into the configuration settings on both the local & remote side to understand what influenced the plan generation. It even looks at live activity to see if the same query is getting different wait stats on the two servers.

It returns a prioritized list of differences between the two plans:

The output is prioritized, so the stuff that’s most likely causing the issues floats up to the top. Let’s zoom in:

In this case, the most likely cause for differences is that the cached plans on dev and prod have two different sets of values. The “Reproducer” row, if you scroll over to the far right of the output, has a call stack that runs the dev params first, then the prod ones, and vice versa, so you can see what happens when one of the plans is put in cache and the other set of parameters is run.

However, continue scrolling down: in this case, the LiveWait section shows that the prod server has an instance of this query running right now, and it shows you the wait stats in that session. This is useful for live troubleshooting when production is in trouble – because perhaps prod is experiencing wait types on that query that you wouldn’t expect.

Don’t wanna use linked servers? No problem! Run sp_BlitzPlanCompare with the @QueryHash you’re investigating, and it’ll generate some XML for you to describe the situation on the server you’re on. You can also use @QueryPlanHash if you know the plan, but not the query:

Copy that data, then connect to the other server, paste it, and run. Voila, the same comparison diagnostic data without linked servers.

Getting the Best Results

To get the most accurate, granular advice, enable the last actual plan setting in SQL Server 2019 & newer:

ALTER DATABASE SCOPED CONFIGURATION SET LAST_QUERY_PLAN_STATS = ON;

You’ll get more granular performance data about what’s happening on both servers, like memory grant differences, TempDB spills, wait stats, and thread statistics. This does have overhead, since it causes SQL Server to cache the last actual plan for every query that runs (not just the one you’re focused on).

I recommend turning this option on when you’re actively performance tuning a server, and you wanna be able to see what’s happening without re-running the queries yourself to get their full actual plans – but only if your server does under 1,000 batch requests/sec. (Above that number, the CPU overhead can start to become impactful.)

How to Get It and Learn More

It’s in the Optional Scripts folder of the First Responder Kit 2026, and the documentation is here. If you hit a bug, or you’d like to see something changed, create a new issue, choosing either a bug report or a feature request, and answer the questions that show up in the issue template.

Wanna learn more about how to use it and how to react to the problems it solves? I’m doing an all-day training workshop called Dev-Prod Demon Hunters at the PASS Data Community Summit in Seattle in November. Register now!

Microsoft’s been working on automatically indexing SQL Server databases. No, not that Azure SQL DB feature, but one that actually works on-premises, going back through all supported versions of SQL Server. This is the brain child of Conor Cunningham and Jianjun Chen – yes, those guys, legends of the SQL Server engine, who’ve been hard at work on this for over two decades.

And it doesn’t even need AI. Just plain ol’ T-SQL.

It’s super simple: the installation file, AutoIndex.sql, creates an Agent job and a series of stored procedures including auto_create_index and auto_drop_index. They watch the index usage and missing index DMVs, log their findings to tables, and trend the data over time in order to figure out which indexes to create, and which ones to prune back because they’re only slowing you down.

And it’s even free!

I don’t think the launch page is supposed to be live right now, but here it is on learn.microsoft.com. I have a hunch that when this blog post goes live, they’re gonna take that announcement down, so here’s the Wayback Machine archive of it, and here’s the zip download.

Go ahead, read that announcement, and then come back here.

Okay, you’re back – and you probably figured out by the date on the Microsoft page that it’s actually from 2006. <sigh> Yeah, that tool actually went live over twenty years ago, didn’t get updated, and then eventually got pulled. That’s kind of a bummer, eh?

It was visionary, back from the giddy optimistic days of SQL Server 2005 when the dynamic management views (DMVs) had just gone live. The world seemed full of hope and dreams, like the database might actually become self-tuning. We had the data! The pieces were all there! We coulda been a contender! Wait, actually, we’re still contenders. Anyhoo.

I asked a couple of LLMs to review the code, and they pointed out some amusing stuff, but I love this note from Claude:

The comment in auto_drop_index — “in the future, we will add a special bit inside metadata to distinguish” — is exactly what shipped as sys.indexes.auto_created in Azure SQL Database a decade later. The recommendations table with counts, history, and execute/disable is recognizably the ancestor of sys.dm_db_tuning_recommendations and automatic tuning’s create/drop-index with verification and revert. The prototype’s missing pieces — checking existing indexes, verifying impact after creation, rolling back regressions — are precisely what the production feature added. Good bones, and a nice artifact of how far the idea had to travel.

My first instinct was, “No, that couldn’t have been a decade later – it had to be longer than that” – but indeed, it dropped around 2017.

It’s wild to think that it’s been a decade since Azure SQL DB got automatic index tuning, two decades since Conor and Jianjun’s initial blog post, and we still don’t have anything like it for SQL Server. I gotta imagine that some enterprising person out there is using AI right now to build something like it, and when they release it and get it working, they’ll be as well-known for their script as Ola Hallengren is synonymous with index maintenance.

The pieces are all there. We’re just waiting for someone to put ’em together. Could be you!

A few really interesting things came up that I wanna share with you because I know a lot of y’all don’t get out to meet your peers in person at regional or national conferences. I feel you. I try to bring you along with me.

We were talking about AI brands, and out of curiosity, I asked for a show of hands for each brand of AI to see who was using each model. Almost everyone in the audience raised their hand for almost every brand, Anthropic, Google, Microsoft, and OpenAI. That completely blew me away. This wasn’t a management or executive conference – these were developers, DBAs, BI professionals, and college students. AI isn’t just pervasive, but all of the brands were pervasively used.

Shortly later, one of the audience questions was, “How do we stop the AI arms race? For example, right now people are using AI to apply for jobs, and companies are using AI to filter out those AI-written job applications. That seems like a waste – how do we get back to real humans doing this stuff?” The panel had a discussion about how the HR and job application processes have been broken for decades, and that going back to real humans wouldn’t fix anything, but the questioner persisted – that’s just one example of the arms race, he said. (Which is a great point – AI is disrupting all kinds of stuff.)

When you place that question alongside the fact that almost everybody in the audience is already using all kinds of AI tools, though, I don’t think it’s realistic to roll back that arms race. It’s just too late. This is the new reality.

At the event, I was talking to a friend about what it’s like to interview people in the age of AI, and he commiserated about how some candidates just give hand-wavy answers now about how they do things. There’s now a generation of employees who put things on their resume as if they’ve done ’em, but … all they really did was prompt those things, and they don’t know the underlying mechanics of how the thing was done. They can even talk a good game, reciting some of the challenges encountered during the project, but if you drill a little deeper as to how they overcame those obstacles, well … it falls apart.

I don’t know what the right answer there is, either, because to some extent, these people did do that task, and if they were gonna do it again today, as long as they were allowed to use AI to accomplish that task – is that good enough? I’m not sure. It’s like if I asked, “Have you ever configured an Availability Group?” If they used the setup wizard, well… they did do it. I think the underlying question is wrong, and it’s time to start turning the questions into the post-prompting work that people have to do – like how do you know if an existing AG setup is correct, or how do you troubleshoot a broken AG. But are people even going to do that without AI? I’m not sure. In some environments, yes – but it’s also a question of how long that will go on, given how good local models are becoming.

Another audience question was, “What happens if a giant AI company’s IPO fails, like Anthropic or OpenAI?” Rob Volk had a succinct answer: it’d be just like when Lehman Brothers failed back in 2008. There’d be a recession, and the US government would try to contain the failures. Things would be financially rough for a while.

I pointed out, though, that that still wouldn’t stop AI: open source local models like Qwen and DeepSeek can already be run locally with open source apps like DwarfStar as long as you’ve got a reasonably powerful Mac or an NVIDIA GPU. If there wasn’t ever another open source local model release, I’d still be quite happy using Qwen and DeepSeek locally on my laptop, and the way I work would never go back to the old way.

Several questions came up that could all be reworded as, “How do I avoid getting laid off?” The audience was almost all using AI already, so they knew firsthand that they were much more productive in less time. They had valid concerns that their companies would see that, and start laying people off because the remaining staff could pick up the work.

Nobody had a silver bullet for that one.

Tim Radney had a good point: the first sign of trouble would be if you can finish all your work in a 40-hour week. If you can, you need to try to become more proactive, to look further down the road at the next problems the company wants you to solve. If you run out of work, the company’s gonna notice that. You also need to be visible in the company: you need to be seen as the one everybody turns to for quick, accurate solutions.

Multiple folks on the panel pointed out, though, that the days of company loyalty to employees is long, long gone. (AI didn’t introduce this phenomenon.) Companies exist not for your benefit, but for the owners’ benefit, and if they can save money by doing something more efficiently without you, they will. Don’t think that by putting in long hours, they’re going to reward it.

I half-jokingly suggested that attendees look to /r/overemployed for tips on how to stay employed. That subreddit is all about getting multiple full-time remote jobs at once, staying employed at all of them, and avoiding detection. It’s hilarious to read their stories about nearly getting caught. I’m sure a good chunk of it is just fiction, but … some of it clearly isn’t. <sigh>