Nobody Teaches You How to Run SQL Server in Production

There are thousands of SQL tutorials online. Courses, bootcamps, YouTube series, blog posts — more than anyone could consume in a lifetime. They'll teach you SELECT, JOIN, GROUP BY, window functions, CTEs. Some of the good ones will cover execution plans and indexing basics.

None of them teach you what to do when your production SQL Server starts grinding to a halt at 2pm every Wednesday.

I've noticed this gap for years, and it's the reason I started building AutoDBA. There's a massive chasm between "I know SQL" and "I can keep a production SQL Server running well," and almost nothing exists to bridge it.

The Knowledge Gap Is Real

Think about what you actually need to know when something goes wrong in production:

• How to read wait statistics and figure out what the server is actually waiting on
• The difference between a PAGEIOLATCH_SH wait (probably a disk issue) and a PAGELATCH_EX wait (probably a tempdb contention issue)
• How to trace a blocking chain back to the head blocker and decide whether to kill the session
• What Error 18456 state 38 means versus state 11 versus state 5
• Why your query ran fine yesterday and is suddenly taking 40 seconds today (parameter sniffing, probably)

Where do you learn this? Not in a SQL course. Not in a computer science degree. Not even in most DBA training programmes, which tend to focus on installation, backups, and high availability — all important, but not the stuff that pages you at midnight.

The honest answer is that most people learn it the hard way: by being the person on call when things break, Googling frantically, piecing together Stack Overflow answers from 2014, and slowly building intuition over years.

Why This Matters More Now Than Ever

Ten years ago, most companies running SQL Server had a dedicated DBA. That person had accumulated years of tribal knowledge about wait types, DMVs, and configuration settings. They knew what "normal" looked like for their servers and could spot anomalies by gut feel.

That model is disappearing. Smaller teams, cloud migrations, and the general push toward "full-stack" roles mean that database management increasingly falls to developers and DevOps engineers who have plenty of other responsibilities. They're smart people, but they haven't spent years building that pattern-matching intuition for SQL Server specifically.

The database doesn't care who's managing it. It still has the same failure modes, the same cryptic error messages, the same hundred-plus wait types that each mean something different. The knowledge required hasn't shrunk — the number of people who have it has.

The Documentation Problem

Microsoft's official documentation is comprehensive in the sense that it covers everything. It's also almost useless when you're troubleshooting under pressure. Looking up a wait type gives you a one-line description. Looking up a DMV gives you a list of columns. What you actually need — "this wait type is spiking, here's what to check, here's the query to run, here's what the results mean" — doesn't exist in any official source.

The best SQL Server knowledge has historically lived in blog posts from people like Paul Randal, Brent Ozar, and Kimberly Tripp. That content is excellent, but it's scattered across years of posts, many of which reference older versions or specific scenarios. When you need an answer fast, you're assembling a puzzle from ten different sources.

This is exactly why we built the SQL Server knowledge base. We wanted one place where you could look up any wait type, DMV, or error code and get everything you need: what it means, when it actually matters, the diagnostic queries to run, and what to do about the results. No login required, no email gate. Just the information.

What "Running SQL Server in Production" Actually Means

If I had to distill the production DBA knowledge that nobody teaches, it would be these areas:

Understanding what the server is doing right now. This means wait statistics, currently running queries, blocking, resource utilisation. Not just "CPU is at 80%" but why CPU is at 80% — which queries, which plans, which waits. The sys.dm_exec_requests DMV combined with sys.dm_exec_sql_text is where this starts, but knowing how to interpret what you see takes practice.

Knowing what changed. The vast majority of "it was working fine yesterday" situations come down to something that changed: a new deployment, a plan regression, a statistics update, a data volume shift. Having Query Store properly configured is table stakes here. If you can't compare today's execution plans to last week's, you're debugging blind.

Distinguishing signal from noise. Every SQL Server has background waits that look alarming if you don't know to ignore them. BROKER_TO, LAZYWRITER_SLEEP, SLEEP_TASK — these show up in every wait stats query and mean nothing. Knowing which waits to filter out is the difference between finding the problem in five minutes and chasing ghosts for an hour.

Making changes safely. Creating an index on a production table is not the same as creating one in dev. Rebuilding statistics during peak hours is not the same as doing it at midnight. Knowing the operational impact of administrative actions — what takes locks, what causes recompilations, what moves the needle on memory and IO — is something you only learn through experience, or through other people's war stories.

Why I'm Building AutoDBA

I started this project because I got tired of watching the same pattern repeat. A team runs SQL Server. It works fine for a while. Performance starts degrading. Nobody notices until users complain. Someone Googles around, maybe finds a blog post, applies a fix that may or may not be relevant. Performance improves a bit, or it doesn't, and everyone goes back to their day jobs.

The knowledge to diagnose and fix these issues exists. It's just locked up in the heads of experienced DBAs, scattered across hundreds of blog posts, or buried in documentation that's optimised for completeness rather than usefulness.

AutoDBA is an attempt to encode that knowledge into something automated. Point it at your SQL Server, run a 60-second scan, and get a report that tells you what's actually wrong — with the same level of context and recommendation that an experienced DBA would give you. Not just "your CXPACKET waits are high" but "your CXPACKET waits are high because your MAXDOP is set to 0 on a 32-core server, here's what to change it to and why."

The knowledge base is the free, public version of that same idea. If you'd rather learn it yourself than have a tool tell you, every article we've published is there for you to use.

Either way, the goal is the same: close the gap between knowing SQL and running SQL Server well in production. Because right now, that gap is where most performance problems live.