Remote SQL Server Audit

Rudi Bruchez has thirty years of SQL Server experience and was a Microsoft MVP for eight consecutive years, from 2018 to 2025. He has audited or administered more than a hundred environments. Reports are available in English or French.

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 afterward.

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: readable code, queries in plain .sql files, open license. Your team can review it before running it, build it themselves, and check exactly what it reads.

What you receive

• A PDF report that connects each measurement to its consequence and a recommendation.
• A .sql file with the commands cited in the report, ready for your DBA to review.
• Three to five actions to take first, ordered against your context.
• A one-hour video call to walk through the findings and answer questions.

You can read a real, anonymized sample audit report before you order.

When this audit is useful

• Performance is degrading, but the available measurements do not point to a clear cause.
• You are considering spending money on processors, memory or storage.
• You are preparing a migration, an upgrade or a production release.
• You have doubts about backups, restores or the recovery plan.
• Your team has received conflicting recommendations and needs to set an order of work.
• Your security policy rules out giving a consultant remote access to production.

When to choose another engagement

This audit does not replace an emergency response for a server that is down. It also does not include four hours of fixes performed live or a complete review of the application code. It documents the state of the instance and helps you decide which work to start next.

Three decisions from real audits

Client, server, database and application names have been removed. The measurements needed to understand the reasoning have been kept.

Backups and recovery objectives

Two instances took one full backup and one transaction log backup per day, on the same volume as the data. The jobs succeeded, but the possible data loss was still twenty-four hours. Losing the volume could also have removed the backups along with the databases.

The recommendation started with separate storage and more frequent transaction log backups. Shrinking the log files without changing that arrangement would only have treated the consequence.

tempdb latency

Writes to the four tempdb data files took between 1.69 and 1.86 seconds. Reads remained at 1.5 ms, and the log on another volume wrote at 3.5 ms. The measurements pointed to the write path of the volume holding the data files.

The storage team could therefore investigate a precise scope, without being asked to replace the whole storage infrastructure.

Plan cache

One instance held 2.85 GB of single-use plans. Enabling optimize for ad hoc workloads looked appropriate, but it would only have affected about 90 MB. The remaining 2.76 GB came from Prepared plans produced in thousands of different forms by the application driver.

The application needed to change how it generated and reused queries. The SQL Server setting could still be useful, but it did not address the observed volume.

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. You order the audit through the order form: version, number of instances, what is untouchable at your site. I confirm the scope and send you the invoice. If you would rather check first that the audit answers your question, a 30-minute call is available before ordering. 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 neighbors);
• it does not read the contents of your application tables;
• it writes nothing to your databases;
• it changes no configuration;
• it is designed to run against a production instance;
• nine collectors dealing with more sensitive information are off by default. They include the text of running statements, Query Store plans, object definitions and deadlock graphs. An explicit flag is required to enable them.

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 authorizing 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.

The knowledge base makes sure that every planned area is examined. I write the report and order the priorities after reading the measurements and the answers provided during the analysis.

The report in detail

The published sample report is a real, anonymized document. Its measurements, findings and questions are those given 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, prioritized. 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.

Checks before delivery

One check compares the writing with the reference reports. Another compares the claims with the values in the archive. For example, a report cannot call a MAXDOP above 4 or a cost threshold for parallelism below 80 compliant. A claim that the collection cannot support is removed or turned into a question.

What the audit does not include

• 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, prioritized 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 afterward, if you want it

Remediation plan. The findings prioritized 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 for SQL Server and then Data Platform in 2008 and 2009, followed by eight consecutive years from 2018 to 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.

Order the audit

You can order the audit directly, with no preliminary call. If you would rather confirm that it fits your situation first, you can book a 30-minute call before ordering. The call is optional.

rudi@pachadata.com · Contact · LinkedIn