Press "Enter" to skip to content

Category: Administration

Lessons Learned from Change Data Capture

Deborah Melkin shares some lessons from working with Change Data Capture:

This has definitely been something that is I’ve had some experience with recently. It inspired my “Change Tracking in SQL Server 2025: Exploring Change Event Streaming vs CDC” session that I presented at SQLCON 26. We had been having problems troubleshooting various issues around Change Data Capture (CDC) and someone suggested that I take look at Change Event Streaming, which is new for SQL Server 2025. One of the great things about putting together sessions like this is that I was able to create a very simple POC to understand it all works. It was also helpful for me to understand some key takeaways with both of these.

The Change Event Streaming lessons are fairly limited (for good reason) but Deb shares some nice tips on working with CDC.

Leave a Comment

Tips for Disaster Response

Christophe Pettus shares some advice:

  • Wind your watch.

No one has a watch that winds anymore, but the point is: take a deep breath. Give yourself a minute, or two, or five to gather data. A too-fast response is the main way a problem becomes a disaster.

Click through for all seven of them. I fully agree with doing drills. If you don’t practice in the easy times, you probably won’t respond well in the harder times. Also, I recommend having the process written down on a one-pager that everyone has a copy of. This should include the most important details around emergency response: how to escalate, what information to start capturing early on, etc.

Leave a Comment

Moving System Databases in SQL Server

Rich Benner hires some movers:

As consultants, we often see system databases existing on the C drive on SQL Servers. There are some issues with this setup, and the biggest is: if one of your system databases grows and fills your C drive, you will likely crash the OS. If that happens, we’re in big trouble. Therefore, moving system databases becomes a necessary operation at times.

This is such a common issue because the default locations are set to C for these databases and that’s where they end up on fresh installs 99% of the time. Don’t worry! If you’re in this situation you’re not alone.

Click through for a query that shows which databases are on which drive and how to migrate databases post-install.

Leave a Comment

A Primer on Group Managed Service Accounts

Randy Knight shows off a useful feature in Windows:

Service account management is one of the quietest ways a SQL Server estate goes wrong. Passwords get set once during install, written down somewhere (or worse, not written down), and then never rotated. The DBA who built the environment leaves. A security audit shows up. Suddenly you’re staring at a hundred service account passwords nobody remembers, and the prospect of changing them all on a maintenance window nobody wants to schedule. Group Managed Service Accounts (gMSAs) solve this.

They’ve been a fully supported option for SQL Server since 2014, they work with Failover Cluster Instances and Availability Groups, and Active Directory rotates the passwords for you on a schedule you control. We use them by default on every new SQL Server build at SSG.

And yet, in a decade of Health Checks, we still rarely see them deployed. The most common reasons we hear: “I tried it once and SPNs broke,” or, “I wasn’t sure it would work with our AG.” Both are addressable. Here’s what you need to know to deploy gMSAs successfully.

gMSAs are very useful at providing a managed identity for on-premises solutions. You don’t need to save passwords anywhere but still have full control over who’s allowed to access a given resource.

Leave a Comment

Alerting on Long-Running SQL Queries and SQL Agent Jobs

Temidayo Omoniyi sends an e-mail:

Have you ever waited for an eternity, waiting for either a query or SQL Agent Jobs to run? This is something most Data Warehouse Developers face daily.

Click through to see how you can use database mail to track long-running tasks. My primary hang-up with solutions like this is, what are you going to do about the e-mail? If there is no concrete action you can take, the most likely outcome will be to ignore the e-mail. This makes it harder to sift out the true positive you need to look into versus the false positives that happen every day.

Leave a Comment

Time Delay for Online Checksums in PostgreSQL

Cristophe Pettus notes an upcoming change to PostgreSQL 19:

For about fifteen years the answer to “can I turn on data checksums without an initdb?” has been “not really.” pg_checksums showed up in PostgreSQL 12 and made the job survivable, but you still had to shut the cluster down. For anyone running 24×7 production, that has left the same three options: take the downtime, fail over through a checksummed replica, or live without checksums.

PostgreSQL 19 adds a fourth path. A commit from Daniel Gustafsson on April 3rd wires up online enabling and disabling of data checksums: the command completes immediately, and the cluster keeps serving traffic while a background process rewrites every heap and index page in the cluster to carry (or drop) the checksum.

Read on to see what it will do, as well as the consequences.

Leave a Comment

Unplanned Failover and SQL Server on Kubernetes

Anthony Nocentino performs additional testing:

In my planned failover walkthrough, I showed what happens when you deliberately move the primary role to another replica. That’s the easy case. Now I want to show what happens when the primary pod just disappears unexpectedly, like during a node failure or a container crash. No graceful shutdown, no demotion, just gone.

I ran two test scenarios, each cycling the primary role across all three pods by force-deleting the current primary three times in a row. First, a 5GB TPC-C database idle. Then, that same 5GB database under sustained HammerDB TPC-C load. Six force-deletes total, six successful automatic failovers. I’ll walk through the error log from the promoted replica, the operator’s detection and recovery behavior, and the full timing data.

Read on to see how Anthony’s SQL Server Kubernetes operator handles when things go bump in the night.

Leave a Comment

Using the Dedicated Admin Connection in SQL Server

Garry Bargsley forces down the door:

It’s 2 AM. Your phone is going off. Users can’t connect to the application, and when you open SSMS to investigate, the connection spinner just keeps spinning. SQL Server is alive; you can see the process running, but it’s too overwhelmed to let you in. You need to get in there and kill something, but you can’t get a connection to do it. This is exactly the scenario the Dedicated Admin Connection DAC was built for. And if you haven’t set it up yet, now is the time. Because when you need it, you really need it.

Because there is a preparatory step, it’s important to run that while the instance is in a healthy state. That way, it’ll be available to you when the instance is at the edge of failure.

Comments closed

Syncing Logins across Failover Groups for Managed Instances

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 master database. 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.

Comments closed