Remote SQL Server Audit

Before anything else

No agent, no remote access, no account to create for me

I never connect to your servers. You run a program, you get an archive, you send it to me. Nothing stays installed, nothing runs continuously, and there is nothing to uninstall afterwards.

Your diagnostic data is not hosted anywhere

It goes from your server to your archive, and from your archive to me. There is no platform, no online account, no database at a supplier accumulating a description of your infrastructure that would then have to be defended indefinitely.

The collector is free software

[github.com/rudi-bruchez/sql-auditor](https://github.com/rudi-bruchez/sql- auditor): readable code, queries in plain .sql files, open licence. Your team can review it before running it, build it themselves, and check exactly what it reads.

The problem, as it almost always presents itself

An application is developed on a server where only developers connect, with a limited data set. Tests pass, the demo is good, and it goes to production without a load test. At first all is well. Then performance degrades as volume and concurrency grow, and turns critical at the worst possible moment: peak activity.

People start looking for solutions. Add memory, spread the files, add processors, without knowing where the problem comes from and without being able to predict whether it will be solved. The gains are real but disappointing, and the situation comes back.

After twenty years of audits:

• most of the time the problem is not hardware. It comes from usage: the code, the configuration, the indexing, the data model;
• SQL Server already holds everything needed for a precise diagnosis, quickly, once you know where to look;
• few people know where to look.

A relational engine is not tuned by giving it a bigger machine. Real tuning goes through structures, code and indexing.

Three recent audits, with their measurements, are summarised on the case studies page.

The audit nobody ever runs

Everybody knows it ought to be done. Few companies have one done, and the reason is always the same: somebody has to come in, be granted access, and be given two or three days, most of which goes into the least interesting part of the job. Open SSMS, run a query, copy the result, repeat eighty times.

That part is mechanical, so it can be automated, and that is what I did. The interpretation and the recommendations are still done by hand.

How it works

1. A first conversation, free, thirty minutes. What you are seeing, on which version, how many instances, what is untouchable at your site. It is also where we check that the audit answers your question. If it does not, I say so.
2. You collect. I point you at the release to download: a single executable, no installation, no dependency, with the guide written for your DBA. You run it yourself, from your workstation or on the server. Collection takes a few minutes and produces a .zip archive.
3. You send me the archive, by whatever means you prefer. Nothing leaves your site on its own: the collector writes a file, and what happens to it is your decision.
4. I deliver the report within five working days of the archive reaching me, then we schedule the walkthrough.

What the collector does, and what it does not

This is the question any serious DBA asks, and it deserves a straight answer: you do not run an unknown binary against production.

• it issues SELECT statements only, against system catalog views and dynamic management views (sys.configurations, sys.dm_os_wait_stats, sys.databases and their neighbours);
• it does not read the contents of your application tables;
• it writes nothing to your databases;
• it changes no configuration;
• it reads without blocking, taking no locks on your production;
• nine more revealing collectors, the text of running statements, Query Store execution plans, object definitions, deadlock graphs, are off by default and only turn on with an explicit flag.

Read-only does not mean free. One collector samples pages of the largest heaps in each database to count forwarded records. On a very large instance, that is real I/O. The documentation says what it costs and how to avoid it.

The collector does not judge. There is no threshold, no score and no recommendation anywhere in its code. It gathers facts, it says what it could not gather and why, and it stops there. A tool that hands you 68 out of 100 does not say how it computed that number, nor what it chose to ignore to get there.

You can check it before authorising it

You can read the code, build it yourself, or, more simply, ask it to write out the queries it carries and have your DBA read them:

sql-auditor queries export --to .\queries

They are plain .sql files. There is nothing else.

Before collecting, one command says exactly what would run and which permission is missing, with the consequence of each refusal spelled out:

sql-auditor check

If a right is missing, the tool writes the matching GRANT to a file. It does not run it: your DBA reads it and decides. And if you refuse a right or a category, the refusal is recorded in the report rather than hidden. You know exactly what was seen and what was not.

What is looked at

More than eighty collectors, across eight areas, filtered by the version of your instance.

The archive also carries a manifest recording what ran, what was skipped, and why. So you know what was not seen.

What happens next, and why it is not automatic

The analysis draws on a knowledge base I maintain: 338 topics across 13 themes, distilled from forty-six real audits. Each topic describes a problem, why it matters, how to detect it, what to recommend, how to remediate, and, a section missing everywhere else, when not to flag it.

Here is the interesting number: of those 338 topics, 165 cannot be detected by a query. A backup plan that deletes the previous backup before the new one succeeds, backups never test-restored, an archive database that should have been set READ_ONLY, a restore runbook that does not exist: none of that reads out of a dynamic management view. It is seen by looking, and it is found by asking.

Half of what matters is therefore not in the collection, and that is the limit of an automated audit. The tool saves the days spent gathering facts. It does not replace the expertise that reads them.

In the same way, the execution plans in the archive come from Query Store: they say what the optimizer decided, not where the time went. For the handful of procedures that really weigh, I ask for an actual, post-execution plan, and I ask during the analysis, naming the procedures, not at delivery time.

That is also what explains the price. The corpus is mine, and the machine applies all of it to every server, without leaving a check out. You are buying that completeness, and the judgement that comes after it.

What you receive

An audit report, as a PDF, in English or French, together with a .sql file collecting the commands it cites, ready to be reviewed and run. They are yours.

You can read an example report before ordering: a real document, anonymised, with its measurements, its findings and the questions it puts to the client.

You can read an example report before ordering: a real document, anonymised, with its measurements, its findings and the questions it puts to the client.

Its shape comes from a survey of the thirty-five real reports that serve as the baseline.

• Every finding fits in three to five sentences: the measured value against the expected one, the concrete consequence on the machine, the recommendation, and the bare T-SQL.
• The order follows the audit method, not a severity ranking: server configuration, database configuration, waits, queries, indexes, sizes and compression, maintenance, security.
• No lecture on the engine. If a concept needs a general explanation, there is a link to the article that gives it. The report is not training material.
• No “Severity / Criticality / Impact” table. Measurement tables, yes: latency per file, memory configuration, the most expensive queries. Consultant tables, no.
• What is not serious is said to be not serious, in half a sentence, so that what is serious stands out.
• Questions, about what the machine cannot say: the retention you actually want, the business intent behind a 2 GB table named _temp, the other processes running on that server.

What the tooling cannot produce is added on top.

The first actions, prioritised. Three to five things to do first, written out, in the order I would do them if it were my server. The order does not follow the severity of the findings. It takes account of what you told me about your constraints, and I give my reasons for each one.

A one-hour walkthrough over video. We go through the findings together, in order of impact, and I answer questions.

Two checks run before delivery

The first measures the prose against the baseline of real reports and refuses what a language model writes spontaneously and I do not. The second confronts every claim in the report with the archive: it refuses a report that would call a MAXDOP above 4 or a cost threshold for parallelism below 80 compliant. A report asserting something the collection does not show does not go out.

What the audit does not include

Better said here than afterwards.

• Carrying out the fixes. The report tells you what to do and why, it does not do it for you.
• The full remediation plan: effort sizing for each fix, ready-to-run scripts, trade-offs against your maintenance windows and deadlines, a control collection after the changes. That is separate work.
• Analysis of the application code beyond what the executed queries reveal.
• Additional instances, billed separately.

The price

€2,500 excluding VAT for one instance: report, prioritised actions and walkthrough included. Fixed price, no time-and-materials billing, no overrun.

€1,000 excluding VAT per additional instance collected in the same pass.

This is deliberately cheap for an expert audit, and the reason is simple: collection is tooled, and the analysis draws on a base of findings built from twenty years of audits, applied systematically. What used to take several days of manual readings takes minutes. The time I bill is judgement time.

Payment

Invoice on order, settled before collection. Bank transfer, in euros.

For a client outside the SEPA area, the transfer goes to a local account, in euros, pounds or dollars depending on your country: you make a domestic transfer, with no correspondent bank fees and no international delay. A VAT number, or its business equivalent outside the European Union, is requested on ordering.

And afterwards, if you want it

Remediation plan. The findings prioritised against your real constraints, sized in effort, with the fix scripts and a second control collection after they are applied. You get a measurable result, with the before and after documented.

Support and training. Implementation alongside your teams, and skills transfer so your administrators can read a collection and repeat the exercise on their own.

Periodic follow-up. A regular collection, a difference report, and a defined number of days per month. Degradations become visible before they turn critical.

These are priced after the audit, once the scope is known. None of them is a prerequisite, and the audit stands on its own. Because the collection is reproducible, it can be run again: six months after the fixes, the same command says what moved.

Who writes the report

Rudi Bruchez, independent SQL Server consultant. Thirty years of experience, twenty years independent. Microsoft MVP SQL Server then Data Platform, 2008-2009 and 2018-2025.

Author of Optimiser SQL Server (Dunod) and Les bases de données NoSQL (Eyrolles, three editions), co-author of Pro T-SQL Programmer’s Guide (Apress) and of SQL (Pearson). More than 120 video courses published on LinkedIn Learning and Pluralsight. Microsoft certified trainer, 950 professionals trained.

More than a hundred SQL Server environments audited or administered, from small companies to large accounts: banking and insurance, industry, energy, retail, software vendors, healthcare, public sector.

Getting started

The first conversation is free and commits you to nothing. Write to me with what you are seeing, the SQL Server version, and the number of instances involved.

rudi@pachadata.com · Contact · LinkedIn