Pinal Dave

How to find the query that ran at 3 a.m. after the fact. It uses nothing but what SQL Server 2025 keeps on its own. I planted a culprit, gave it eight disguises and buried it in four hundred innocent lookups. Then I tracked it down with Query Store. This is the poster. WANTED FOR READING 2,500,000 ROWS TO COUNT THEM Description A COUNT_BIG over dbo.Orders_S60, filtered on Amount and Status, neither of which has an index. Travels under a different literal each time, so no two sightings look alike.

Claude on SQL Server works best when it can read everything about performance and change nothing in production. A read-only login enforces that rule. A library of past cases then makes each investigation faster than the last. Where This Comes From A few of the teams I work with use the same loop every day. Their DBAs and developers find slow queries, test fixes safely and keep a record of what they learned. I asked one team how they run it.

A SQL Server deadlock, written up the way a recipe card is written. Ingredients, prep, method, and what to do when the sauce splits. It reproduces on SQL Server 2025 every time, and I have the timestamps and the deadlock graph to prove it. Serves 2 sessions. Prep 2 minutes. Cook time about 8 seconds. Difficulty: happens by accident.