Mark Varnas | SQL Server Nerd

I make slow SQL Servers fast | Partner @ Red9 | 10,000+ databases later

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

@boardyai @andrewdsouza Let me know if we can help in any way

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

We’ve just launched something we've spent months building.

The free Red9 SQL Server Health Check tool.

So why have we built this and what is the problem it solves?

SQL Server problems rarely announce themselves early and by the time a database makes the news inside your company, it's already an outage or a bill.

- Backups look fine on the dashboard until the day a restore fails.
- Queries slow down and nobody agrees if it's CPU, I/O, memory, or indexes.
- License spend creeps up because nobody has time to right-size the cores.
- Security gaps sit quiet in logins, permissions, and backup files for months.

So we packaged 20+ years of SQL Server work into a tool anyone runs themselves.

145 read-only checks and a prioritized report in under 30 minutes.

What you get:

1. One health score from 0 to 100 for your whole environment.

2. Every finding ranked by business impact, written in plain English. "4 databases have no backup in the last 7 days" instead of a wall of red flags.

3. A 90-day fix plan to hand straight to your team. Quick wins first.

The question every DBA asks before running anything against production: is it safe?

Read-only. No writes, no schema changes, no downtime. Your data never leaves your environment. You review the exact T-SQL of every check before it runs.

We never touch your servers. You run it, you keep the output.

Oh and it’s free. No credit card, trial clock or a follow-up call unless you want one.

Fix the findings yourself or bring us in for the worst ones. Up to you.

Link in the comments.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

Register here: https://t.co/36LjwDgC5O

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

Gentle reminder SQL Server 2016 extended support ended last week.

July 14.

Without Extended Security Updates, normal patching is finished.

The bigger warning is for large SQL Server 2019 estates.

Hundreds of instances, application testing and change windows take years to work through.

Do not wait until the next deadline becomes this week.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

TempDB filled the disk at several client sites.

The culprit was DBCC CHECKDB.

Nothing had changed except the databases had grown and the maintenance jobs had not.

Your integrity checks need to scale with the database.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

One of the easiest ways to break DR:

The failover works. The database comes online. Everything looks green.

Except the application login is missing from the secondary, or its SID and password hash no longer match.

Now the business is down and you are fixing logins mid-outage.

Your DR process has to include the server-level objects around the database, not just the database itself.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

Companies keep doing this.

Big primary SQL node. Smaller DR node to save money.

That can be fine if the business accepts reduced capacity and you have tested it.

But this client had not.

The failover worked. The secondary came online. Then it struggled under production load.

Test your recovery plan before the disaster tests it for you.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

“Do you have DR?” is no longer enough.

Auditors and insurers increasingly want restore logs, failover evidence and measured recovery times.

A diagram is not proof that recovery works.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

Poorly configured SQL Server monitoring makes firefighting worse.

Hundreds of default alerts. Most require no action. Teams tune out.

Then the real warning arrives and gets ignored with everything else.

Monitoring is not a product you install.

It is deciding what deserves attention, who owns it and what happens next.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

AI can analyse approved SQL Server telemetry, summarise issues and draft recommendations.

Execute production changes unsupervised?

Not a chance.

Polished confidence is not the same as safe judgment.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

A client’s DR test failed because the secondary server could not carry the production workload.

Their response was stop testing.

That is not a DR plan. That is a theory nobody wants to test during an outage.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

We moved to Azure SQL, so we do not need a DBA anymore.

I hear this a lot. It is wrong.

Azure SQL and AWS RDS handle patching, backups, and HA mechanics. Real value. Nobody argues with it.

Here is what the cloud will never do for you:

Right size your environment. The cloud wants to charge you more, not less. It will never suggest you drop from Enterprise to Standard, cut CPU cores, or move to cheaper storage.

Those recommendations cost the vendor money.

Tune your queries before they degrade.
Catch the brute force attempt on your login.
Design your DR and HA strategy.
Plan your next migration.

Under the shared responsibility model, your data, your workload, and your security posture are still yours to own.

Cloud removes some mechanics.

It does not remove the need for someone who knows what good looks like.

The cost math does not change either.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

Should you hire a DBA or outsource it?

Run the numbers before you decide.

One fully loaded in house DBA: $186,000 to $258,000 a year.

Business hours only. No nights. No weekends. No backup when they are sick.

SQL Server managed services: a few hundred dollars to $3,000 per server per month.

