We inherit a lot of SQL Server environments. And a thing that happens more often than I’d like is that we find a completed SQL Server health check sitting in the environment already. A pretty darn good one, too. The findings are right, the recommendations make sense, and a lot of the time we know the person who wrote it, because it’s a small tech community and we respect the folks doing this work.
Then we look at the date on the report. It’s a year old. And then we look at the environment and not one of the important recommendations has been done. For more than a few of these times, none of them have been done.
And sometimes it could even be our own report from long ago…
That’s the uncomfortable part, and it’s the reason I wanted to write this, life is too short to not be transparent and think about how to solve these things at the same time. If you’re thinking about paying anybody for a SQL Server health check or health assessment or whatever your favorite name for it is (and that includes paying us), the report is not actually the thing you should be evaluating. What happens after the report is the thing.
The short version: health check findings don’t get implemented because a finding without an owner, a date, and a follow-up is just documentation. The report usually didn’t fail. What happened after the report failed, and some of that is on the consultant who wrote it when we don’t make sure you’re ready to go, know what to do, why you should do it, and how to communicate it and verify it.
Why don’t SQL Server health check findings get implemented?
The interesting thing is that this is almost never a knowledge problem. When we come in, the client usually remembers the assessment. They’ll say “oh yeah, we had one of those done, here’s the report if you want it.” Some of them go a step further and ask us to help implement the findings somebody else gave them and provide us the reports and documents and say “here – help us do this stuff….”
So they knew. They were told exactly what needed to change. And a year later nothing changed. There are four reasons we see this over and over, and the last one is the one us consultants don’t like talking about.
Is a recommendation the same thing as an implementation plan?
No, and this is the biggest one.
“You should test your restores.” Great. No duh…. But now go be the person who has to do that, and look at the questions that recommendation leaves sitting on your desk.
| The recommendation says | The person doing it still has to answer |
|---|---|
| Test your restores | Which systems, and in what order? |
| Restore to where? What server, what storage, whose budget? | |
| Who does it, and is it in their job description? | |
| How often, and when does the first one happen? | |
| How do we know the restore was actually good? Do we run CHECKDB against it? Do we do an app test? Is the CheckDB good enough? How do we know? | |
| What do we do with the restored copy afterward? | |
| Does this need a maintenance window? | |
| What happens if the test fails, and who gets told? |
The recommendation can be technically perfect and still die right there, because nobody answered the questions that nag the person who has to own it (and their leadership team and change control boards.) And so it becomes one more line on a report that gets filed on a shelf somewhere (you can see a little bit of my messy bookshelf behind me in the video, so I’m not throwing stones – though I keep the really messy shelves off camera.)
A finding without an owner and without a date and without a task is documentation. It is not a plan.
Why do critical findings keep getting pushed to next month?
Because normal life happens, and normal life is relentless.
A performance problem shows up and it takes priority, and honestly it’s funner to work on for most of us DBA types. Somebody needs a report by Thursday. Disk space gets tight. There’s a deployment. Six meetings get scheduled in the same hour and you have to pick at least 3 of them to kind of attend. And the critical recommendation from the assessment becomes “we’ll get to that next month,” and then next quarter, and you already know how that story ends because we’ve all lived it.
We wrote about this in our post on the perils of being a solo DBA, and it’s the same problem. As a company who uses EOS, this falls in the “Capacity” category not the Gets it or Wants it category (IYKYK).
Are DBA Consultants explaining findings in a way the business can act on?
Often, no, and this one is on us as a profession.
We walk into a room and tell an IT Director that MaxDOP is wrong, or the recovery model doesn’t line up with what Veeam is actually doing, or there’s a security configuration problem. All true. All meaningless to somebody who is already holding a list of 47 things from one sysadmin, plus everything coming down from above, plus what clients are pushing in, plus whatever the SOC 2 people asked for this week (we’re nearing the end of our first SOC2 audit – and a question from the auditor takes priority, I get it now!)
If we don’t describe the business impact and answer their questions, it doesn’t get prioritized, and if it doesn’t get prioritized it doesn’t get done.
| What we tend to say | What the person deciding actually needs |
|---|---|
| Your recovery model is wrong | If we lose this server at 2pm, here’s how much data is gone and here’s what that costs |
| You have no CHECKDB job | We can’t currently tell you whether your data is already corrupt, and backups of corrupt data don’t help. I don’t even want us to go to sleep this weekend until we do a checkdb and pray about the results and see them… |
| MaxDOP is misconfigured | Queries are competing for CPU, here’s the report that runs slow because of it |
| Security configuration issue | Here’s who can currently do what, and here’s how that reads to an auditor |
The frame that works is pretty simple. Here’s what can happen to the business if we don’t do this. Here’s how likely we think that is. Here’s what it takes to fix, in money and time and downtime and reboots. Here’s the risk of making the change, and here’s the risk of doing nothing. And here’s what I’d fix first and why.
Are consultants part of the problem?
Yes, at least partly, and this is the part I don’t think we talk about enough.
If I hand you a brilliant report with 70 findings, take your check, wish you luck, and come back a year later to find you did none of it, I have to at least ask myself whether I actually helped you. Why are all of these still here?
Did I explain it well enough? Did I make the priorities obvious? Did I describe the risk in language your business could use? Did I give you an achievable first step, and did I help you pick the right first thing and then the second thing? Did we establish an owner? Did I follow up with you at all? Was I there to answer questions and encourage you? Did I offer to help you make the changes?
Yes, I took your money and I delivered the report and legally the contract was met if you just bought a health check only (We do sell a SQL Server health check for $997 and we go deep enough with it, but we prefer to sell a bucket of 20 hours, do the health check in the first bunch of hours and have time left over to help actually implement the changes and maybe even follow up a few times if you like.) But why did I deliver it, and why did you pay for it? Was it because you wanted a nice looking PDF, or was it because you wanted to know what was bad and how to fix it?
There’s one more question in there too, which is whether my recommendations were even realistic in your environment. There are two kinds of best practices out there. There are the ones that are right for you and your environment, and there are the ones that are right in a textbook somewhere. Sure, disable the sa account. But if you’re running a vendor app that flat out will not work any other way, is that recommendation helping you, or should we have gotten on a call with your vendor instead?
None of that means the consultant owns your decisions. We can’t. You and your business have to own the decision and you have to act. But we see this enough that it’s good to think through.
What should a SQL Server health assessment actually give you?
These days I care a lot less about handing somebody a big list. A big list is easy. You can get your own big list with all of our free community SP_Check tools – especially now that we’ve released sp_CheckHealth that we use internally to drive a lot of our health checks. You can find the latest free app or vibe coded tool and see what’s not ideal today. What you actually need to walk away knowing is where you’re going to get hurt, what has to be fixed first, what can wait, and who needs to be in the room for each decision. And understand which to apply when and which to hold off on because the ingredients aren’t right for it for you.
Every finding should carry six things:
| Component | The question it answers | What happens when it’s missing |
|---|---|---|
| Finding | What is it? | Nothing to act on |
| Explanation | Why does it matter, and how does it actually work? | It gets ignored or argued with |
| Priority | What do I fix first, and what can wait? | Everything looks equally urgent, so nothing moves |
| Owner | Who is doing this? | It stays everyone’s job, which means nobody’s |
| Date | When? | It slides to next month, forever |
| Follow-up | Who notices in six months if it didn’t happen? | You buy the same assessment again in two years |
If the last three are missing, none of us should act surprised when the same findings show up again.
And the practical detail matters just as much as the finding. If we tell you to reformat a drive to a 64K allocation unit and we don’t also say “please don’t do that tomorrow afternoon on the production box with live databases on it,” that’s a failure of the report, not a failure of the reader. What needs downtime, what doesn’t, what’s going to blow away your plan cache and give you an ugly twenty minutes, what’s going to take you offline until you restore if you don’t do the right steps? That belongs in the deliverable so you can work with the approval process and get the stuff approved. That’s why we prefer to stick around and get our hands dirty with the bucket of 20 hours. For the same price as some health assessments, we’ll do the assessment, stretch our hours and make the changes with you, teaching as we go billing in 15-minute increments. We like to see you pay for the findings – and walk away healthy. We can spend the next bucket of hours or do DBA as a Service with you on the funner “next” stuff.
Who owns fixing what a health check finds?
Somebody has to, and it’s worth being clear-eyed about who before you buy anything.
| Task | A health assessment | Ongoing DBA ownership |
|---|---|---|
| Tells you where you’re exposed | Yes | Yes |
| Prioritizes it for you | Should | Yes |
| Does the work | No | Yes |
| Notices in six months | No | Yes |
| Good fit when | You have someone to act on it, you understand the priority and info, the health assessment helps you walk away with a plan and you have confidence in making the changes | You don’t have that someone – or they’re stretched too thin. |
A health check can tell you where you’re exposed. Someone still has to do the work to un-expose you. Sometimes that’s your internal DBA. Sometimes it’s the person on the team who can spell SQL because you don’t have a DBA. Sometimes it’s a consultant, and sometimes it’s a DBA as a Service team working alongside you. Any of those can work. But the “hope it gets fixed and someday we may” approach won’t work most of the time.
What should you ask before you buy a health check from anyone?
This is the part I’d genuinely like you to take with you, whether you buy from us, from one of our friends in the community, or you download a free community tool (our or anyone’s) and run your own.
Don’t just ask what’s in the report. Ask what happens after it.
| Ask this | A good answer sounds like | A bad answer sounds like |
|---|---|---|
| What happens after you hand me the report? | We walk it through with your team and agree on the first three things | We’ll send it over and you can reach out with questions |
| Who helps me prioritize this? | We do, in your context, with your constraints | It’s ranked high/medium/low in the document |
| Who owns the next steps? | We’ll name an owner for each finding with you and can answer questions about who typically owns it | That’s on your side |
| Will you teach us, or just tell us? | We’ll show your team why, so you can maintain it, we can even help you on the implementation nights | Here’s the fix |
| Who notices in six months if none of it happened? | We follow up | (silence) |
| Are these recommendations realistic in my environment? | We’ll flag which ones your vendor or app constrains | These are industry best practices |
If you’re doing it yourself with a free tool, the questions don’t change, they just become an internal conversation. Somebody on your side has to own accountability, or you’ve generated a very accurate list of things that will still be true next year. If you want help with your SQL Server health check, for $997, we can help.
Because at the end of the day, the best assessment in the world doesn’t reduce one single bit of risk if it’s stuck in a PDF.