https://www.pachadata.com/en/tags/ai/Recent content in AI on Rudi BruchezHugoenWed, 21 Oct 2026 18:46:32 +0200https://www.pachadata.com/en/docs/articles/sql-server/performance/query-store-agent/Wed, 21 Oct 2026 00:00:00 +0000https://www.pachadata.com/en/docs/articles/sql-server/performance/query-store-agent/<p><em>Co-written with Claude, who ran the lab tests and part of the research.</em></p> <div class="alert alert-success" role="alert"><div class="h4 alert-heading" role="heading">TL;DR</div> <p>Searching the Query Store by hand, query by query, takes hours. A command-line agent (Claude Code, Codex) does it on its own if it has <code>sqlcmd</code> and a dedicated login that holds only <code>VIEW DATABASE STATE</code> in each database: it reads the query texts, the plans and the runtime statistics, and gets error 229 on any table. For more caution, <code>DBCC CLONEDATABASE</code> produces a copy without data that contains the Query Store, to restore on another instance.</p> <p>The Query Store does not keep everything. In <code>AUTO</code> capture mode, an ad hoc query is only recorded from 30 executions or a certain cost onward: in my measurements, a read of the whole <code>Contact.Contact</code> table (120,140 rows) split into 25 queries left no trace. A query run from <code>master</code> or <code>tempdb</code> is recorded nowhere, and a <code>TRUNCATE TABLE</code> never is. The agent only finds what the Query Store kept.</p> </div>