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

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

[UPDATED] One of the major projects I was tasked with in my current role involved solving two persistent issues: Build a redundant Numbering Lookup microservice used by multiple applications. The requirement? It must read from secondary, asynchronous, read-only replicas of NumberingDB, distributed across several regions (DC2, DC3, DC4). The primary source of truth remains NumberingDB in DC1, and our service must only query its regional replicas. Replace SQL Replication for

I worked on a migration project where two production databases were moved from a legacy standalone SQL Server 2014 instance to a high...

Managing SQL Server day-to-day isn't just about setting it up, it’s about keeping it running smoothly: managing logins, scheduling jobs,...

SQL Server configuration used to mean a lot of clicking around in SSMS, memorizing registry tweaks, or juggling half a dozen scripts....