SQL Server blocking, told as a choose-your-own-path story. You are the on-call DBA. The phone has gone. The diagnosis and the kill were run in the lab on SQL Server 2025 and measured. The other branches are reasoned, and the text says which is which.

Msg 1222: Lock request time out period exceeded.
(after 8,009 ms)

SELECT r.session_id, r.blocking_session_id, r.wait_type, r.wait_time / 1000 AS wait_s,
       r.status, b.event_info
FROM sys.dm_exec_requests r
OUTER APPLY sys.dm_exec_input_buffer(r.session_id, NULL) b
WHERE r.session_id <> @@SPID;

session_id  wait_type  wait_s  status     input
52          WAITFOR    9       suspended  INSERT dbo.IncidentLog ... ('archive', 'begin ...

SELECT s.session_id, s.program_name, DATEDIFF(SECOND, t.transaction_begin_time, SYSDATETIME()) AS open_s,
       (SELECT COUNT(*) FROM sys.dm_tran_locks l WHERE l.request_session_id = s.session_id) AS locks
FROM sys.dm_exec_sessions s
JOIN sys.dm_tran_session_transactions st ON st.session_id = s.session_id
JOIN sys.dm_tran_active_transactions t ON t.transaction_id = st.transaction_id;

session_id  program_name  open_s  locks
52          SQLCMD        11      3,367

KILL 52;

10:14:56.586  branch KILL: killing spid 52
10:14:57.238  rollback finished, session gone after 652 ms
10:14:57.238  rows still archived after kill: 0

How this SQL Server blocking incident was built

A 1,200,000 row ledger table. One session updates 400,000 rows and sleeps ninety seconds inside the transaction. A second session, with an 8-second lock timeout, plays the application. A third plays you.

The timings above are from the log those sessions wrote. The 652-millisecond rollback is a measurement, not a guess. The log’s clock reads 10:14 rather than 2:14. I ran the incident at ten in the morning, which is the only respectable time to rehearse one.

If your shop has a job that pauses inside a transaction, I’d like to meet it before 2 a.m. does.

An incident is not a mystery, it is a transaction somebody left open.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on SQL Server Blocking at 2 a.m.: You Are the On-Call DBA

It Started Because Excel Broke My Scripts

Like every DBA, I kept a folder of scripts I used again and again. Backups, index maintenance, the query that shows how tables connect. I stored them in Excel, and Excel kept breaking the formatting. So I tried a blog, the way you try a new notebook.

My first post was a query to display foreign key relationships. There was no introduction and no hello, only the query. The post was for me.

I named the blog after CFAuthority, a site I loved from my ColdFusion days. The name sounded bigger than I was. I was a developer with a folder of scripts and a habit of losing them.

My First Readers Were My Parents

When I started this blog, I was living outside India for work. My parents were with me then. My dad, Rajendra, and my mom, Renuka, followed this little blog more closely than I did.

They checked the visitor count like a cricket score. “Today five people came to your blog.” The next day it was three. Then nine. Every number got the same happy announcement.

To them it was simple and a little magical. “You write, and people read.” Nine readers felt like a full hall. Their joy was the first motivation this blog ever had, and some days it was the only one.

My dad is no longer with us. Rest in peace, Papa. This twentieth anniversary belongs to you too. Mom is with us, and I wish Mom the best of health. You two were counting my readers long before anyone else did.

A Stranger Found My Diary

One day an email arrived from someone I had never met. They liked my index maintenance script and wanted a small change. They had found it through Lycos.

That email changed how I saw the blog. My diary was public. Anyone in the world could read it, and one person already had.

That was the day SQLAuthority stopped being a notebook. Somebody out there was waiting for the next script, and I didn’t want to let them down. I still don’t.

Today there are almost 6,000 posts on this blog. At the 13th anniversary I counted 4,918. I’ve stopped being surprised by the number. I haven’t stopped being grateful for the people behind it.

Six Days Old, and Already in a Sentence

On September 1, 2009, Nupur and I became parents. Shaivi arrived at 7:03 in the morning, and our lives were rewritten in one breath.

We had shortlisted nearly 100 names. My mom, Renuka, found the one we chose, in our old scriptures.

Six days later I wrote about it on this blog, in between posts about SQL Server. In that post, Baby SQLAuthority, I added one sentence I hadn’t planned to write. It read: “I am sure that my daughter Shaivi will make me proud one day.”

I didn’t know then that a sentence can wait. That one waited for years.

The Youngest Speaker in the Room

On April 20, 2013, the Bangalore SQL user group held a Women in SQL day. More than a hundred people came. The organizers wanted a surprise for the end: the youngest SQL speaker anyone had seen.

Shaivi was three years and seven months old. We stood on that stage together, and Shaivi said a few words about SQL Server to a room of engineers. I wrote about it the next day in Youngest SQL Speaker.

I have spoken at conferences in fourteen countries. In one year alone I presented at eighteen international events. None of those stages felt like that one.

Nupur, and the Hours Behind Every Post

Almost 6,000 posts means almost 6,000 drafts that Nupur, my wife, read before you did. I was the one typing, but I did not bring this blog through twenty years by myself.

Nupur edits every single post I publish. She catches the typo I can no longer see and the sentence that made sense in my head but not on the page. When I think a post is finished, she gives it another careful read.

Her name is not in the byline, yet her work is in the version you read. Editing can be invisible when it is done well. The hours she gave this blog deserve to be seen. Nupur, thank you for every page you read, especially when I was ready to call it done.

The Twentieth Book Has Shaivi’s Name on It

Over these twenty years I wrote nineteen books. I know what it takes to finish one: the work at the desk and the patience of the people waiting beyond it.

Shaivi wanted to help our family reach twenty books for the twentieth year of SQLAuthority. She wrote Balance, Bounce & Believe: A Practical Guide for Young Gymnasts, drawing on her life as a gymnast. When I saw her name on the cover, I thought of the six-day-old baby I had introduced to you on this blog.

Nineteen books by me. The twentieth is hers. Twenty books in our family, in the twentieth year of this blog. I could have counted posts or readers today. This is the number that stopped me.

I wrote in 2009 that Shaivi would make me proud. She had done that long before she became an author. Still, opening a book she made felt different. For a moment, I was simply her reader.

Brent Ozar: Because You Are, I Am

There is a story from the Mahabharata I grew up with. Dronacharya was the greatest archery teacher of the age, and taught only the princes of the royal court. A young archer from the forest, Eklavya, came to learn and was turned away.

Eklavya went back into the forest and shaped an image of Drona out of clay. Every day, Eklavya practiced in front of that clay teacher, as if the real one were watching. Years later, Eklavya had become one of the finest archers alive, taught by a teacher who never knew.

I am Eklavya in this story, and Brent Ozar is my Drona. I learned from Brent’s posts and Office Hours for years, from far away, long before we met.

The story ends with Drona asking Eklavya for a right thumb as the teacher’s fee. Eklavya gave it without a word. Brent never asked me for anything. Brent only kept giving.

Some friendships show up in the comments long before they show up in life. Brent left a first comment here in 2008. It was a practical warning about msdb history growing too large.

On September 1, 2009, I posted that our baby had arrived. Brent was there that day too: “WOOHOO! Congratulations, sir!” In June this year, on Shaivi’s author post, Brent wrote again: “Congratulations to all of you!”

In between, Brent called me a friend in 2011 and a natural presenter in 2017. Brent cheered my anniversaries and wrote that Nupur and I put real effort into this work. In 2023 I was a surprise guest on Brent’s Office Hours. For years Brent has been my mentor in this field.

In Hindi we say “tu hai to main hoon.” Because you are, I am. Brent, this blog is here partly because you are. Thank you.

What 20 Years of SQLAuthority Taught Me

People ask me for the secret. There isn’t one. I wrote the next post, then the next one, on the easy days and the hard ones.

Consistency looks like discipline from the outside. From the inside it looks like people: the reader waiting for an answer, and the family making room for it.

I’ve made mistakes here too. Some of my old answers were wrong, and readers told me. This month I went back and corrected a few of my replies from 2007. Twenty years late is still better than never.

If you have a folder of scripts you keep losing, start a blog. Don’t wait until you feel ready. I wasn’t.

Thank You

To every reader who asked a question, left a comment or found a mistake: thank you. Twenty years ago this was one query saved in a hurry. You turned it into a place people come back to.

To Mom, and to Papa in loving memory: you counted my first readers when there were only five. Thank you for believing it mattered.

To Nupur, for reading every draft and giving this work your time again and again: thank you. To Shaivi, for making the twentieth book entirely your own: I am so proud of you.

Tomorrow there will be another post. There usually is.

Twenty years of SQLAuthority is not a count of posts, it is the people who made each one possible.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on 20 Years of SQLAuthority: Twenty Books, One Family, and a Diary That Grew Up

Cardinal Rules. A Saturday cartoon about AI and databases.

Every shop has one. Nine hundred lines, no comments, a name like usp_ProcessFinal2, and a quiet agreement that nobody opens it during month end.

Cardinal can read it in a second, and this is the honest good news. A model is genuinely excellent at the mechanical part. It will tell you what the procedure touches, which tables it writes, where the cursor is, that the same table gets updated three separate times, and that one branch has been unreachable since a parameter default changed.

That is real work, and it used to take a careful afternoon. Ask for it. It is one of the best uses of AI in database work right now.

Then comes the part where the lights flicker. There is a clause that only fires on Tuesdays. Cardinal can describe exactly what it does and has absolutely no idea why it exists. The why was a promise made to a customer in 2011 by somebody who left in 2014. It is not in the code. It was never in the code.

So the procedure is not haunted by its logic. It is haunted by a decision nobody wrote down. Read the code with the machine, then go and find the one person who remembers the Tuesday, and this time write it in a comment with a date and a name on it.

Cardinal Rule

Code nobody understands is not an asset, it is a haunting.

The machine reads what the code does. Only people remember why.

Cardinal has refused to open the procedure again until November. On the desk this season: AI: Nobody’s in There. But we’re still in here. (on Amazon) and 100 AI Interview Questions and Answers for Data Professionals (Kindle, also on Amazon.in, paperback and audiobook).

Next Saturday, the VP announces that the AI says the backups are fine.

Ask the machine what the code does. Ask a person why it does it.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on AI Read the Procedure Nobody Dares to Touch

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.

Here’s how the poster was made.

The crime: one query that ran at 3 a.m.

I cleared Query Store so the only history was what this test made. Then two hundred innocent lookups, one customer each, a few reads apiece.

Then the culprit, eight times, with a different amount in the WHERE clause each time. It looked like eight separate ad hoc statements. Then two hundred more innocents on top, to bury it.

Then I flushed Query Store to disk and started the investigation cold. As if I’d been handed the alert a minute ago.

Step one: who did the most reads?

The first query any investigator runs. Everything Query Store saw, sorted by total reads.

DECLARE @from DATETIME2(3) = DATEADD(HOUR, -1, SYSUTCDATETIME()),
        @to   DATETIME2(3) = SYSUTCDATETIME();

SELECT TOP (5) q.query_id, LEFT(qt.query_sql_text, 52) AS query_text,
       SUM(rs.count_executions) AS execs,
       SUM(rs.avg_logical_io_reads * rs.count_executions)
         / SUM(rs.count_executions) AS avg_reads,
       SUM(rs.avg_logical_io_reads * rs.count_executions) AS total_reads,
       MAX(rs.last_execution_time) AS last_seen
FROM sys.query_store_query q
JOIN sys.query_store_query_text qt ON qt.query_text_id = q.query_text_id
JOIN sys.query_store_plan p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats rs ON rs.plan_id = p.plan_id
WHERE rs.last_execution_time >= @from
  AND rs.first_execution_time <= @to
GROUP BY q.query_id, LEFT(qt.query_sql_text, 52)
ORDER BY total_reads DESC;

query_id  query_text                                     execs  avg_reads  total_reads  last_seen
7         (@x bigint)SELECT @x = COUNT_BIG(*) FROM dbo...  1      41,823     41,823       09:35:02
8         (@x bigint)SELECT @x = COUNT_BIG(*) FROM dbo...  1      41,823     41,823       09:35:02
6         (@x bigint)SELECT @x = COUNT_BIG(*) FROM dbo...  1      41,823     41,823       09:35:01
5         (@x bigint)SELECT @x = COUNT_BIG(*) FROM dbo...  1      41,823     41,823       09:35:01
3         (@x bigint)SELECT @x = COUNT_BIG(*) FROM dbo...  1      41,823     41,823       09:35:00

Five suspects at the top, each seen once. They look like five different people. That’s the disguise working.

Two things about this query, and an earlier draft of this post got both wrong.

Aggregate before you rank. One runtime stats row is one plan in one interval. Rank the raw rows and the arithmetic goes wrong. A heavy query that ran all week can sit below one that ran once. Group by the query first, then sum.

Declare the window once and keep it. My earlier version filtered by interval in step one and then dropped the filter in steps two and three. In a freshly cleared lab that gives the right answer. In a production Query Store holding weeks of history it would not.

Step two: take off the disguise

The query hash is computed from the statement shape with the literals stripped out. Eight statements with different amounts share one hash.

SELECT TOP (3) q.query_hash, COUNT(DISTINCT q.query_id) AS distinct_texts,
       SUM(rs.count_executions) AS execs,
       SUM(rs.avg_logical_io_reads * rs.count_executions) AS total_reads
FROM sys.query_store_query q
JOIN sys.query_store_query_text qt ON qt.query_text_id = q.query_text_id
JOIN sys.query_store_plan p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats rs ON rs.plan_id = p.plan_id
WHERE rs.last_execution_time >= @from
  AND rs.first_execution_time <= @to
GROUP BY q.query_hash
ORDER BY total_reads DESC;

query_hash          distinct_texts  execs  total_reads
0x1E34C17E155296A7  8               8      334,584
0xB3D890533C39CB7C  1               394    3,819

One suspect, eight disguises, 334,584 reads. I issued four hundred innocent lookups and Query Store recorded 394 executions of them, 3,819 reads in total. The culprit did 88 times the reads of everyone else combined.

Same window as step one. That is the whole point of declaring it once.

Step three: the accomplice

Query Store keeps the plan. The plan names what it touched.

;WITH inwindow AS (
    SELECT q.query_hash, p.plan_id, p.query_plan,
           p.is_parallel_plan, p.last_execution_time,
           rs.avg_logical_io_reads * rs.count_executions AS reads
    FROM sys.query_store_query q
    JOIN sys.query_store_query_text qt ON qt.query_text_id = q.query_text_id
    JOIN sys.query_store_plan p ON p.query_id = q.query_id
    JOIN sys.query_store_runtime_stats rs ON rs.plan_id = p.plan_id
    WHERE rs.last_execution_time >= @from
      AND rs.first_execution_time <= @to
), top_hash AS (
    SELECT TOP (1) query_hash FROM inwindow
    GROUP BY query_hash ORDER BY SUM(reads) DESC
), worst_plan AS (
    SELECT TOP (1) plan_id FROM inwindow
    WHERE query_hash = (SELECT query_hash FROM top_hash)
    GROUP BY plan_id ORDER BY SUM(reads) DESC
)
SELECT TOP (1) w.plan_id, w.is_parallel_plan,
       CAST(w.query_plan AS XML).value('count(//*[local-name()="RelOp"])', 'int') AS operators,
       CAST(w.query_plan AS XML).value('(//*[local-name()="RelOp"][.//*[local-name()="Object"]]/@PhysicalOp)[last()]', 'varchar(40)') AS access,
       CAST(w.query_plan AS XML).value('(//*[local-name()="Object"]/@Table)[1]', 'varchar(40)') AS accomplice_table,
       CAST(w.query_plan AS XML).value('(//*[local-name()="Object"]/@Index)[1]', 'varchar(40)') AS accomplice_index,
       CAST(w.query_plan AS XML).value('(//*[local-name()="RelOp"][.//*[local-name()="Object"]]/@EstimatedRowsRead)[last()]', 'float') AS est_rows_read
FROM inwindow w WHERE w.plan_id = (SELECT plan_id FROM worst_plan);

plan_id  is_parallel  operators  access                 accomplice_table  accomplice_index  est_rows_read
3        0            2          Clustered Index Scan   [Orders_S60]      [PK_Orders_S60]   2,500,000

Two operators. A scan of the clustered index, reading every one of 2,500,000 rows, and an aggregate on top. There’s no index on Status or Amount, so there’s nowhere else to go.

Two details worth copying. Rank that hash’s plans by the reads they did, not by which ran last. The same query shape ran again after I built the index. That newer plan is innocent. And take the innermost operator that touches the object. The first one in the plan is the aggregate sitting above it.

That’s the reward on the poster, and I paid it. With a 48 MB index on (Status, Amount), the same count went from 41,823 reads to 4,886. It ran as a seek on the new index.

Step four: last seen

SELECT i.start_time, i.end_time, SUM(rs.count_executions) AS execs,
       SUM(rs.avg_logical_io_reads * rs.count_executions) AS reads,
       MIN(rs.first_execution_time) AS first_seen, MAX(rs.last_execution_time) AS last_seen
FROM sys.query_store_query q
JOIN sys.query_store_plan p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats rs ON rs.plan_id = p.plan_id
JOIN sys.query_store_runtime_stats_interval i
  ON i.runtime_stats_interval_id = rs.runtime_stats_interval_id
WHERE q.query_hash = 0x1E34C17E155296A7
  AND rs.last_execution_time >= @from
GROUP BY i.start_time, i.end_time;

interval_start_utc  interval_end_utc  execs  reads    first_seen_utc       last_seen_utc
2026-09-22 09:00    2026-09-22 10:00  8      334,584  2026-09-22 09:35:00  2026-09-22 09:35:03

The interval is an hour wide, which is the default, so the row covers 09:00 to 10:00. The execution times inside it are what pin the crime down to three seconds. Filter on those, not on the interval’s start. Otherwise an interval that began forty-five minutes ago drops out of your window.

Eight runs in three seconds isn’t somebody typing. It’s something automated, and Query Store can’t tell me which job. That’s the next place to look, in the job history or the application log.

Why Query Store and not the plan cache

The plan cache would have found it too, and I checked. But the plan cache forgets. A restart, memory pressure, or a busy afternoon and the evidence is gone. Query Store writes to disk and keeps it for as long as you tell it to. That’s why it’s the tool for anything that happened while you were asleep.

It was on by default on this database, capturing everything, with a 1,000 MB budget. Check yours before you need it.

Hang this one up

The four queries above are the whole method. One window, then total reads, then group by hash, then the plan, then the interval. Ten minutes from alert to poster, and the index took another two.

If you’d like these queries tuned for your instance, with the intervals and retention set right, that’s a morning’s work.

A mystery query is not gone, it is in Query Store wearing a different literal.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Find the Query That Ran at 3 a.m.: A Wanted Poster

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. They shared their working document, and I removed everything specific to them.

None of it needs new servers or special tools. With Claude, a production server and a staging copy, you can do it yourself, starting this week. Teams that run this loop get evidence every morning. Other teams keep guessing, and the gap grows each week.

How the Loop Fits Together

Production only ever sees Claude’s reads. Staging sees Claude’s changes. A person decides what ships. Three stages build on each other: start this week, make it a habit, then automate it.

Stage 1: Start This Week

Five days, one real finding. Aim for one tested fix by Friday.

Day 1: The Read-Only Login and a Staging Copy

One login on production sees performance data and definitions, never table rows. Restore a fresh copy of production to staging the same day. The login is the guardrail, not the prompt.

-- On production: a login that can look, not touch
USE master;
CREATE LOGIN claude_reader WITH PASSWORD = 'Your strong password here';
GRANT VIEW SERVER STATE TO claude_reader;
GRANT VIEW ANY DEFINITION TO claude_reader;
-- Repeat in each database Claude should read
USE YourDatabase;
CREATE USER claude_reader FOR LOGIN claude_reader;
GRANT VIEW DATABASE STATE TO claude_reader;
GRANT SHOWPLAN TO claude_reader;
-- SQL Server 2022 and later: VIEW SERVER PERFORMANCE STATE is narrower

In my test on SQL Server 2025, the login read waits, plans and Query Store, and every SELECT on a table failed with Msg 229. Test yours with EXECUTE AS LOGIN before you hand it over.

Day 2: The First Morning Report

Save this prompt in Claude’s project instructions, so every run asks the same questions.

Using the claude_reader login on PROD, review the last 24 hours: top waits,
top queries by CPU and duration from Query Store, plans that changed or got
slower, and blocking. For each finding, give one hypothesis, its evidence and
the test to run on STAGING. Change nothing on PROD.

Claude turns the answers into a short list. Each line carries its evidence and a test, so nobody starts the day guessing.

This is an illustrative example. The object names and numbers are made up.

Day 3: Prove One Finding on Staging

Pick one finding and ask Claude for one hypothesis you can test. A good hypothesis names an object and a cause. Claude runs the query on staging, applies the change and runs it again. Then it compares duration, CPU, reads and plan shape.

Day 4: Save the First Replay Pack

Save everything from the test in one folder, so anyone can rerun it a month later. A wrong idea gets a pack too. That stops the team testing it twice.

order-history-slowdown\
  notes.md       idea, result
  query.sql      text, parameters
  plan-before    actual plan
  plan-after     actual plan
  baseline.csv   time, CPU, reads
  change.sql     the tested fix
  rollback.sql   how to undo it

Day 5: Review, Decide and Ship

A person reads the evidence, then approves the change, asks for another test or rejects it. The DBA team ships it in a planned window with the rollback ready. Staging can’t copy live traffic, so a gain there is evidence, not a guarantee. The next morning, Claude confirms the gain held on production.

You’re ready for Stage 2 when you have one reviewed fix, one replay pack and a morning report you read every day.

Stage 2: Make It a Habit

Stage 1 proves the loop works. Stage 2 makes it run every day, so it no longer depends on one enthusiastic person.

The Routine

Don’t save this for emergencies. When a crunch comes, the baseline and the replay packs are already there.

• Daily, about 20 minutes: Claude writes the morning report. The team picks one or two items, and Claude tests them on staging.
• Weekly, about an hour: replay the week’s packs, approve what passed and book the window. Note where Claude was wrong and update its instructions.
• Monthly, half a day: refresh staging from a recent backup, review indexes and statistics, and retire packs that no longer matter.

A Pack for Every Case

Every investigation gets a replay pack, wrong ideas included. Keep the folder layout and the file names identical, so packs are easy to review and easy to search.

The Past Cases Library

Every morning report and replay pack goes into a shared folder that Claude can search. This setup is called RAG, short for retrieval augmented generation. Before a new investigation, Claude reads past cases that touched the same query, table or wait type.

Without that memory, each investigation starts from zero, and lessons leave when someone moves on. With it, the hundredth case is faster than the first. The library becomes the team’s best documentation.

Your first replay pack is the library’s first entry. Then add one sentence to the morning prompt: “Check the past cases library first.”

The Ground Rules

• No write access to production, ever.
• One change at a time, each with a rollback script.
• Staging holds masked data where required.
• Reports stay internal. Query text has values: in my test, the Query Store text of one call showed the date I typed.
• Nothing ships until a person reads the evidence.

You’re ready for Stage 3 when the routine has run for a few weeks without anyone chasing it, and Claude cites past cases in its findings.

Stage 3: The Ultimate Setup

This is where the teams that run the loop every day end up. Each piece builds on what you already have.

• A schedule: a scheduler calls Claude through the API with the same morning prompt and the same read-only login. The report is waiting when the team logs in.
• A second opinion: the same evidence goes to Claude and to OpenAI’s Codex. A fix moves ahead when both agree, and a DBA settles any difference.
• One person leads: a senior member owns the shift. They keep the instructions and the library current, and bring DBAs and developers into the same loop.
• The library as memory: new people read it to learn the system, and the daily work keeps it current.

A review step is too slow in a real outage. Your DBA acts first, and the loop pays off on the ordinary days around it.

You’ve arrived when the report is waiting every morning, two models have checked each fix and the library is the first place anyone looks.

Advanced: How the Pieces Connect

Claude reaches production through Claude Code on a jump box that the DBA team controls. It connects with sqlcmd, or with an MCP server for SQL Server, and only as claude_reader. Staging gets its own login, which can change things there and nowhere else. Keep both passwords in the operating system’s credential store, never in the prompt.

Start the library as a plain shared folder, one folder per case, with the same file names every time. Claude Code searches it with ordinary text search, and that’s enough while the library is small. As it grows, add a vector index over the notes and reports. Then Claude finds a case by meaning, such as “slow after a statistics update”, not only by exact names. Tag every pack with the query hash, table and wait type, so both kinds of search land on the right case.

Give This Post to Claude

You don’t need to build this by hand. Share this post with Claude and ask:

Here is a guide for tuning SQL Server
with Claude:
https://blog.sqlauthority.com/2026/10/29/claude-on-sql-server-read-prove-then-change/
Help us set it up, one step at a time.
Ask before anything touches a server.

Every stage here is something your team can do on its own. If you’d rather have it running in weeks than months, I set this up for teams. My consulting page has the details.

I wrote about the habit behind the DBA review in How to Check AI Fast. It’s an essay about putting your checking effort where a wrong answer costs the most. It’s one of thirty essays in my book AI: Nobody’s in There. But we’re still in here. All of them are free to read online, and the paperback is on Amazon.

Claude is not a replacement for your DBAs, it is the investigator that gives them evidence every morning.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.

First appeared on Claude on SQL Server: Read, Prove, Then Change