What the Diagnostic collector reads — and what it never touches

You're about to run our script against a production SQL Server. You should not take that on faith. This page tells you exactly what the collector does, what it reads, what it never touches, and how to verify every line of that yourself before you run it.

It's a readable script. Read it before you run it.

The collector is a readable PowerShell script that runs read-only T-SQL — not a compiled binary, not an installed agent, not a service. Every query it executes is right there in the source. Open it in your editor and read it line by line before it goes anywhere near your environment. If your change process requires review and sign-off first, that's exactly what it's built for.

Your download is served over TLS from our client portal, with token-authenticated access.

You run it. You review the output. You upload it.

The collector makes no outbound connections while it runs. No telemetry, no phone-home. (One optional version check exists behind a switch — it is off by default.) It writes its output to a local JSON file: plaintext, not encoded, not compressed, with a SHA-256 sidecar so you can confirm the file you upload is the file it wrote. Run the collector standalone and you can open that file and inspect every line before you upload it through the client portal. If you never upload it, we never see it.

What it reads

System metadata, statistics, and performance counters — around 95 system DMVs and catalog views, in these groups:

  • Configuration — sys.configurations, sys.databases, instance and database-scoped settings. Why: a large share of high-severity findings are configuration, not code.
  • Performance — wait statistics, performance counters, query stats, sessions and requests, I/O file stats, and CPU history from the ring buffer (data SQL Server has already recorded — not live stress sampling). Why: this is where “what's actually slow” comes from.
  • Query Store (SQL Server 2016+) — query, plan, and runtime statistics. Why: plan regressions and top resource consumers.
  • Storage — file layout, log info, volume stats (opt-in). Why: capacity, growth, and VLF findings.
  • Security — server principals, login names and policy flags (never password hashes), permissions, audits, encryption state. Why: sysadmin sprawl and audit-readiness checks.
  • HA/DR — availability group health, backup history from msdb, log shipping state. Why: the findings that matter at 2 am.
  • Agent and Database Mail — job configuration and history, alerts, operators. Configuration only — never mail content.
  • Indexes and statistics — index metadata, missing-index DMVs, statistics properties. Physical index stats are opt-in and capped.

One caveat we'd rather state than bury: the collector captures the SQL text of your most expensive queries from the plan cache and Query Store, truncated. If an application embeds literal values in its SQL instead of parameterising, those literals can appear inside the captured query text. It is query text, never query results — no rows from any table are ever read or returned. If that's still too much for your environment, an -AnonymizeData switch aliases instance and host names, and you can review the output file before anything is uploaded.

What it never touches

Each line below is verified against the shipped script's full source.

  • It never queries your tables. No SELECT against any user table anywhere in the script — metadata, statistics, and counters only.
  • It makes no changes to your databases. Zero writes to any database table; zero objects created, altered, or dropped. The full asterisk: it uses two temporary worktables in tempdb to capture DBCC output, automatically removed. They exist for seconds and never touch your databases.
  • It never collects password hashes. Login names and policy flags only.
  • It never executes xp_cmdshell. The string appears in the script only to check whether the option is enabled — as a security finding.
  • It installs nothing. No agent, no service, no scheduled task. When the script finishes, nothing of ours is running.

Permissions it needs

The collector does not require sysadmin. At startup it checks what your login can do and skips what it can't, recording the reason in the output — it degrades, it doesn't fail.

For a near-complete collection: VIEW SERVER STATE, plus the ability to read system catalog views in each database. A handful of extras are sysadmin-gated and silently skipped without it: error log entries (opt-in anyway), trace flag inventory, and legacy VLF counts on older versions.

Footprint and runtime

On our lab instance (SQL Server 2022, three user databases), a full default collection takes about 41 seconds. That is a lab-tested figure, not a projection — production instances with many databases take minutes, not hours, with duration scaling mainly on database count and plan cache size.

The load profile is deliberately light: read-only queries run one at a time with a per-query timeout, CPU history comes from already-recorded data, and the expensive collections (physical index stats, volume stats) are off by default and capped when enabled.

Still not comfortable?

Fair enough — that instinct is what keeps production safe. Book a 15-minute scoping call and ask him directly, or email the script questions to jason@sqlinsightsolutions.com.au before you buy.

Book an AIDA Diagnostic — $495