A monitoring probe kept firing “SQL Connection Error — Disaster” and clearing itself sixty seconds later. The engine never went down. It was never CPU-starved. It simply had no worker left to hand the next login. This is how I proved that from the DMVs, why max worker threads was the right lever in this one specific case, and the single check that tells you whether it is the right lever for you — because most of the time it isn’t. “Raise max worker threads” is the kind of adv

nitsql — a multi-dialect SQL static analyzer: 52 rules across SQL Server, PostgreSQL, Oracle, MySQL and SQLite. Finds SQL injection, non-SARGable predicates, missing indexes, connection leaks and error-handling gaps — in .sql files and in SQL embedded in Python, Node.js and C#. Runs as a CLI, a CI gate, a pre-commit hook, or a Claude Code skill. Open source, MIT. We maintain quite few SQL Server database repositories — thousands of stored procedures, functions and views, most

I recently ran an in-place operating-system upgrade of a production, two-node SQL Server Always On Availability Group from Windows Server 2022 to Windows Server 2025 — with zero planned downtime and SQL Server left on 2022. It mostly went to plan. The parts that didn't are the reason this post exists. Everything below is anonymized, but the sequence, the commands, and the failures are exactly what we hit. The setup Two nodes — call them SQLNODE01 and SQLNODE02 — running SQL S

I used to open a chat window and ask my AI assistant to health-check the database fleet whenever I remembered to. It worked great — but "whenever I remembered" is a lousy schedule. So I taught the same health check to run itself: every production database server now grades its own health once a week and drops a color-coded report card into our team channel. No one logs in. No one runs anything. Here's the story — and a real (anonymized) report at the end so you can see exactl

Every production database investigation I've ever done started the same way: cold. An alert fires — "DB Call Failures," a blocking spike, a node that just failed over — and the clock starts. I open RPDs, dozen SSMS tabs, remember which server is the primary this week, paste in the same wait-stats query I've pasted a thousand times, and start piecing together what happened. The knowledge of how to investigate lived in my head and a folder of .sql snippets. None of it was avail

In my last post I traced a wave of EXCEPTION_ACCESS_VIOLATION (0xc0000005) crashes on our SQL Server 2022 fleet to an EDR heap-hook incompatibility on Windows Server 2025, and walked through the cross-server comparison that pinned it down. That conclusion held up — for that crash signature. What it didn’t do was stop the bleeding. A few nodes kept crashing after the EDR remediation. Same exception code, but when I actually read the dumps frame by frame, it was a different fau

[UPDATED] In March 2026, our production messaging-database cluster started crashing again. Same exception code as the incident we resolved last year (0xc0000005, Access Violation), but a different stack signature, different servers, different cloud, and ultimately a completely different root cause. This time the bug wasn't in SQL Server. It wasn't in the storage drivers. It wasn't in our queries. It was in something we'd never have suspected without comparing the crashing ser

In late October 2025, our production SQL Server 2022 Enterprise cluster running on AWS EC2 started crashing repeatedly with Access Violation (0xc0000005) exceptions. This wasn't just any database going down — this cluster is the heart of the business. It powers the core platform that our customers depend on every day: real-time communications services, call routing, messaging, and the APIs that integrate with everything downstream. When this database cluster goes offline, the

It was a regular Thursday afternoon. The kind where you're wrapping up tasks, maybe thinking about what to have for dinner. And then, at 4:36 PM, the alerts started rolling in. Transaction processing delays. Partial database inaccessibility. The production database cluster — the one that powers core services for an entire region — was going down. Not because of a hardware failure. Not because someone fat-fingered a config change. But because of something far more subtle: a gh

How default SQL Server configuration brought a production server to its knees — and how two settings fixed it in under a minute. The Escalation It started with a message from my manager: Attached was a screenshot of CPU pinned near 100%. Not a good look on a production server handling live traffic. The Investigation My first instinct was to hunt for a rogue query. That's usually the culprit — some poorly optimized SELECT statement doing a full table scan, or a report running