24/7 SLA backed coverage. Tools included. No recruiting. No sick days. No 4.2 FTE staffing problem.

Even at the high end, $3,000 a month is $36,000 a year. Less than one DBA, and it covers far more than one hire ever will.

Most engagements come in well below, so the break even stretches further.

Hire in house when you run 20+ instances, SQL Server is your core product, or regulation demands it.

Outsource when you run 1 to 10 instances, need real 24/7 coverage, and want accountability in writing.

If you have never priced managed services honestly, you are guessing at the most expensive line in your database budget.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

One DBA does not equal 24/7 coverage.

Here's a little math:

- 168 hours in a week.
- A full time DBA covers 40 of them.
- Leaves 76% of your week uncovered unless you pay overtime or on call premiums.

True round the clock coverage needs 4.2 full time DBAs as a floor. Factor in sick days and vacation and you are closer to 4.6.

So when your production database goes down at 2am on a Saturday, who is answering?

If the honest answer is nobody until Monday, you do not have coverage.

You have a single point of failure with a salary.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

We spent an extra $400 to $500 a month on a VM instance type.

It outperformed RAID servers running tens of thousands a month.

A client ran SQL Server in Azure on custom RAID arrays built on the fastest disks available. Fast on paper. Slow in practice.

The bottleneck was never the disks. It was the VM throughput cap sitting above them, throttling everything, invisible in the standard dashboards.

Move to the right instance type and disk latency went from 300 milliseconds to 37.

You are not always paying for performance. Sometimes you are paying for a ceiling you will never reach.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

Push SQL Server Standard before you pay for Enterprise.

SQL Server 2025 Standard handles 32 cores, 256GB buffer pool, failover clustering, log shipping and Basic Availability Groups. More than most teams realise.

Enterprise will not fix bad indexing or a broken execution plan. It makes the same problems cost four times more per core.

Measure the workload. Find the real bottleneck. Then pick the edition. Buy Enterprise to be safe is not a strategy.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

I remember a SQL Server migration that passed every initial check. The VM moved, SQL Server started, all green.

Then production load hit and storage I/O fell apart.

A booting server does not prove the platform handles the workload.

The fix was clean destination VMs, a database-level migration and load testing before cutover.

The faster-looking path was the slower one.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

We cut a client's SQL Server bill 46%. From $15,698 to $8,491 a month.

They hit a wall on Azure SQL Database Premium P15. 100% CPU spikes, timeouts, zero room to grow while processing 9.6TB a day.

Rather than guess which of the 120+ Hyperscale configurations would hold up, we tested them.

We captured the production workload with Microsoft DEA, built test environments and replayed the real workload against each setup. CPU, reads and duration scored on every one.

The surprise: Microsoft's marketed Serverless option performed worst. Auto-scaling sounds great and did not handle this workload.

Winner: Hyperscale Elastic Pool, Premium-series memory optimized, 40 vCore.

46% lower cost.
15% faster response, 952ms down to 808ms.
30 to 40% more headroom for growth.
CPU off the 100% ceiling, down to 80% peaks.

Hyperscale and Serverless are labels. They do not guarantee performance. You test with your real workload or you guess.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

Hundreds of AWS configs exist for a SQL Server migration. Pick wrong and you pay several times over.

Most teams copy the on-prem spec or size up to be safe. Both waste money.

Every unused vCPU is also a licensing bill. Standard is about $4k per two-core pack. Enterprise is over $15k.

Measure the workload. Then size it.

[Mark Varnas | SQL Server Nerd @MarkVarnasRed9]

Ask AI to fix your SQL Server replication and see what happens.

Replication is one of the least understood corners of SQL Server. The docs are scattered. The good books are over a decade old. The real knowledge lives in the heads of DBAs who have been in the trenches.

A nightmare for AI.

AI is strong when there is a huge volume of consistent material online. Query tuning, index design, common errors. Thousands of examples to learn from.

Replication is different. The answer depends on your exact topology. Transactional, merge or snapshot. Push or pull subscriptions. Publisher, Distributor and Subscriber versions. Agents, filters, identity ranges, security, undistributed commands.

An AI script looks completely reasonable and still misses the one setting taking your whole topology down.

When replication breaks at 2am, a generic script from Google is not enough.

You need monitoring. You need a tested runbook. You need someone who has seen replication break before and knows where to look.