SQL Server Health Check
SQL Server evidence without the scavenger hunt.
A fixed-scope, SQL-queryable assessment of configuration, workload, maintenance, backup history, security settings, and resource pressure. No cross-department evidence chase. No claims that cannot be backed by collected SQL Server data.
Assessment boundary
- Read-only SQL Server collection scripts
- DMVs, catalog views, msdb history, Query Store, Agent metadata, and server configuration
- Only SQL Server-queryable evidence is included
- Findings are tied back to collected outputs
Why teams book the review
Small SQL Server settings can become large production symptoms.
A database problem rarely announces itself as a single clean failure. More often, a small technical condition starts a chain reaction. Auto-update statistics may be disabled, ineffective, or unable to keep up with data change. The optimiser starts working from stale estimates. A query chooses a poor join strategy. Memory grants become inaccurate. Sorts and hashes spill to TempDB. IO waits increase. CPU rises. Queries hold resources for longer. Blocking becomes more visible. Users report slow screens, reports miss their window, and job failures start to look unrelated.
That is the point where teams lose time: not because nobody is trying, but because the symptoms are arriving faster than the root cause can be isolated. The DatAIbase SQL Server Health Check is designed to collect the SQL Server evidence first, separate confirmed findings from noise, and show which issues deserve attention before the next release, migration, seasonal peak, or hardware decision.
The scope is deliberately practical: if it cannot be queried from SQL Server or its own history tables, it does not appear as a confirmed Health Check finding.
Buying triggers
Use the Health Check when SQL Server symptoms are consuming time but the evidence is scattered.
The review is most useful when the team can see pressure building and needs a defensible view of what SQL Server itself is showing.
Performance drift
Queries are slower than they used to be, nightly jobs take longer, TempDB is busier, or the same workload now needs more CPU, reads, or elapsed time to complete.
Configuration uncertainty
Key instance and database settings have accumulated over time and nobody is fully confident which ones are defaults, deliberate choices, or old workarounds.
Change is approaching
A seasonal peak, migration, compatibility-level change, hardware refresh, cloud move, or major release is coming and the SQL Server baseline has not been reviewed recently.
Maintenance is noisy
Agent jobs fail intermittently, maintenance windows are tight, index and statistics routines are unclear, or CHECKDB and backup jobs need a proper evidence review.
DBA capacity is stretched
The internal team is busy, review work keeps getting deferred, and SQL Server configuration or workload evidence needs an external pair of eyes.
Leadership needs facts
IT leaders need evidence before approving remediation work, accepting risk, delaying an upgrade, or deciding whether the estate needs deeper attention.
SQL-queryable assessment scope
The review only includes evidence that can be collected from SQL Server.
This keeps the engagement controlled. DatAIbase does not need to chase other departments or external process evidence to produce the core Health Check report.
1. Version, edition, and patch level
SQL Server version, edition, build number, support exposure, database compatibility levels, and upgrade indicators available from the SQL Server estate.
2. Instance configuration
Memory settings, MAXDOP, cost threshold for parallelism, backup compression default, optimize for ad hoc workloads, instant file initialisation indicator, TempDB layout, and trace flags.
3. Database settings and file layout
Database options, recovery model, page verification, auto close/shrink, compatibility level, file sizes, autogrowth, log configuration, and settings that affect supportability.
4. Backup history and backup configuration
Full, differential, and log backup history from msdb, backup age, backup type coverage, backup size, compression, CHECKSUM usage where recorded, and obvious backup-chain concerns.
5. Integrity evidence
DBCC CHECKDB job history where logged, suspect pages, page verification settings, corruption-related SQL Server evidence, and failed integrity-maintenance jobs.
6. SQL Agent and maintenance jobs
Job definitions, job ownership, recent failures, long-running jobs, schedules, disabled jobs, maintenance routines, and recurring SQL Agent error patterns.
7. Query Store and workload evidence
Query Store state, capture settings, regressed queries, high-resource queries, forced plans, failed forced plans, runtime patterns, and plan-cache evidence where available.
8. Waits, blocking, and resource pressure
Wait statistics, blocking evidence, deadlock history where available, TempDB pressure, memory grants, spills, IO indicators, CPU pressure, and workload hotspots.
9. Indexes and statistics
Missing, duplicate, unused, and overlapping indexes; statistics update behaviour; stale statistics indicators; large tables with weak supporting indexes; and index maintenance side effects.
10. Security configuration
Sysadmin membership, SQL logins, disabled or orphaned users where detectable, database ownership, TRUSTWORTHY, xp_cmdshell, CLR, linked servers, and privileged access indicators.
11. High availability metadata
Availability Group, clustering, mirroring, and log shipping metadata where configured, including synchronisation state and SQL Server-visible health indicators.
12. SQL Server alerting primitives
SQL Agent Alerts, operators, Database Mail configuration indicators, job notifications, and SQL Server-native alerting setup.
Delivery process
Read-only collection, evidence review, and a findings walkthrough.
The engagement is designed to avoid slow information chasing. DatAIbase provides the collection approach, the customer runs or approves the SQL Server evidence capture, and the report is produced from those outputs.
How the review runs
- Discovery call: confirm the SQL Server scope and any access constraints.
- Collection pack: provide read-only scripts and explain what each output is used for.
- Evidence review: analyse SQL Server configuration, msdb history, jobs, Query Store, waits, indexes, statistics, and security metadata.
- Report production: group findings by severity, evidence, likely consequence, and recommended action.
- Walkthrough call: review findings and agree which actions should be considered first.
Report output
The report should make clear what was found, what evidence supports it, and what to do next.
Every finding should be traceable to collected SQL Server evidence. If a subject cannot be supported from the collection, it is excluded from the confirmed findings rather than padded with conjecture.
Executive summary
- Overall SQL Server evidence summary
- Critical and high-priority technical findings
- Plain-English explanation of likely operational consequence
- Recommended first actions
- Items suitable for deeper review or follow-up work
Severity model
- Critical: credible SQL Server evidence of severe performance, availability, integrity, or backup-chain risk
- High: important issue that should be scheduled soon
- Medium: meaningful improvement or risk reduction
- Low: hygiene, housekeeping, or future review
- Informational: context, observation, or useful baseline
Technical findings
- Evidence observed
- Why the finding is relevant
- Likely operational consequence
- Recommended remediation
- Risk, effort, and dependency notes
Remediation sequence
- Quick wins
- Actions requiring change control
- Items needing application-owner review
- Work suitable for DatAIbase follow-up support
- Suggested repeat-review cadence
Package shape
Make the first engagement easy to understand and easy to approve.
The Health Check is a fixed-scope productised service with clear deliverables and a clear evidence boundary.
Entry point
Essential Health Check
Best for one important SQL Server instance or a small estate where the team needs a fast view of configuration, backup history, maintenance, and workload indicators.
- Focused SQL Server collection
- Severity-ranked findings
- Written report
- Findings walkthrough
Recommended
Comprehensive Health Check
Best when configuration, workload evidence, Query Store, jobs, security metadata, and resource pressure all need review before a peak period, migration, or major change.
- Full SQL-queryable assessment
- Workload and Query Store review
- SQL Agent and maintenance review
- Prioritised remediation sequence
Estate option
Estate Sample Review
Best for larger estates where representative SQL Server instances can be assessed first to expose common patterns, version exposure, configuration drift, and repeatable remediation themes.
- Representative server sample
- Estate-level technical themes
- Pattern-based recommendations
- Next-scope planning
FAQ
Questions buyers usually need answered before booking.
Do you need direct access to production?
Not necessarily. The preferred starting point is read-only evidence collection. The customer can run the scripts and provide the outputs if direct access is not appropriate.
Will the Health Check change anything?
No. The Health Check is an assessment. It should collect evidence and produce recommendations. Any remediation is scoped separately.
What data is needed?
Typical inputs are SQL Server metadata and history collected from read-only scripts: configuration, database settings, msdb backup and job history, Query Store where available, waits, indexes, statistics, security metadata, and SQL Server error/alert indicators.
Is this only for systems already in trouble?
No. It is often useful before a peak trading period, migration, compatibility-level change, infrastructure change, application release, or support handover.
Do you fix the issues afterwards?
The report separates findings from remediation. Follow-on work can be scoped separately for fixes, validation, documentation, training, or Fractional DBA support.
What makes this different from a generic checklist?
The Health Check is built around evidence and consequence: what SQL Server shows, why it deserves attention, and which action should be considered first.