A Fine Slice Of SQL Server
Andy Brownsword gets replicating:
Failover Groups for Managed Instances are a great option to replicate data, but they don’t replicate key instance elements – one of which is logins that live in the
masterdatabase. If left unchecked, failovers leave systems unable to connect and panic ensues.To alleviate this we’ll look at a script to synchronise logins and permissions across replicas.
Click through for a link to the script and an explanation of what’s going on with it.
Leave a CommentJohn Deardurff explains how to make a choice:
Recently while discussing the Task Execution Model and Thread Scheduling, I was asked the following question, “When discussing worker threads, how can we determine whether we should increase CPU capacity or focus on query tuning? This is when our worker threads are under pressure and the instance is becoming exhausted?“
In my brain, I thought, that is a great question, and it’s exactly the right way to think about worker thread pressure vs. real CPU starvation, especially when worker threads are getting tight. Let’s write a post.
John has a nice discussion of the trade-offs and signals associated with each approach. One third approach I might add is caching in the application(s), if applicable. This is especially useful if a significant fraction of the queries access static or nearly-static data.
Leave a CommentShaun Thomas talks checkpoints:
Every database has to reconcile two uncomfortable truths: memory is fast but volatile, and disk is slow but durable. Postgres handles this tension through its Write-Ahead Log (WAL), which records every change before it happens. But the WAL can’t grow forever. At some point, Postgres needs to flush all those accumulated dirty pages to disk and declare a clean starting point. That process is called a checkpoint, and when it goes wrong, it can bring throughput to its knees.
One thing I would note is that direct-attached nVME storage is approximately 1 order of magnitude slower than RAM. Yeah, that’s still a lot slower, but the gap has closed significantly. If you have PCIe 5 nVME drives (call that 12-14 GB/sec) and relatively slow RAM (20 GB/sec), it’s getting close to on par. But once you move past the top-of-the-line for disk speed, you add more orders of magnitude and everything Shaun describes becomes a problem again.
Jeremy Schneider offers a follow-up involving autovacuum_cost_delay:
A few days ago, Shaun Thomas published an article over on the pgEdge blog called [Checkpoints, Write Storms, and You]. Sadly a lot of corporate blogs don’t have comment functionality anymore. I left a few comments [on LinkedIn], but overall let me say this article is a great read, and I’m always happy to see someone dive into an important and overlooked topic, present a good technical description, and include real test results to illustrate the details.
I don’t have any reproducible real test results today. But I have a good story and a little real data.
Check out both of those articles.
Leave a CommentRebecca Lewis looks into a feature:
Two weeks ago I covered the Resource Governor changes in SQL Server 2025 — specifically, capping how much tempdb data space a workload group can consume. That was the data-file side. For the log side, SQL Server 2025 now lets you enable Accelerated Database Recovery (ADR) on tempdb. Enable it and cancelled queries stop grinding, the tempdb log stops bloating, and recovery gets faster. Sounds like an easy yes — but you’ve got to read the fine print.
Click through for that fine print.
Leave a CommentReitse Eskens suffers the consequences in this Highlander world:
Last week, we ran into an issue where deployment pipelines are owned by a person who no longer works for our organisation. This meant we could not access the deployment pipelines owned by this account.
Click through to see how to do this, including the code necessary.
Leave a CommentJeremy Kadlec puts together a list:
What are the SQL Server DBCC commands? Why should SQL Server DBAs be familiar with these commands? How do you interpret the output from DBCC commands?
Click through for some Q&A format and a lot of links to additional tips.
Leave a CommentJeff Iannucci has some updates:
This month though there are mostly a few small updates for the tools, as next month’s updates should also include many of the issues noted in GitHub (thanks for those!) Most of this month’s updates were to sp_CheckSecurity, although we did add “Initial File Size” to the output of sp_CheckTempdb since that had been requested by a few folks.
We hope these new updates can help you, especially if you’ve never used these stored procedures. Here are the updates for March 2026, with links to the GitHub repositories where you can download the latest versions.
Click through for those links.
Leave a CommentAfter receiving the alert, I verified that there were multiple databases on the same instance that were in the “Recovery Pending” state. A review of the SQL Server error log showed that the folder on the L drive was inaccessible, so transaction log files could not be read.
Click through for the troubleshooting steps leading to a happy ending.
Leave a CommentPankaj Arora has a new ‘give us money’ lever:
Capacity overage, is a new opt‑in capability in Microsoft Fabric designed to help organizations keep their workloads running—even during unexpected compute spikes. Now available in preview, this feature allows for automatic billing for excess capacity usage, based on limits you set, instead of throttling operations, ensuring smoother experiences when workloads exceed the limits of your purchased capacity.
I will say that I think it’s reasonable to have the two options of throttling (you went over by 30%, so for a stretch of time you’ll be capped until you get back under the limit) or simply paying. The controversy around this was mostly in the fact that, if you shut off and restart your Fabric capacity, you’d automatically be charged for the overages you created. To that end, providing more options on how to work off that overage debt is useful.
Leave a CommentLately, I’ve been feeling like we’re not paying as much attention to transaction logs as we should. In fact, I’ve been saying there needs to be a flashing neon sign that says “Transaction Logs are more important than ever.” I thought I’d take a minute and explain why.
Click through for some important functionality that makes heavy use of the transaction log, Deb also has a call to action on how to keep them going.
Leave a Comment