Our pricing for our Remote DBA service is deliberately pretty simple: one quarterly price, one pool of DBA hours, and a set of services that come with the relationship whether you use every hour or not.

The number itself is the easy part and that doesn’t take a lot of time on calls with potential customers to sort through, but what people usually want to understand is what that number actually buys, what uses their hours, what doesn’t, and what happens when their needs change.

So I’ll try and answer most of those questions here. I don’t mind answering them in the calls also, but I like solutioning and sorting out relationship fit and figuring out the specific challenges on the calls and if we can answer a few questions ahead of time with some posts and videos, that’s more time to talk about the unique challenges.

I talk a bit more about the philosophy (and my extreme dislike for “contact us for pricing details” on a website in the above video.

This post is Part of our Buying DBA Services series: We’re sharing what we’ve learned from inside the managed DBA business over the years to help you understand the costs, tradeoffs, problems, and questions to ask before choosing a provider. The goal is to help you make the right decision, whether that means hiring Straight Path, another DBA company, an internal DBA, or nobody at all.

How much does Straight Path’s DBA as a Service cost?

It’s on the DBA as a Service page but as of today:

• Micro: $6,000/quarter for 10 hours, overage hours are $295/hr.
• Silver: $10,000/quarter for 25 hours, overage hours are $275/hr.
• Gold: $14,000/quarter for 45 hours, overage hours are $265/hr.
• Diamond: $19,000/quarter for 75 hours, overage hours are $250/hr.

Gold and Diamond let you roll forward hours, all levels get the same monitoring and full team relationship, all have access to us after hours. Silver and up start with a Senior DBA owning the relationship, Micros are owned by the amazing DBAs on our support team. But the full team serves all clients – we don’t gatekeep you from the right resource based on your level. More details are on the pricing page.

Why do you charge quarterly instead of monthly?

We actually started pricing monthly way back when – but a few things hit:

1. More overhead – it was a LOT more to track and send invoices.
2. We made more money from overage from clients in some months while other months had hours left over – a lot can change month to month.
3. We wanted more stability in the billing for our client and a bit more time to be proactive.

Monthly is too much churn and too hard to predict. Quarterly can be difficult for some clients but it tends to be the right cycle for natural ebbs and flows in a relationship and normalizes over the 3 months. Some clients wind up on semi-annual and annual plans and for many clients that works well – for some it’s a bit too far out to predict if they don’t have a great annual forecast of work and are going through changes.

Why don’t you price DBA as a Service by the number of SQL Server instances?

Instance count just doesn’t really equate to workload. The age old SQL Server DBA answer to every question is “It depends” – and that really applies to a question like “how busy is one instance?” We have a few clients with a single SQL Server instance who are easily Diamonds forever because of all the important work, help with tuning and SQL Dev work they need, and some that have scores of instances with or without a DBA that can get by on Silver or even Micro. We charge by hours and we let folks change levels quarter by quarter based on needs. This really has worked well.

What is included in the quarterly price?

• Monitoring of their entire estate – daily health checks, alerts as they happen that are watched by our triage team M-F 8AM to 5PM no charges for the tools to be there or the daily health review summary our team looks at and sends or the alert triage. We bill when we get connected.
• A single instance of SQL sentry monitored (more available at our discount – priced with a really steep discount – we aren’t a software reseller – we’re just passing on a discount we get for buying in bulk)
• A staffed on-call team and escalations.
• A lead DBA and access to some of the best of the best DBAs (and access to CDO services, Azure architecture and more with Buck on the team)

What actually uses my included DBA hours?

Whatever you need. I guess you could simply just say, work. We sometimes get calls asking “what about if it’s emergency work? what if it’s proactive? Is it different for reactive? What if it’s reactive but it’s a Tuesday? What if it’s after hours patching work? What if it’s project work vs fix it work?

We don’t play that game here. For two reasons. One because it’s confusing as heck for the customers and a strange service model. The other? Because I don’t want to have to track all of that. If we’re connecting and doing work or talking to you about things or in a meeting – we’re billing in 15 minute increments.

After hours work is still billed in 15-minute increments, but we start the clock at an hour then go to 15 minute increments. So theoretically, if something after hours only took 45 minutes, an hour is deducted from the retainer – but I can’t think of many after hours things that are 30 minute things by the time you get connected, load the ticket, confirm the plan, test the work, etc.

Why does Micro have a higher effective hourly rate than Silver, Gold, or Diamond?

There is a fixed cost to ever DBA as a Service relationship. We don’t do a “monitoring only” plan – but if we did we’d see a bit more normalization between the levels. The things like the monitoring infrastructure and support and dev team and security, our own security and audit compliance, the back office, the team reviewing the alerts and doing the daily health checks that aren’t billing clients for hours. We’re paying for the team to be on-call whether they get a call or not. Mentoring and training. All of these costs are baked into what we do as a company but the fixed client service costs like the alerting and tooling – that has a bit less room to “hide” when a plan like Micro has 10 hours per quarter.

What happens if I don’t use all of my hours?

For the Micro and Silver tiers – we don’t have rollover, but we also don’t like a client losing hours. These plans are really “up to” plans but we do our best to use all of the hours. We have monthly check-in calls and report the hours, we review things, we have a heavy focus on proactive support and catching things before they go bad – and we escalate and keep calling if we aren’t getting feedback. We want to be the most valuable partner that each of our clients work with – and we pride ourselves on winning the best in service award from Clearly Rated, the folks who do our independent surveys. We love it when a client tells us that we’re a partner, not a vendor. We do our best to use the hours.

For Gold and Diamond we have rollover available 10 and 25 hours respectively.

And when a client consistently uses less hours – our leads suggest a downgrade if there are no plans to use them in the future.

What happens if I use more hours than my plan includes?

Every client can purchase overage. We never assume overage either. When a client gets close on hours, their lead DBA sends them a note saying they are burning at a higher rate than their level is at and we ask for which stance they’d like us to take. Allow us to consume up to some number of hours overage at the overage rate (we don’t bill it then – we just get a limit and approval and then bill only what’s used at the end of the quarter.), save some for emergencies, allow only emergency overage, or hold work at the level.

Each level has different overage rates as described above and on the pricing page.

The overage rates are a lot less expensive than the Bucket of Hours rates. This isn’t to punish a bucket of hours client, but it’s to optimize for the relationship – and with an existing DBA as a Service client, we’re often able to better plan and predict and even head off some of the work because we’re really part of their team. I think of it as our clients on DBA as a Service are in some sort of a membership with us. (That said when a bucket of hours gets usage up high – we’ll often offer price breaks and relationship breaks.)

We also will look at an emergency or faster than planned usage as a way to really optimize for the relationship. We try and be creative when it makes sense and let a client upgrade their next quarter and steal ahead (we make a bit less for the overage – but we haven’t profited off of a big emergency – leaving overage for the 10-20 hours above and beyond that happen from time to time not a true increase in workload where the next level just makes sense.)

Why don’t you charge different rates for projects, emergencies, performance tuning, upgrades, patching, and other types of DBA work?

I don’t want a client wondering “shoot which SKU of work is this before I call?!” I want them thinking of us as their partner, in it for them – with them – and if it’s work – it’s just being billed in 15 minute increments. Back when I was on the ambulance as a volunteer – I loved patient care and figuring stuff out and stabilizing a crisis – I really, hated the paperwork. Imagine all of the paperwork and work we’d have to do to have a million different rates based on a flow chart of ideas. Nah… If we’re working with you – we’re billing the retainer in 15 minute increments. Case closed.

(That said after hours support calls are assessed a $500 fee – one and two calls are waived a year for Gold and Diamond) We pride ourselves on getting few calls – the fee is at the right level to be worth it for an emergency, but a bit too high for a “stubbed toe” – the reason we don’t get the calls isn’t the fee – it’s our proactive stance – we like to setup an environment for success ahead of time and focus so hard on prevention.

Can I just buy a bucket of consulting hours instead?

Absolutely.

Buckets of hors list today for $7,000 for 20 hours and we just moved the pricing to $12,000 if a client buys 40 hours at a time. The hours are good until they are exhausted or for a year, whichever comes first. We bill those in 15 minute increments also.

Buckets are great if you don’t want monitoring, if you don’t need alerting, if you don’t need a support team to call – we are getting fewer of our team members access and the work is planned work where we are helping with a defined project, some tuning, a health check and fixes afterwards.

The buckets of hours are NOT for support or break fix after hours or with the 15-minute P1 response (though we still try and help where we can and when we can – the buckets are optimized for project work that is planned and no real DBA support.)

If you just need hours and not support and relationship – just buy the hours.

How do you decide which DBA as a Service level I should start with?

Normally on a call with a potential customer, right about now I’d wet my finger and put it up to the wind and say “it’s a bit of a guessing game.” And, yeah, I really do that far too much (with clean hands!!)

But we kind of “figure it out” on the call. We hear about the pain points, the size of the environment, the size of the team monitoring it, the answers to questions and we take all of the clients we’ve served who feel and look like you and we are able to narrow it down fairly accurately. Onboarding is taken out of those hours also so we talk about the onboarding process – more pain = more time to manage and setup accounts and PAM tools and MFAs and second and tertiary accounts.

But we also tend to optimize for a higher level for the first quarter and we just tell the client if you go with Gold or Diamond based on what it feels like – and we bit off to many hours we’ll give you a one time courtesy rollover – you can rollover all unused hours instead of the 10 or 25 to the next quarter – so we de-risk it and if the hours are used the way we expect (and, usually, they are) we saved them overage, made a little less margin and were able to really help.

But it’s an estimate- and we get it wrong sometimes and that’s why I love running a small company where I’m the sales guy, customer experience officer and founder – we figure it out and make it right. But we’ve been doing this for a long time and we get it right more often than not.

Are your DBAs incentivized to use all of my hours?

They are incentivized to serve you, make you feel protected and cared for, the NPS score of their customers in our annual review, and living to our values (Trust360, Generosity, Humility, Ownership mentality.) So they are incentivized to serve you. That means use the hours we have, not just go into overage because we can and try and blend proactive work to reactive needs and to your budget. If they think more hours are needed they’ll tell you – if the budget is there to go up a level we’ve saved you from overage and keep working, if the budget is a tier lower, we titrate to effect.

We like long-term client relationships and we have lower churn rates of team and customers and I want to keep it that way. We don’t want to bill for solving the same alarm over and over again, we don’t want to actually have you use on-call – and we want to make sure we get what needs to get done and we’ll tell you if your hours are too high or too low – but we’ll respect the budget. It’s absolutely an amazing sign of success when we see a client start at Diamond, move to Gold and then live at Silver because we’ve solved many of their challenges for real – it just means I have to have a few more sales calls when we do it, but so be it.

Can I move between service levels?

Absolutely – we need 30 days’ notice to move levels. We suggest down or upgrades based on what we see and we work with you to pick the right option.

Do I have to sign a long-term contract?

No. Heck no. We once had a client – someone I used to work with and wanted our service – need to wait some time before he could break a contract with another, bigger DBA as a Service client, or pay some exorbitant fee. That reminds me of a scene I hated when I had a summer job. I was working at a beach side store on the east coast – in my small town. And we made fried clams and the owner got after me once because I didn’t properly “fold the bottom of the box up” – basically we were instructed to squeeze the bottom of the box for each size where the boxes were made – it meant the bottom was now I don’t know 1 inch? half an inch higher? And at a point so this mean that maybe 2-3 less fried clams (or scallops or whatever) would fit in the box. I didn’t like it – and I asked what if the customers notice? He pointed to the beach and said “every single day we get how many new people here? and we’re the store here – where are they going to go? and I don’t need repeat business it’s new folks every year.”

A lot of our values and approach to business are informed by crap I’ve had to deal with or don’t like at places. The long term contracts is 100% there as well. Stay because you like us, because we’ve earned your renewal. If we haven’t? Then we don’t deserve your business. We need 30 days’ notice to leave us, too. With no penalty (though you may have to suffer through a call with Evan, our COO, and I to learn lessons and make sure there’s nothing we can do to make it better.

What happens after hours?

We do planned work after hours all the time as described above with the hours. If it’s an emergency you call our on-call number. 888-SQL-DATA and press option 2 and you talk to our answering service who then calls our on-call DBA. They have 5 minutes to answer or they get called again. After the second 5 minutes they call the backup. After 5 minutes there they call Evan or I. The team doesn’t want Evan or I called – usually the backup never has to get called – and then our team member is on with you. Our SLA is to be on a call within 15 minutes of you calling and to be able to be online working with you within an hour at the worst (the team covers for each other and we often will have folks jump in even if not on-call – we all get an e-mail when the on-call number is first called – and Evan, Sheila, and I get a text and we all watch… We sometimes trip over each other to help – but I’d rather it be that way.)

What should I compare when I’m looking at another DBA provider’s price?

Don’t just compare the number.

Ask the questions above. Ask questions like:

• What is included in the base price?
• What consumes hours?
• What doesn’t consume hours?
• Is monitoring included?
• Who actually reviews the monitoring?
• What happens when an alert fires?
• What happens after hours?
• Are emergencies billed differently?
• Is project work billed differently?
• What happens if I don’t use everything?
• Can I change service levels?
• Who actually works on my SQL Servers?
• Who owns the relationship?
• What is explicitly NOT included?
• What happens if I decide to leave?

Evaluate the answers, see how you fit with them and pick the best fit for your needs out of a few providers.

Which Straight Path DBA as a Service level is right for me?

Micro

Micro clients are the one client with two major differences:

1. You have a Support Team DBA as your primary DBA.
2. You have to allow us to use a shared access methodology (which is secure, MFA, etc and we are happy to describe that on the call with you.)

Micro is great if you want the monitoring, the relationship, the ability to flex up. Maybe you have a small environment – and are growing and want someone there with you. Maybe you have a DBA team and want coverage. We’ve thought about renaming this service to Essentials – all of our tools – our full team – we keep the lights on but don’t have a ton of hours to go deep with the proactive.

Silver

You need between 15-25 hours a quarter and have enough complexity to need that Senior DBA relationship and you want us to have time to be proactive and keep ahead of things in your smaller environment.

Gold

This is 45 hours a quarter and has one on-call fee per year waived and rollover available. This is where we start getting to busier environments, a bit more going on and the hours are needed – we’re doing more tuning and performance work , helping do a lot of future proofing. You may or may not have a DBA team. We’ve thought about renaming this level to Professional one day and maybe finding some number of hours that would make Silver and Gold turn into it- The main difference to Silver is the hours but it’s not that huge of a leep -but it saves you $1,500 a quarter in overage if you need to go over.

Diamond

You need 75 or more hours a quarter, we’re doing a lot more work and there is more complexity. We’ve thought about renaming this to “Enterprise” one day. You’d get two on-call fees waived per year.

A bucket of hours

I talked about that above – but really you just need the work, don’t need or want the monitoring, the ongoing reviews and relationships and SLAs – but you’d love the expertise that comes from a team like ours.

The short version

Our DBA as a Service pricing is designed around the amount of DBA work and coverage you actually need, not simply the number of SQL Server instances you own or any other metrics that are really open to interpretation.

You pay one quarterly price. You get a pool of DBA hours plus the monitoring, tooling, coverage, and team infrastructure that comes with the service. We don’t have different rates for different tickets or access to the “good SLA”. It’s just a pool of hours for you to use how you need.

If you need more, we can use overage or move you up. If you consistently need less, we can move you down.

And if you don’t need an ongoing managed relationship at all, we’ll happily sell you a bucket of consulting hours instead.

The goal isn’t to put every company into the biggest DBA as a Service plan we can sell.

It’s to figure out what kind of DBA help you actually need and price the relationship accordingly and grow with you even if as the relationship grows the hours may drift down because of what we’ve accomplished. That’s success.

Still not sure which option fits?

That’s normal. We don’t expect you to diagnose your own DBA workload before talking to us. If you reach out, we’ll ask about your environment, your team, what keeps breaking, what’s coming up, and what you actually want help with. Sometimes we’ll recommend DBA as a Service. Sometimes we’ll recommend a bucket. And sometimes we’ll tell you that what you really need is to hire somebody. Book some time with me or reach out – we don’t have a sales team or sales process – we have a conversation and see if we’re right for each other.

The post How Much Does DBA as a Service Cost? What’s Included, What Uses Hours, and Why We Price It This Way appeared first on SQL Server Consulting - Straight Path Solutions.

We do this every day here at Straight Path using sp_CheckHealth, and we wanted to share it with you.

Here at Straight Path Solutions, we’re big fans of community tools like sp_WhoIsActive, Brent Ozar’s First Responder’s Kit, and Erik Darling’s suite of helpful stored procedures. As database administrators who are constantly looking at new clients and new servers, we wanted one tool we could run the moment we sit down in front of an unfamiliar instance to get the lay of the land and see what needs our attention first. Like many of you, we’ve been using sp_Blitz for years, but we wanted a tool that was more focused on administration-related issues. So, we wrote one.

You can download sp_CheckHealth now from our GitHub repository, along with several other helpful tools for SQL Server.

What does sp_CheckHealth do?

This tool will give you a fast, comprehensive picture of a SQL Server instance. It gathers the kind of information you would otherwise collect by clicking through a dozen dialogs and running a handful of scripts, and it flags potential issues so you can decide what to deal with first. The findings are organized into categories like Recoverability, Security, Availability, Integrity, Reliability, and Performance, and each one comes with details and an action step so you aren’t left guessing about what to do next.

This tool has several modes that present a different set of data, depending on what you want to examine.

• @Mode = 0: only the problematic issues we could find.
• @Mode = 1: instance information only, with one finding per row.
• @Mode = 11: instance information only, returned as a single row. This is handy if you want to collect the same facts from many instances and stack them together, especially if you have a Central Management Server that you can query.
• @Mode = 99: instance information and problematic issues together (the default).

How do I use it?

Execute the script to create sp_CheckHealth in the database of your choice.

Executing it without using parameters runs @Mode = 99 and returns a single result set that includes your instance information followed by any problematic findings, sorted so the most important items are at the top.

Although you can simply execute it as is, there are several optional parameters.

@Help – the default is 0, but setting this to 1 will return some helpful information about sp_CheckHealth and its usage in case you aren’t able to read this web page.

@Mode – see the previous few paragraphs to decide which Mode you want to use.

@DatabaseName – the default results include information for all databases, but use this parameter if you have a specific database that you are reviewing. Using this parameter can greatly reduce the results.

@Override – by default the stored procedure will quit and notify you if you run it on an instance with 50 or more databases, since collecting the history on that many databases can use substantial resources. Use this parameter to override that and run the full check.

@VersionCheck – the default is 0, but setting this to 1 will return the version number and version date of the copy of sp_CheckHealth you are running, and nothing else.

What do the Importance levels mean?

1 – High. This is the stuff that needs your attention, like recoverability gaps, integrity problems, or configuration that is actively working against you. Try to address these when you can.

2 – Medium. This is the stuff that may or may not be intentional, like certain settings, trace flags, or security configuration. Review these findings to make sure they were all intended or expected.

3 – Low. This is stuff that probably isn’t a problem, but you should be aware of it anyway.

What are the requirements to use sp_CheckHealth?

There are two requirements.

Your SQL Server instance should be using SQL Server 2014 or higher. If you are using an earlier version, execution of the stored procedure will skip some checks because some of the DMVs used don’t exist in earlier versions. The results should still be valid and helpful, but you should really consider upgrading to a newer version. Or maybe it errors out for earlier versions, but if it does we can’t help you other than to say that you should plan to migrate to a supported version.

You need to have VIEW SERVER STATE and VIEW ANY DEFINITION permissions. This tool uses several system tables and DMVs to collect information about your SQL Server instance, and these permissions will allow you to read nearly all necessary information. There are some checks that require permission in the sysadmin role, but those are skipped if this permission is not present.

The post Introducing sp_CheckHealth: Check Your Overall SQL Server Health appeared first on SQL Server Consulting - Straight Path Solutions.

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 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.

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:

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.

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.

What Should You Do Next?

If this post has you wondering about the health of your own SQL Server environment, you have a few options.

Want to do it yourself? We’ve released our SQL Server health check tools for free. Start with sp_CheckHealth, and use tools like sp_CheckSecurity to dig deeper into specific areas. Jeff Iannucci and I are also doing a series of free sessions walking through how to assess your own SQL Server environment and what to do with what you find.

Want somebody to help you do the health check? We do SQL Server health checks, too. We’ll help you understand what’s actually dangerous, what should be fixed first, what can wait, and what the path forward should look like. The goal isn’t to hand you a PDF. It’s to leave you knowing what to do next.

Need somebody to actually own this with you? Sometimes a health check isn’t really the problem. You already know there’s technical debt. You don’t have enough DBA capacity to work through it, or you need ongoing monitoring, coverage, and senior DBA help. If that sounds more like your situation, we’ve put together and are continuing to contribute to our Buying DBA Services post series explaining how managed DBA services work, what they cost, when they make sense, when they don’t, and what to ask before you hire any of the great shops providing that service out there.

Do It Yourself → Do your own SQL Server health check. Start with SP_CheckHealth, check out the monthly webinar series Jeff and I are doing on linked in. Intro session recording is here, follow me on LinkedIn to see the links for the next ones.

Get a Health Check → Buy a $997 SQL Server Health Check from us if you want some help and review/documentation.

Get Ongoing DBA Help → Check out our series of posts about the buying DBA services or check out our remote SQL Server dba services – DBA as a Service.

At the end of the day…

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.

The post Why SQL Server Health Check Findings Don’t Get Implemented (And What to Ask Before You Buy One) appeared first on SQL Server Consulting - Straight Path Solutions.

There’s a pattern we’ve lived through many times at Straight Path. A client we’ve served for many years gets acquired. Sometimes they are folded into a larger holding company and the client is held forever, sometimes they are raided for their contracts and a few people, sometimes it’s a private equity group making a platform play maybe there’s a strategic benefit. In all cases, eventually – sometimes months – sometimes years – later new leadership comes in for the mandated expense review and contract review. Where can the cuts happen? Where can EBITDA be protected? And they usually find us… We don’t do cell-phone contracts, each quarter is renewed if it’s earned, and if it’s not – we don’t want to force a bad fit. That model really works and it helps us operate within our values even before we’ve sent an invoice. But here? The model can break. For us, sure, we’ll be fine and find new clients, but also for the company we’ve served for a long time. We’re the easy cut. No long term contract, we aren’t even that expensive, so how much value can we really be adding?

Cutting the niche database managed services provider is a pretty easy decision on paper. No severance, no HR talks, not even a contract to really unwind. Surprisingly, we wind up staying more often than not – and for many of those firms we’re still with them as a resource across their entire portfolio of clients because they get the value a team with breadth and depth in SQL Server, Cloud, Databases, Performance, etc that operates in a fractional model. Sometimes we get the cut. A couple of times we’ve gotten the cut and then called back in later…

I’m obviously a bit biased… I run a company that I founded with a team that has grown with me and stays with the company and I think we do a great job. But we also help sometimes with due diligence work FOR these acquirers and we’ve even helped some clients hire the right full-time DBA that replaces us when that is the best answer. So I want to talk about the case for and the case against keeping a company like us…

The Case Against Keeping DBA as a Service Team

There are real reasons to cut a service like ours. Below are a few and if any hit where you are – you probably should cut us or the company like ours.

You have a genuine shared services team with capacity and expertise

Some acquirers – especially the larger vertical software guys have built amazing central platform/database teams that serve their entire portfolio of companies. If that team exists, has senior SQL Server people on it (today SQL server is our platform, though we are in the midst of also becoming a Postgres team, more on that soon) and it can absorb another platform – you absolutely should consolidate that support. You have one standard operating book, one toolset, and you still get one throat to choke – but instead of it being mine it’s the leader of that team. I think the key emphasis here is on genuinely having that. If they are stretched across platforms in your portco, generalists and don’t have the bench of MVPs, authors, trainers, bloggers, etc that your partner has – it could become a case to keeping us around a bit.

The product is being managed down.

Business is business, and I hate to see a product team I loved to work with and build a relationship with have their product be the one chosen to be redundant to the software the new owners already had. But if the buy was for quieting a competitor or moving the MRR to the new product, it’s the decision. Some products get invested in, some get maintained, some get milked along towards sunset and migrations. If the plan for a product is slow wind-down, no new onboardings and sales and customer retention and experience matters a bit less – you may not need as much proactive database support. You don’t need the architectural advice and support, the tuning to keep the clients happy and leaving good reviews or the team catching the P1 before it happens. You still need to test your restores, keep your client’s data secure and stay out of the news with a breach headline – but you maybe can split the tasks among your team or have us wind down to just some hours to support and no actual monitoring and best practices ahead of the curve. We’ll sell you a bucket of hours to help you if you’d like but it makes sense to manage it less if you’re winding it down.

The workload justifies investing in a DBA team.

We tell folks before they sign with us – if you need 40 hours a week of DBA team, we’re too expensive. I have a post coming out in a couple of weeks that does all of that math – and it’s actually closer to 15 hours of consistent steady work – if you are looking at a numbers by the hour game only – we lose there. Sure I believe having one DBA is the same thing as having none and I blogged about that last week. Maybe it’s time to really invest if the work is not getting done and you need a DB developer or DBA there full time. We can help you transition that work to someone and even help you find and train that person. And if you get a team of DBAs who can cover you around the clock for emergencies, the case is closed – you don’t need us in there, and you can save that $20,000 – $72,000 a year you’d spend on us depending on the level.

You’re reducing vendor count for real risk reasons.

This one is a little trickier. We are in the midst of our SOC2 audit and it’s going well, should have our report in hand in a month. And we serve credit unions, banks, healthcare providers, insurance, governments, etc. I think the risk factor isn’t there with us, and we answer plenty of security questionnaires for vendors and haven’t failed one yet. That said – we’re your DBA team so we need certain access, we need certain tools in place, and if we can’t get that for a real risk reason or that’s just the policy from on high – then why pay for a service that you can’t fully utilize.

The Case for Keeping The Service

Your ARR sleeps in your database

Monthly recurring revenue is the lifeblood of the vertical SaaS company world. Your customers have a seemingly endless number of places to put their monthly fees and I could have sworn I wrote a blog post long ago about why Inertia was a terrible customer retention strategy – I can’t find the post or a draft so I’m not sure, I mentioned it in the M&A advice post at least. I still think it’s a poor strategy either way. Customers will leave eventually when that is the strategy. And the renewals go down, the EBITDA slips… Cutting the team who helps keep you in a proactive stance, teaches your team, tunes the environment, and stays ahead of the future corners and has been lobbying the existing team for upgrades and improvements for years is risky.

The math usually doesn’t math the way the report from finance suggests…

A single senior DBA with all-in costs runs somewhere around $190,000 – $220,000 (I just did some review for the post coming in a couple of weeks) or more once benefits, taxes, training,etc is added. And like I already said above, one is none – you have no coverage and if you don’t keep them interested – they’re gone. Not every company, though, always needs the full time DBA hands on keys, so a lot of that salary for many (not all) companies can become an expensive insurance policy. Our team is bringing our own monitoring tool, SQL Sentry, and a team of experts to be your DBA team. For a fraction of the cost – and for many companies at, say, our Gold level, we’re talking about $56,000 per year if they aren’t on an annual arrangement with a slight discount – even if you add in two emergencies and a migration with some overage – you’re easily under $75k for the year. And many clients who are in a niche SaaS industry are getting my with Silver ($40k a year) or Micro ($24k a year if bought by the quarter, $20k if bought by the year) with our team as their team. And all those monitoring tools are run by SaaS companies who want more MRR and longer deals, so we’re saving you from contracts with them since the tooling comes with us.

You’re gonna need that deep DBA bench at somepoint again

Assets get sold, even when the plan was to hold permanently – the economy shifts and stuff moves, merges happen later. When that day comes the new buyers are going to ask those questions about performance, security, compliance, why haven’t you upgraded? Prove out the RPO and RTO the SLA says you offer. Those questions are a lot easier when the DBA team is an extension of your team and, as our reviews suggest, operates like a part of your team. We make those questions get answered with ease and the proof is in the pudding usually.

The spend is already shaped like the way you probably operate

At least when Straight Path is your DBA as a Service provider. Probably most of our friendly competition also. Our model is pretty simple: a relationship based model priced quarterly, renewed quarterly if earned, no long-term exit clause in the contract and it can flex down when spend goes down and flex up when the needs are higher (saving you money from overage.) If integration means there are some aspects of service your central services/platform/DB team can deliver, we can reduce our costs and hours. If you bring in a multi-hat wearing person who can take on some of the work but still need us a backstop or mentor – we reduce and mentor. And you still always get a chance to exit us every 90 days as things change. This seems pretty aligned to a disciplined portfolio management strategy as any outside vendor relationship can get.

Five Questions to Answer Before You Cut the Line Item

1. Who watched the databases at 2AM last month? Who was ready to swing in and fix the issue with a simple phone call and could fix it while the leadership team slept hopefully unaware? Who will watch it after the cut? How quickly will they solve it?
2. What did the last unplanned outage cost? In dollars? In renewals? In reviews? Who fixed it? Who fixes the next one?
3. If we move to the central team, how busy are they? How much attention does this new platform get? How expert are they at the specifics of this environment?
4. Who will push us to make the right decisions based on working with hundreds of customers? Do we know enough about what we don’t know? Do we have the wisdom across a lot of clients to know why one decision isn’t as good as the other? Will the new folks be unbiased or will they prefer a certain direction because of their own incentives?
5. What are we actually saving net of monitoring tools, on-call coverage, the hire we will need and the risk we’re asking to take on?

If the answers and the info above still push towards making the cut – then cut and any great managed services provider worth keeping in your contacts will do a clean knowledge transfer and leave that bridge in-tact and door open. We do every time because tech is small and the industry is small. The relationships often outlast the transactions and we get called in when someone moves on – and we’ve literally been called back when the big company management team switches out the leadership team again and they realize that the databases weren’t getting the love they needed.

The post Should You Keep the Managed DBA Service After Acquisition? Pros and Cons appeared first on SQL Server Consulting - Straight Path Solutions.

There are at least three situations where, if you called me and described what you needed, I’d probably tell you not to buy DBA as a Service from us – and all of these are situations where in the early days we said yes and then learned. We’d rather say no now. Actually, I’d probably tell you what I think you should buy instead. I don’t like “no” by itself, our Straight Path Principles suggest that maybe “NO!” isn’t a great answer (unless it’s “should we do an in place upgrade?”)

DBA as a Service is a specific kind of solution to a specific kind of problem. Sometimes you need that. Sometimes you need a different flavor of the DBA services, and there are all sorts of choices out there. And sometimes you really just need to hire a person.

The short answer: DBA as a Service is probably the wrong fit if your organization cannot act on recommendations, if you only want somebody to clear alerts without caring about root cause, or if you really need 30–40 hours a week of dedicated hands-on database work.

This post is Part of our Buying DBA Services series: We’re sharing what we’ve learned from inside the managed DBA business over the years to help you understand the costs, tradeoffs, problems, and questions to ask before choosing a provider. The goal is to help you make the right decision, whether that means hiring Straight Path, another DBA company, an internal DBA, or nobody at all.

The video gets into all of these, but I’ll describe the three situations a bit more here.

1. You’re Paying for Expertise Your Company Can’t Actually Use

The first bad fit is an organization where every recommendation has to travel through six layers of approval, three committees, two architecture review boards, and a partridge in a pear tree before somebody can actually do anything. And even then that’s only if it gets through some pride filters and some curmudgeon client success manager at a software vendor…

• Nobody really owns the decision.
• Everything gets analyzed until nothing happens.
• There’s a term for that: Analysis paralysis.
• I’ve had that job before (and I left for a reason…)

I spent part of my career at a very large, very well-known insurance company where I learned the term firsthand. And to be clear, this isn’t really about company size. We work with large organizations, Circle K and Rawlings Sporting Goods come to mind. Large organizations can be fantastic clients.

The problem is when nobody has the authority, appetite, or ownership to actually improve anything. And that can happen at the smallest of companies – though it does tend to happen just a bit more at the biggest of companies.

You can hire the best DBA team in the world. They can identify the problem correctly. They can show you the risk. They can give you the exact change. They can tell you how they’d test it, how they’d roll it back, how much downtime to expect, and why they think you should do it.

But if all they’re allowed to do is Observe. Document. Wait. …you’re paying for expertise you can’t use.

That’s a terrible way to spend your money.

What should you buy instead?

Maybe you really do need a full-time internal DBA.

Some organizations need someone embedded in the company who understands the political landscape, knows which approvals have to happen, builds relationships over time, attends all of those meetings, and gradually gets things moved through the organization.

That’s a different job from bringing in an outside team that is supposed to help you continuously improve the environment.

And, yes, I joked in the video that maybe you need someone who is really content with things the way they are and waiting for retirement. I’m mostly kidding… Mostly….

The real point is that if your organization cannot consume change at the rate an outside team can recommend it, paying for more recommendations probably isn’t the answer.

Before you hire a DBA service provider, ask yourself: If they tell us what needs to change, can anyone here actually make or allow it to happen?

If the answer is no, solve that problem first.

2. You Really Just Want a Security Monitor

There was an old GEICO commercial I still talk about with our team. Here it is:

Helpful. That’s the analogy I use for the second kind of relationship that isn’t a good fit for us. (And it’s a think I repeat to the team often because I never want us to be a database monitor… Anyone can do that. Vibe-coded apps can do that…)

Some companies don’t really want their managed DBA provider to own anything. That sounds odd, but I mean it. They are just looking for a security monitor in slack hours or to quiet the noise.

They want someone to see an alert quickly, acknowledge it quickly, apply the fastest possible fix, close the ticket, and move on.

Tomorrow, when the same thing happens?

Do it again. And again. And again.

That model absolutely exists.

There are providers with very large teams and operating models built around high-volume alert response. They are very good at it.

If that’s what you need, you should talk to them. But that’s not the relationship we’re trying to build at Straight Path.

Alert clearing and ownership are not the same thing

Our team is full of geeks. I say that lovingly.

They’re authors, bloggers, speakers, longtime SQL Server professionals, and people who get genuinely annoyed when something keeps breaking for the same reason.

If an alert happens, of course we want to fix the immediate problem.

But then we want to know:

• Why did it happen?
• Can we keep it from happening again?
• Is there a configuration issue?
• Is there a capacity problem?
• Is there technical debt we need to eliminate with our client?
• Is this a symptom of something bigger?
• Can we make the environment better so nobody has to wake up for this again next month?

We do not want to be paid forever to chase the same pain.

That doesn’t feel like stewardship to me. It doesn’t meet with any of our values.

And it isn’t how I want our team thinking. It’s not how they want to think anyway..

Fast response is still important

There’s an important distinction here because I don’t want somebody reading this and thinking:

“Straight Path doesn’t like alerts.”

That would be a pretty interesting position for a managed DBA company. We absolutely care about fast response. We just hired Richie Rump to join our developers as we slowly release our Skopos Database Monitoring platform to our clients. We follow ITIL for P1, P2, P3, and we measure that response rate. Do we like alerts? I don ‘t know – but they are critical and we’re on them.,

Our DBA as a Service clients have a 15-minute P1 SLA, and our own full-time DBAs participate in the on-call rotation.

We take the reactive side seriously.

We just prefer this sequence:

Problem → Resolve it → Understand it → Prevent it

instead of:

Problem → Resolve it → Close it → See you tomorrow

There are times when you genuinely just need somebody keeping the lights on.

Maybe your organization is in transition and you’re not ready to address the larger issues yet. Maybe you own the proactive and long-term and fast incident handling is all you want. That’s fine, just recognize what you’re buying.

You may want an alert-response service with fewer Senior DBAs and more helpdesk DBAs around the world more than an ongoing DBA relationship.

3. Sometimes You Don’t Need Managed Services at All

This one probably surprises people more. Sometimes you just need a person.

Not an outside team from a DBA as a Services team. You don’t need a fractional DBA team. You just need a person.

If you have 30 or 40 hours every single week of database work waiting for somebody, DBA as a Service can get expensive compared with simply hiring dedicated capacity.

Maybe you have:

• ETL packages that constantly need work
• Stored procedure development
• Application releases every week
• A giant backlog of database tickets that gets added to faster than it gets emptied
• A role that is one part DBA, one part application developer, one part DevOps engineer, one part developer, and apparently one part who knows.
• Enough day-to-day work to keep one person busy essentially forever

If that describes you, we’re probably too expensive for the job.

We intentionally built our DBA as a Service offering around something different. We want to use a quarterly allotment of hours intelligently.

We want enough room to do proactive work, fix problems, plan ahead, and still preserve capacity for the surprises that inevitably show up.

If what you actually need is somebody sitting in the proverbial chair doing hands-on work 40 hours every week, go hire a contractor or an employee. We can even help you do it.

A managed DBA team can still support that person

This doesn’t mean there’s never a role for us.

We have clients where the model looks more like:

Internal DBA or developer + Straight Path

Maybe we help with architecture. Maybe we mentor the person you hired. Maybe one of our senior DBAs reviews difficult changes. Maybe you bring us in for escalations. Maybe we help interview DBA candidates or think through what the role should actually look like. Maybe we become the person’s backup so they aren’t carrying the entire environment alone.

That can work really well.But don’t buy an expensive team of experts when what you really need is a dedicated pair of hands.

And certainly don’t let a managed-services salesperson convince you otherwise.

So What Are You Actually Trying to Buy?

This is the question I’d ask before comparing DBA providers, reading proposals, or scheduling five demos.

What problem are you actually trying to solve?

Here’s the rough distinction I’d use:

None of those is automatically better than the others. And DBA as a Service can slot into many of the situations. The approaches and type/size of the service providers all solve different problems.

I’ve written before about the questions I think you should ask when evaluating a SQL Server managed service provider: team size, coverage, SLAs, proactive work, experience, whether they actually improve the environment, and whether they teach your team instead of gatekeeping knowledge. Those questions matter.

But before you ask any of them, figure out which kind of relationship you need in the first place.

When DBA as a Service Does Make Sense

I’ve spent most of this post telling you when not to buy the thing we sell, so it’s probably fair to explain when I think working with one of the excellent firms our size works really well.

DBA as a Service tends to fit when you want access to a broader SQL Server DBA team without hiring all of that expertise internally.

Maybe you have a good internal DBA but they need backup.

Maybe you have sysadmins managing SQL Server and want experienced DBAs available for the harder work.

Maybe you have nobody dedicated to SQL Server and you need somebody to actually own backups, recoverability, performance, patching, configuration, monitoring, planning, and all the other things that eventually get neglected when everybody is busy.

Maybe you need somebody at 2 AM, but you also want someone thinking at 2 PM about how to prevent the next 2 AM call.

That’s where the model starts making sense.

A Good Provider Should Be Willing to Tell You “No”

There’s probably a larger point here than DBA services themselves. Your journey to a DBA as a Services provider should be one with due diligence and review. I’ve recently shared 7 things to check before you hire a Managed SQL Server DBA service provider and some thoughts on How to Choose a SQL Server Managed Service Provider. Those posts may help you pick the best firm that’s best for your specific situation.

If somebody sells one particular solution and somehow every prospect they meet needs exactly that solution, I’d ask a few more questions. Sometimes we aren’t the right company. Sometimes DBA as a Service isn’t the right service or you need the larger firm.

Sometimes the best thing I can do on a sales call is tell someone, “You shouldn’t buy this from us.”

If you’re trying to figure out which problem you actually have, we’re happy to talk it through. If DBA as a Service makes sense, I’ll tell you. If I think you should hire someone instead, I’ll tell you that too.

That seems like a much better way to start a relationship.

The post 3 Times You Should NOT Hire a DBA as a Service Provider appeared first on SQL Server Consulting - Straight Path Solutions.

You know the thriller movies where they keep looking for the creepy stalker type? The phone calls keep coming, the signs of stalking are there, and they do a bunch of digging and through the taps or traps they realize the calls are coming from inside the house.

I just spent an afternoon proving something I’ve been saying for years, and it landed exactly where I expected. It was one part exciting (I had to do some ugly stuff to get SQL Server 2014 to install, and I got to do a demo in some SQL which is a nice change from spreadsheets and Level 10 meetings…) And one part scary (What I keep shouting is proven true, in about 1 minute in the second part of this video:)

The SQL Server Vulnerability

Here’s what I did. I stood up a SQL Server 2014 instance. Service Pack 3, latest CU, latest security update (I’m not paying for the ESUs so I don’t know if this one is fixed already for those paying for the 2014 ESUs, they run out next year anyway, and they aren’t there for SQL Server 2012 and back.) Then I built a second instance to be my victim, patched it exactly the same way, and I restored a database backup to it that I created on the first. I added a stored procedure to a database on the souirce instance, made the DB a publisher in replication, added a schema and took a backup of it. That’s it. No password cracking. No malware. No clever network trickery. I restored a backup to the second instance, which is the single most routine thing a DBA or a sysadmin does in any given week. And when the restore finished, there was a brand new login sitting in the sysadmin role that I never created on that instance. I logged in as it. I owned the instance. Game over.

(If you want the deep technical walkthrough of how this actually works, go read Fabiano Amorim’s excellent post over at Redgate. He found this, he reported it to Microsoft, and he explains the mechanics far better than I’m going to here. I just followed his steps in my little lab (fixing one little typo – he needed an extra bracket in most scripts.) All the credit is his.

The short version: it’s CVE-2026-47295, Microsoft rates it an 8.8, and the trick behind it is a tricky one. An attacker crafts a database with a deliberately bizarre name (a big pile of closing brackets in this case), adds a simple stored procedure inside it with a schema with the same bizarre name as the database, backs the whole thing up, and hands you the .bak. When SQL Server restores that backup and runs its normal replication cleanup when you restore a DB to a new instance, an old internal procedure builds a name, runs out of room in the variable it’s stuffing that name into, and winds up running the attacker’s cleverly named schema.procedure instead. As the highest privileged user that could exist in SQL Server – internal to the system…. During the restore. Before you’ve even had a chance to look at the thing you just restored. (And he could have gotten more creative also – make a job that does things, add more logins, add some steps, exfiltrate data, unlock other doors, etc.)

Microsoft Not Patching an Unsupported Version Does NOT Mean It’s Safe!!!

Microsoft fixed this on July 14th, 2026. They fixed it on SQL Server 2016 (Service Pack 3), 2017, 2019, 2022, and 2025. They did not fix it on 2014 (unless they did with the ESUs – not a subscriber there..) They did not fix it on 2012 or back. It would be very easy to skim that list and think “well then, the old ones must not be affected.” That read is exactly backwards. Those older versions didn’t get the fix because they’re out of support. Out of support means the patches stop coming. It does not mean the bugs politely stopped existing.

And this code is old. The whole replication cleanup path this bug lives in has been kicking around SQL Server since, as near as I can tell from poking at it, the 2005 era (that appears to be the last time that proc was changed – I didn’t have the time to test all versions but if this one doesn’t impact older versions – but isn’t SQL Server 2014 old enough?!? – the next one may anyway..) Replication itself goes back further than that. Nobody introduced this in some shiny recent feature release. It’s old plumbing that’s been sitting inside just about every version you’ve ever run, quietly, for the better part of two decades, until somebody finally looked at it hard enough to notice.

This is Why I Keep Shouting UPGRADE YOUR SQL SERVERS!

The vulnerabilities getting found and patched month after month are usually not in the brand new stuff. They’re in the old surface area. The plumbing that’s been there forever and nobody scrutinized until now. Which means when one of these gets discovered and published, the odds are very good it was already sitting inside your unsupported instance the entire time, just waiting for someone to walk up to it. And the odds are close to certain that more are on the way, because the folks hunting for these things (both the good-faith researchers chasing bug bounties and the bad actors who are very much not chasing bug bounties) are burning through tokens looking for them just as fast as Microsoft’s team is fixing them. It’s a steady drip. Every patch month. On and on.

You Can Harden SQL Server… But Is That Enough?

So let me be fair here, not all FUBAR on you. This particular bug? You can absolutely harden against it. And you should, today, on every instance you’ve got, supported or not… This is just some good advice with or without this one:

• Don’t restore backups you didn’t create onto anything that matters. Treat a vendor’s .bak or a customer’s .bak the way you’d treat a random .exe you found on the internet. No amount of paranoia is too much here.
• Use an isolated, throwaway lab instance for restoring anything that came from outside your walls.
• Alert on RESTORE operations. Most shops watch queries all day and never once watch restores. A restore is a privileged event and it deserves eyes on it.
• Alert on new logins, and especially on new members of the sysadmin role.
• Go hunting for databases and schemas with strange names (long runs of brackets are a dead giveaway with this one).
• Run a security sweep with a tool like SP_CheckSecurity on the regular.
• Setup auditing and actually read the audits regularly.

Do all of that. It’s good best practice and it helps you with a lot more than just this one CVE.

But here’s what hardening can’t do for you. It can’t protect you from the one you haven’t read about yet that finds some new flaw we aren’t auditing. Or maybe it exploits you and you can read all about it, tomorrow or on Monday. Running on software that gets updates means that Microsoft is on your security team at least in some fashion… They are finding and fixing the exploits that you are buying time against with the best practices. Hardening buys you time on the bugs you know about and the ones that eventually get fixed. Being on unsupported software means you are out there on your own longer than you’d like to be.

Count The Cost

Which brings us to the only question that actually matters to the person signing the checks. What does it cost to stay?

There are two doors, and honestly I don’t love either one of them for you.

Door one is ESU. Microsoft’s Extended Security Updates program will happily sell you critical patches for 2016 (and 2014’s paid window is nearly shut now too). But you pay through the nose for the privilege, and you only ever get the updates that Microsoft decides are “critical.” and I’m sure their lawyers made the agreement you sign be in their favor – it’s probably best effort, no guarantee. You and I don’t get a vote on that definition. And Microsoft is a very busy company these days, trying to keep Fabric up, fixing the bugs that the AI bug hunters are finding and worrying about the cloud. Your ten or 12 year old database engine isn’t where their major focus is. I would not want to bet my clients’ data on how much attention an out-of-support version is going to get.

Door two is worse. Door two is the breach you weren’t covered for. Because here’s the thing a lot of folks have never actually checked: Insurers are starting to carry conditions about running supported, patched software. Running an end-of-life database engine can hand your insurer a very clean reason to reduce or flat-out deny a claim. And when that claim gets denied, the remediation, the breach notifications, the lawsuits, the settlements with your Credit Union members, patients, banking clients, SaaS subscribers, manufacturing customers, etc. all come out of your company’s pocket, and the numbers involved are the kind that decide whether a company is still around next year. It’s also the meeting where everybody in the room slowly starts looking around for the one person who decided to stay on the old version.

Upgrading is cheaper than either door. Over Time – It’s not even close.

And upgrading is not the monster you’re picturing in your head right now. I’ve been doing SQL Server work for a long time, and I still treat every single upgrade with care and a healthy dose of paranoia. But with some real planning, a clean build, honest testing, and the compatibility mode settings that exist precisely so this goes smoothly, we move shops onto a supported version all the time. (Just don’t get me started about in-place upgrades… Let us help you do a simple migration upgrade.) For the simplest of environments it can be as little as 20 hours of work. We do dozens to scores of these a year for our clients. It’s become almost second nature, which is exactly what you want an upgrade to feel like.

So that’s my plea. If you’re on 2014, or you’re on 2016 without paying Microsoft’s toll, or (I see you out there….) something older still, please go build a plan. This week’s demo is just ONE bug. There will be another one next month, and it’ll probably be in old code too, and the fix will land on the supported versions and skip right over yours.

If you want a hand, reach out. Even if all you want is a second set of eyes and a straight answer about what your upgrade path would actually look like. I’m glad to point you in the right direction whether you ever become a customer or not.

The post I Restored a SQL Server Database and Became a Sysadmin appeared first on SQL Server Consulting - Straight Path Solutions.

Having an amazing DBA, having reliable coverage, and having proper support are not the same thing.

Relying on one DBA creates a coverage gap because one person cannot provide 24/7 availability, deep expertise in every SQL Server discipline, and enough time for proactive maintenance. The solution is not necessarily replacing that DBA. It is giving them trained backup, documented access, clear escalation procedures, and a broader team behind them…

This post is Part of our Buying DBA Services series: We’re sharing what we’ve learned from inside the managed DBA business over the years to help you understand the costs, tradeoffs, problems, and questions to ask before choosing a provider. The goal is to help you make the right decision, whether that means hiring Straight Path, another DBA company, an internal DBA, or nobody at all.

Prefer to watch? Catch my breakdown above, or read on for the details.

The “Math Problem” (And the Urgent vs. Important Trap of a Solo Prod DBA)

This isn’t about whether your DBA is committed. It doesn’t matter about their training. Most DBAs really care. We’re sort of a strange personality type that wants to own the world and fix everything. But it comes down to a simple math problem: Can one person realistically provide the coverage you need every hour of every day of every week of the year?

Spoiler: No… Heck No…. In spite of what some people think, DBAs actually like taking vacation sometimes, at least I’ve heard of those that do. And our families prefer we don’t take our phones and laptops to the beach. When that one person isn’t available, who has the access, the experience, and the context to step in and make a difference?

Even when they are at work, a strong DBA has specialties, and it can’t be in all areas. A performance tuning expert might not be the person who spends every day building DR architectures, planning cloud migrations, or handling SQL Server upgrades. (Just look at all the SQL Server 2016 instances still out there, completely end-of-life and unsupported. Some DBAs can stay at one job for ten years and still have never done a SQL Server upgrade.) That’s normal when a DBA isn’t deep in everything. And one person just can’t be.

The real danger is the “Urgent vs. Important” trap. The urgent work always wins. The meetings, the broken jobs, the daily fires. The dangerous part is the stuff we push to next week, next month, or next year (restore testing, documentation, patching, capacity planning, migrations, upgrades, stopping the drift and reducing the cloud costs…) The stuff that just gets left behind until that overwhelmed solo DBA eventually quits and the cycle continues for the replacement who comes in slaying dragons and bringing heroics eventually to find that they can’t get it all done either.

The “Quick Fixes” That Don’t Work

Companies try to solve this coverage gap in all sorts of ways. I’ve been on all sides of these methods, they don’t work:

• Knighting the Sysadmin: You point at a network admin, say, “You can spell SQL Server, therefore you are the backup DBA,” but then they never get the training to actually do the job safely (assuming they even get the time to actually do it – they won’t – they’re fighting their own urgent tasks, too.)
• Pretending Vendors Are DBAs: I’ve had uncomfortable calls with companies who say, “I thought our eDiscovery or ERP vendor was my DBA because their support team gives me so much advice.” No, they aren’t your DBA team, and you should have been taking backups, and now you have to talk to me because you’re not in a good state. I probably have at least 3 blog posts about those situations.
• Buying a Monitoring Tool: I love a good monitoring tool, but an alert is not a resolution. A tool can tell you something broke, but it can’t tell you the business impact is, the safest solution, or the historical context of why this server was configured that way. The DBA already knows there’s a problem. The monitoring tool just temporarily band-aids it by letting you turn the alert off until it comes back in a day or two.

The Real Cost and SLAs of DBA Coverage

When IT leaders finally realize they have a coverage gap, the conversation usually turns to cost, SLAs, and response times.

If you rely solely on one person, what is your actual SLA? It’s “whenever they wake up” or “whenever they get back to their desk.” If they are on vacation, your response time is practically nonexistent. What if they get sick? What if they decide they are done being the only DBA and join a bigger team?

You could hire two or three full-time DBAs to get true 24/7/365 coverage with guaranteed SLAs, but from a cost perspective, most companies can’t justify a massive payroll for a database team. You could buy an expensive monitoring tool, but as we established, you’re paying thousands of dollars for alerts, not fixes to watch your database estate.

Healthy coverage doesn’t mean replacing your DBA. It means putting a team behind them, around them. When you look at the “co-sourcing” of DBA as a Service, you are generally paying a fraction of the cost of a single full-time senior hire, but you get access to an entire bench of experts with guaranteed SLAs for response and resolution, and you aren’t paying them to be in meetings or sing happy birthday to Mimi in Accounts Payable.

Here is what that actually looks like when you compare the options:

The One Question You Need to Ask

At the end of the day, you should ask your DBA this one question: When you’re not available (whether it’s planned or sudden), who can really take over your work?

If the answer is unclear, or they laugh and say, “Don’t worry, I’ll just take my laptop on vacation and not get sick,” that doesn’t mean you have a bad DBA. It means you have a critical coverage gap. And it probably means that person is going to leave at some point to go get some help or work somewhere they have a little more support (or join a team like ours – but we can’t hire them if we’re contracted to you – it’s in our agreement!)

If you’re a solo DBA and you’d like to have a team join you and help support you, or you want to help your DBA succeed and stay, our DBA as a Service offering may be just what you are looking for. All 22 of us here at Straight Path help companies solve this every single day. Reach out, and let’s get you some backup.

The post Your DBA Isn’t the Problem. Depending on One DBA Is. appeared first on SQL Server Consulting - Straight Path Solutions.

Saving money on licensing makes strategic business sense, but executing a quick “lift and shift” migration of production database servers into an untested virtualization environment creates serious hidden risks. I’m all for a fun rope swing into a river…. But I’m a fan of not being the first one or at least looking around a little bit before leaping… Some recent chats with clients brought this back up, made me rant a bit on a video (below) but here’s the point I’m getting at.

The Return of Virtualization “Gremlins” for our SQL Servers

In the early days of virtualization 15 years ago or whenever those bleeding edge days were, us DBAs spent countless hours chasing transient issues, unexpected I/O bottlenecks, and mysterious storage corruption (“no… SQL can’t be at fault here because this is how it works” conversations were definitely had…) Over the last decade, hypervisors matured to the point where database teams rarely had to worry about underlying host layers. I haven’t fought for an RDM in ages on VMware – though I still push for PVSCI and other best practices and still arm wrestle about the snapshot breaking production performance a bit too much. Most of that is covered in our VMWare Best Practices guide for SQL Server.

With the sudden rush away from VMware, those early-era gremlins are starting to return here and there, and I’m getting a little scared for our clients. Especially when their sysadmins or integration partners sort of move them and then tell us (their DBA teams…) When hosting providers or MSPs take a legacy VM (running Windows Server 2012, 2016, or 2019 with SQL Server whatever version) and wedge it directly into Proxmox or another hypervisor without adjusting underlying drivers, storage caching, or NUMA configurations, problems follow quickly:

• Unexplained Performance Degradation: Storage latencies spike due to unoptimized virtual disk controllers or caching policies.
• Transient Storage Failure & Corruption: Database integrity errors and corruption spikes often align directly with the exact date a VM was migrated. (It was a series of transient checksum errors that brought this post to mind – and until today they dodged the corruption. Thankfully it’s an AG and the other node is good for now – though each node have the checksum errors when either is primary…)
• Configuration Oversights: Default settings on cloud platforms like Azure or open-source hypervisors are rarely tuned for heavy database write workloads.

Why “Lift and Shift” Fails Production Databases

Databases are fundamentally different from standard application servers. SQL Server relies heavily on low storage latency, explicit CPU/memory allocation, consistent disk flush guarantees, and stable driver stacks. (I mean all server types like all of those things, but a database server really really realllllly needs those things)

When an IT team or MSP migrates a database VM using standard default settings:

1. Disk Flushing Policies: Some hypervisor caching modes do not honor write-through guarantees, putting transaction logs at risk during power or host events.
2. CPU & NUMA Mapping: Default virtual CPU assignments can break NUMA node alignment, severely choking SQL Server memory access speeds.
3. Driver Incompatibilities: Legacy guest OS drivers interacting with newer host kernel modules cause unexpected driver-level resets.

Saving $30,000 on VMware licensing provides little value if it leads to an emergency outage that costs double that amount in downtime and consulting fees – I’ll take the hours, sure, but I’d rather the client and their clients keep the peace of mind.

A 4-Step Checklist Before Migrating SQL Server Hypervisors

Before letting an MSP or internal infrastructure team migrate a production database host to Proxmox, Hyper-V, or Azure, verify these four steps:

In addition to those steps (that’s the minimum – and it would save you a lot of extra time with your DBA team or Managed DBA as a Service provider..) really ask if the lift and shift is the best way. If you are migrating, say, a Win 2016 server – maybe it’s time to consider doing a migration and building a clean VM from scratch. How many old machines were P2Vd up to VMware to begin with? You want to roll the dice and do a “V2V” with that now? Taking all of the pain that has been on that server for 8-10 years and gamble that production will be fine?

Proactive Planning Beats Emergency Support

Alternative hypervisors like Proxmox or cloud hosts like Azure can run SQL Server effectively, but only when configured with proper database-first architecture. And the newer the virtualization technology (or at least newer to high end performance databases on Windows) it is, the more care you need to give before going there.

At Straight Path, our goal is always to help organizations avoid emergencies before they happen. If your organization is planning a hypervisor transition, reach out to your database team or outside SQL Server experts to review the migration plan beforehand. If you’re about to do a migration and want to get your SQL Servers moved wherever you are going safely, and you don’t have a DBA team or you’d like a mentor and backstop for your solo DBA – you should reach out, we can probably help.

The post Hey Sysadmins & Integrators – Look Before You Jump Into the Next Virtualization Platform appeared first on SQL Server Consulting - Straight Path Solutions.