MKhub / sql server health check guide
A useful SQL Server health check does not end with a generic score or a pile of screenshots. It should tell the team where the real operational risk sits, which problems are already visible, and what needs attention first.
Use it when the environment is old, undocumented, recently inherited, or about to change and nobody wants to discover the real risks during the maintenance window. If the main pain is already active drift and alert quality, keep the SQL Server monitoring guide nearby.
Related
Use SQL Server consulting when the team needs a practical estate review instead of another export from the monitoring tool. Pair this guide with the SQL Server monitoring guide for signal quality, the SQL Server hardening guide for exposure review, and the SQL Server recovery guide when restore confidence is the weak point.
In this guide
Use this when
1 / Purpose
Teams usually ask for a health check when something feels off but nobody has a clean summary of the risk. Maybe the server is old. Maybe performance is inconsistent. Maybe backups are running but nobody wants to bet the outage on them. Maybe the DBA who knew the estate left two years ago and the current owners inherited jobs, alerts, and settings they do not fully trust.
In that situation, a useful review is not a benchmark exercise and not a vague best-practice sermon. It should answer a narrower question: what in this estate is sane, what is brittle, what is misleading, and what would hurt first during pressure or change.
That is why health checks sit close to consulting work. The value is not only in listing settings. The value is in reading the estate as an operating system with business consequences. Some findings are immediate fixes. Others are assumptions the team needs to stop making.
2 / Scope first
Health checks go wrong when people jump straight into waits, indexes, or memory numbers without establishing what they are looking at. One standalone OLTP instance is different from a multi-instance shared host. One internal application with predictable usage is different from a vendor platform with opaque behavior and poor release discipline.
Before deciding what is wrong, get the estate map clear enough to explain workload shape, critical databases, business timing, recovery expectations, and change pressure. That framing matters because the same technical finding can have very different priority depending on whether the server runs month-end finance, internal reporting, or a customer-facing application.
| Review area | What to confirm | Why it matters |
|---|---|---|
| Business context | Critical systems, outage tolerance, recovery expectations, peak windows. | Priority depends on operational impact, not only on technical ugliness. |
| Estate shape | Instance count, host sharing, version spread, key dependencies, HA layout. | You need to know whether you are reviewing one box or a small ecosystem. |
| Ownership | Who owns SQL, who owns the app, who owns backups, who signs off changes. | Weak ownership is a common root cause behind repeated drift. |
| Recent pain | Incidents, change failures, slow periods, restore doubts, audit pressure. | Recent pain tells you where the estate has already started arguing back. |
3 / Core setup
Most unhealthy estates do not fail because one famous setting is missing. They fail because the configuration tells the story of an instance that was installed, made to work, and never fully brought under control. Memory caps are vague. Tempdb sizing is inherited from a different era. Autogrowth is technically enabled but operationally messy. MAXDOP and cost threshold are either untouched defaults or cargo-cult values copied from somewhere else.
Tempdb deserves separate attention because it amplifies other problems. Poor file layout, bad growth settings, and hidden space pressure rarely appear alone. They show up together with blocking, version-store growth, index work, spills, or maintenance jobs that run longer every month. A health check should not just note that tempdb exists. It should decide whether tempdb is a supporting layer the workload can lean on.
Configuration checkpoints
4 / Recovery proof
Backup history by itself is comforting and often misleading. A green backup job does not prove retention is usable, log chain handling is correct, off-host copies are available, or restore timing fits the business expectation. It only proves that one step of the story ran without shouting.
In review work, this is where false confidence shows up most often. Teams discover that restore tests are old, integrity checks are partial, one critical database sits outside the standard schedule, or recovery expectations were never translated into real timing and procedure. The estate may look protected until someone asks who would restore what, in what order, from which source, and how long the business would really wait.
| Checkpoint | Healthy answer | Risk signal |
|---|---|---|
| Backup coverage | Full, differential, and log strategy matches the recovery objective for each important database. | One generic schedule applied everywhere whether it fits or not. |
| Restore testing | Recent restores have been tested and timed on something close enough to reality. | The team assumes backups are valid because jobs are green. |
| Integrity proof | Backup validity and database integrity checks are both part of the operating routine. | Corruption or unusable media would only be discovered during the incident. |
| Runbook clarity | The restore order, dependencies, owners, and communication path are known. | Recovery depends on whoever happens to remember the last outage. |
5 / Pressure signals
Health checks should look at waits, blocking patterns, expensive queries, and broad resource pressure, but not as isolated trophies. The point is not to say "top wait is X" and move on. The point is to decide whether the system is broadly healthy with known workload shape, or whether contention and latency are exposing deeper design or operational debt.
Blocking chains, WRITELOG pressure, PAGEIOLATCH waits, memory grant issues, CX class waits, or recurring query regressions all mean something. What they mean depends on workload context, change history, and whether the behavior is normal for known peak periods. A review should separate recurring load truths from avoidable pain.
What to check
6 / Ongoing care
Plenty of SQL Server estates have maintenance in the narrow sense that jobs exist and things run at night. That does not mean the maintenance is good. Health-check work needs to decide whether index and statistics handling still match the workload, whether job schedules collide with business use, and whether maintenance cost has quietly become part of the performance problem.
Index review is also a fast way to see how the environment has evolved. Too many overlapping indexes, missing support for critical access paths, stale statistics behavior, or rebuild-heavy routines can reveal an estate that has been patched around for years without a coherent workload view.
| Area | Good sign | What usually shows drift |
|---|---|---|
| Indexing | Indexes reflect real access paths and write cost is understood. | Duplicate, overlapping, or obviously stale index choices accumulated over time. |
| Statistics | Stats updates are predictable enough for the workload and plan stability is watched. | Plan quality changes but nobody can explain when stats last mattered. |
| Integrity and maintenance jobs | Jobs complete consistently and their runtime still fits operational windows. | Jobs exist mostly as inherited tradition and are failing, overrunning, or skipped. |
| Maintenance strategy | The estate has a reasoned approach, not just one script bundle dropped everywhere. | Rebuild, reorganize, update stats, and cleanup are treated as one-size-fits-all. |
7 / Security posture
Health-check work should not pretend to be a full penetration test. What it can do very well is identify the obvious SQL Server posture problems that teams normalize over time: too-broad sysadmin use, shared service accounts, unclear linked server trust, old features left enabled, weak separation between admin and application access, and patch posture that has already become a security argument.
This matters because security weakness in SQL Server estates is often operational, not cinematic. It shows up as poor accountability, fragile secrets handling, overpowered automation, and production changes nobody can cleanly attribute. Those are also the same conditions that make incidents harder to contain.
Security sanity checks
8 / Resilience claims
Estates with failover capability are often described as resilient long before anyone proves the operating model. Health checks should review what the team believes about Always On, clustering, replicas, off-site recovery, and application failover behavior, then compare those beliefs with evidence.
This is where expensive surprises hide. Synchronous commit does not mean the application reconnects cleanly. Replica existence does not mean jobs, logins, alerting, and runbooks are ready. A DR design on paper does not mean the recovery sequence has ever been rehearsed under realistic time pressure.
| Assumption | What to verify | If it is false |
|---|---|---|
| Failover is ready | Recent failover tests, application behavior, job ownership, listener and dependency checks. | A real outage becomes a live rehearsal with extended downtime. |
| Replica data is enough | Data movement health, lag behavior, and whether the recovery point is acceptable. | The business discovers the resilience promise was overstated. |
| DR can be invoked quickly | Runbook clarity, access readiness, restore order, and who leads the event. | Recovery delays come from confusion, not only from technology. |
| HA reduces operational load | Monitoring, patching, failover drills, and support ownership across the topology. | The platform is more complex but not actually better controlled. |
9 / Operational reality
A lot of SQL Server risk is social in the boring enterprise sense. Nobody clearly owns patching. The application team assumes the infrastructure team owns backups. The infrastructure team assumes the DBA owns restores. Alerts exist, but they are routed to a mailbox nobody watches. Agent jobs were created by a former vendor and are still treated like sealed boxes.
These are not side issues. They are why technically survivable problems turn into long incidents. Any serious health check should note where the operating model is missing, not just where the server settings look weak.
Operational gap checklist
10 / Output
The output should be more useful than a red-amber-green summary. Teams need a short list of findings that are clearly prioritized, tied to evidence, and grouped by risk. That usually means separating immediate operational dangers from medium-term cleanup and from longer-term design work.
It should also be obvious which findings the current team can fix alone and which ones need deeper review, rehearsal, or outside support. If the estate has drifted for years, the biggest value is often not one magic correction. It is getting from vague discomfort to a defensible plan.
That is the point where consulting becomes practical. When the review has already shown weak restore readiness, confusing HA ownership, unstable blocking patterns, or config debt that crosses into workload design, the next step is not another generic audit. It is focused remediation and a second set of eyes on the order of work.
| Deliverable | What good looks like |
|---|---|
| Prioritized findings | The top risks are ranked by business impact and operational urgency, not by how easy they were to spot. |
| Evidence summary | Each finding points to the technical signals, configuration choices, or operational gaps behind it. |
| Action split | The team can see what should be fixed now, what should be scheduled, and what needs design review first. |
| Ownership | Every important next step has a likely owner instead of becoming another shared concern that nobody picks up. |
Next step
If the estate needs a real review with findings, priorities, and an actual follow-up path, start with SQL Server consulting.
Next useful reads: the SQL Server monitoring guide for signal quality, the SQL Server backup guide for restore confidence, and the SQL Server hardening guide for posture work.