A real SQL Server health check is a senior DBA running 80+ targeted diagnostic checks against your live environment — not a stored-procedure dump or a tool report. The output is a prioritized action list, not a 200-page PDF. Here's exactly what's inside.
Search "SQL Server health check" and you'll mostly find one of two things: free scripts that dump 200 pages of DMV output, or vendor reports that grade your server on a 1-to-10 scale with no actionable detail. Neither one fixes a slow database.
A real health check is an experienced DBA looking at your specific environment, in context, and telling you in plain language what's wrong, how bad it is, and what to do about it. After two decades of running these for production environments, here's the framework I work through — organized by area, with the specific checks that matter most.
1. Performance Baseline (the foundation)
Before diagnosing anything, you need a baseline. Without one, "the server is slow" is unfalsifiable.
- Wait statistics analysis — top waits by category over the last 7 days, normalized to wait-time-per-batch-request, with comparison against Microsoft's published baselines
- CPU pressure indicators — signal wait ratio, runnable task count, parallelism waits
- Memory pressure — Page Life Expectancy (PLE) per NUMA node, buffer cache hit ratio in context, memory grants pending
- I/O subsystem latency — stalled I/O per data file, average read/write latency, and I/O distribution across files
- tempdb contention — PFS/GAM/SGAM latch wait analysis and file count verification
What a tool report misses
A script can tell you PLE is 312. A senior DBA tells you that PLE is 312 on a NUMA node hosting your highest-query-volume database, and that the storage stats show your hot data isn't actually in cache because of a misconfigured Resource Governor pool. That's the difference.
2. Query Performance Analysis
Performance problems live in queries. Every health check should surface and rank them.
- Top 25 queries by CPU, duration, logical reads, and physical reads — separately, because the same query rarely tops more than one list
- Execution plan review — looking for scans on large tables, hash spills, missing seeks, implicit conversions, parameter sniffing victims, and bookmark lookups
- Plan cache health — single-use plan bloat, ad-hoc query saturation, forced plans vs. natural plans
- Statistics freshness — auto-update thresholds vs. table growth, asynchronous update behavior, statistics histograms vs. actual distribution
- Query Store analysis if enabled — regressed queries, high-variance queries, top resource consumers over time
In most environments, 80% of CPU is consumed by fewer than 20 queries. Identifying those 20 — and ranking them by how much business value they support — is where a health check earns its fee.
3. Indexing Strategy
Bad indexing causes more performance complaints than bad code does. The check covers both sides of the problem: too few and too many.
- Missing index analysis — with critical context: Microsoft's suggestions are a starting point, not the answer. We evaluate them against actual usage and existing covering options.
- Unused indexes — indexes that have been written to but never read since the last restart (or per Query Store history)
- Duplicate & overlapping indexes — these silently inflate write cost
- Fill factor per index, against actual fragmentation patterns
- Heap analysis — large tables without clustered indexes are red flags 95% of the time
- Foreign key indexing — missing indexes on FK columns are a common cause of cascade delete locks
4. Configuration Review
SQL Server has hundreds of knobs. Most are set wrong because they were set once in 2014 and never revisited.
- Memory configuration — min/max server memory in context of total RAM, NUMA settings, and column-store memory pools
- MAXDOP & cost threshold for parallelism — verified against actual workload patterns, not "the default that ships in the wizard"
- tempdb file count, sizing, autogrowth, and instant file initialization
- Power plan at the OS level (still set to "Balanced" everywhere, somehow)
- Lock pages in memory, IFI, and the service account's local security policy
- Database-level settings — recovery model vs. backup cadence, query store size, parameterization mode, isolation level, auto-shrink (please no)
- Trace flags in use — deprecated ones still enabled, recommended ones missing
5. Security Posture
Security is part of the health check because security failures look like outages — and because every SOC 2, HIPAA, PCI-DSS, and DoD STIG audit asks the same questions.
- Service account privileges — still running as LocalSystem? Domain Admin?
- SQL logins, AD groups, and orphaned users
- sysadmin role membership with a justification check
- Encryption posture — TDE on databases with regulated data, TLS for connections, backup encryption
- Auditing — SQL Audit specifications in place for the events auditors actually look at
- Patch level vs. CVE exposure — cumulative update lag against published security bulletins
- Public schema permissions — the silent path to data exfiltration
6. High Availability & Disaster Recovery
If you have HA/DR, it gets tested. If you don't, the recommendation is part of the report.
- Backup verification — not just "backups are happening," but RPO/RTO modeled against actual database growth and last-restored timestamps
- Always On Availability Groups — health detection, automatic failover thresholds, listener configuration, read-only routing, sync vs. async commit behavior under load
- Cluster quorum and witness configuration
- Log shipping latency and orphaned restore jobs
- Replication health — distribution database size, latency, agent stability
- Last successful restore test — because a backup you've never restored isn't really a backup
7. SQL Agent & Operational Hygiene
- Job failure history with root-cause categorization
- Long-running jobs that quietly broke their SLA
- Database mail and operator wiring — alerts that don't actually page anyone
- Severity 16+ alert coverage
- Maintenance plans vs. modern alternatives (Ola Hallengren's solution is usually the right answer)
What you get back
The deliverable from a real health check is not a 200-page PDF. It's three things:
- An executive summary — one page, business language, what's at risk and what it costs you
- A prioritized action report — every finding categorized P0 / P1 / P2, with effort estimates and expected impact
- A walk-through call with you and your team, where I explain the findings in plain language and answer questions
Yes, I use scripts — sp_WhoIsActive, sp_BlitzFirst, custom DMV queries, Query Store extracts. But scripts are inputs to a senior DBA's judgment, not a substitute for it. A health check is the analysis, not the dump.
How long it takes
A standard SQL Server health check on a single instance runs about 5–10 business days from kickoff to walk-through. Larger environments (multi-instance, AGs, replication topologies) take longer. The discovery call is free; the engagement starts after we've agreed on scope.
Ready to know what's actually in your SQL Server environment? Book a free 20-minute discovery call below and we'll talk through your environment, your pain points, and whether a health check is the right next step.