SQL Server health check
Know where the risks are before they become incidents
A structured review of your SQL Server instances and databases, delivered as a prioritised report – what matters, why it matters and what to do about it. Not a technical dump.
Ask for a fixed-price assessment. We’ll give you a fixed price after a short conversation.
Scope
What the health check covers
Each instance and its databases are reviewed against the same checklist, so nothing depends on what happened to catch someone’s eye.
- Instance configurationMemory, parallelism, tempdb, trace flags and settings changed from their defaults.
- Database configurationRecovery models, compatibility levels, auto-shrink, auto-close and file growth settings.
- BackupsWhat is backed up, how often, where to, and whether anything is missing.
- RecoveryWhether the backup chain supports the recovery the business expects.
- Integrity checksWhen DBCC CHECKDB last completed successfully on each database.
- PerformanceWait statistics, the heaviest queries and signs of memory or I/O pressure.
- Indexes and statisticsMissing, duplicate and unused indexes, fragmentation where it matters, statistics age.
- Securitysysadmin membership, service accounts, authentication mode and orphaned users.
- StorageFree space, growth trends, log sizes and VLF counts.
- MemoryMax server memory against what the host and other services need.
- SQL Agent jobsFailing, disabled and overdue jobs, and who is told when they fail.
- MaintenanceWhether index, statistics and integrity maintenance runs, and whether it suits the workload.
- Version and patch statusCumulative update level and the end-of-support date for each version.
- High availabilityAvailability groups, failover clustering or log shipping, where used, and their current health.
- RisksSingle points of failure and anything that would make an incident worse.
The report
Prioritised findings, not a data dump
Every finding is graded and explained in business terms, with a recommended action. Technical detail sits in an appendix for whoever makes the changes.
| Priority | Finding | Why it matters | Recommended action |
|---|---|---|---|
| High | No transaction log backups for a database in FULL recovery | The log will keep growing until the disk fills, and point-in-time recovery is not possible | Schedule log backups to match the agreed RPO, then right-size the log file |
| High | DBCC CHECKDB has not completed on two databases for over 90 days | Corruption could go undetected and be copied into every backup kept since | Run checks now; schedule weekly checks and alert on failure |
| Medium | Max server memory left at the default | SQL Server can starve the operating system of memory, causing paging and erratic performance | Set a limit that leaves headroom for the OS and other services |
| Medium | Version is out of mainstream support; several cumulative updates behind | Known defects stay unfixed, and security updates will stop | Apply the latest cumulative update; plan the upgrade path |
| Low | Five indexes with no reads since the last restart but heavy writes | Every insert and update pays to maintain indexes nothing uses | Confirm over a full business cycle, then remove |
Findings shown are generic examples of the kind a health check produces. Your report reflects your own environment.
How it works
A fixed-price starting point
The health check is scoped and priced before it starts, based on the number of instances and databases. It is often the first piece of work we do with a new client, because it gives both of us an accurate picture of the environment.
- We agree the servers in scope and how we’ll connect.
- We collect configuration and performance data, mostly from read-only system views.
- We review the findings, grade them and write the report.
- We walk you through it, and you decide what to do next – your team, us, or a mixture.
Questions
Health check questions
Will the health check affect our live systems?
Data collection relies mainly on system views and metadata that SQL Server already maintains, which have little effect on a running server. Anything heavier, such as an integrity check, is agreed with you and scheduled outside busy periods.
Do you fix the problems you find?
Only if you want us to. The report is written so that your own team can act on it. Many clients ask us to make the high-priority changes and then keep an eye on things afterwards.
What access do you need?
Remote access to each instance with enough permission to read server state and configuration, arranged through whatever secure route your IT team prefers. We confirm exact requirements when agreeing the scope.
Next step
Want to know where the risks are?
Tell us roughly how many instances and databases you run and what depends on them.