Press "Enter" to skip to content

Category: Availability Groups

Extending Index Information across Availability Group Replicas

Published 2025-10-08 by Kevin Feasel

Aaron Bertrand extends a prior article:

In my previous tip, Managing Unused Indexes in SQL Server Availability Groups – Part 1, I showed how I use dynamic SQL to gather index usage statistics for a given table from all replicas in an availability group. Knowing the usage from all workloads is definitely better than focusing on only the primary or a single secondary. But what if I want to make more informed decisions, incorporating row counts, size, and index columns into this output?

Read on to see how you can incorporate this additional information.

Leave a Comment

Accounting for Index Usage over Availability Groups

Published 2025-10-06 by Kevin Feasel

Aaron Bertrand wants a cross-replica accounting system:

As a part of optimizing performance, I evaluate index usage across many instances and databases. I often find that some indexes aren’t used much or, at least on first glance, appear to go unused. Since we use availability groups (AG), different workloads run against replicas in different roles. All writes happen on the primary, obviously. However, some queries only happen on read-only secondaries (either because read-only routing is in use, or because some processes are manually directed at specific secondaries, or both). Unfortunately, index usage is not rolled up anywhere across all replicas. This means that looking at the primary alone gives an incomplete picture. How do I make sure I account for index activity everywhere, not just on the primary?

This is part one of a series but already has enough to get us started.

Leave a Comment

Measuring Delay in Availability Groups

Published 2025-07-28 by Kevin Feasel

Matt Gantz wants to see how far behind we are:

Availability Groups are useful for creating Highly Available (HA) database systems, but that doesn’t mean they are entirely immune to performance problems. In busy systems, limitations in the infrastructure can introduce replication lag that is severe enough to affect database performance in ways that aren’t immediately obvious.

In SQL Server Availability Groups, the relevant difference between synchronous and asynchronous replicas comes down to how and when a transaction on the primary server is considered “committed”: Although it is easy to measure the lag between asynchronous replicas by using the dashboard in SSMS or by querying the DMVs (Dynamic Management Views), it takes more work to find the latency between synchronous replicas. This article explains how to measure that latency using internal performance counters, offering a simple technique for monitoring the cost of synchronous replication.

Click through to read the whole thing.

Comments closed

When All AG Nodes are Secondaries

Published 2025-06-09 by Kevin Feasel

Randy Knight demands quorum:

If you’ve encountered a situation where none of your SQL Server Always On Availability Group (AG) replicas become PRIMARY after a cluster failure — you’re not alone.  We recently had a customer with this exact scenario (AG won’t become primary after force quorum), and it is both uncommon and difficult to troubleshoot so I thought it would be worth posting about.

Click through for the scenario, what’s happening, and how to resolve this.

Comments closed

A New Dashboard for Distributed Availability Groups

Published 2025-04-02 by Kevin Feasel

David Fowler has been busy:

This comes off of the back of my last post looking at using a distributed availability group (DAG) to help facilitate a SQL server migration. SQL Server Migration Using a Distributed Availability Group

One thing that I mentioned in that post was that, although SSMS gives us a nice dashboard to check the health of our regular AGs. There’s nothing there to look at the state that the DAGs are in. The only choice that we’ve got is to tap up and compare results from a couple of DMVs on each side.

David has met that demand. Read on to see what the solution includes and how you can get your hands on it.

Comments closed

Seeding an Availability Group via T-SQL Snapshot Backup

Published 2025-02-28 by Kevin Feasel

Anthony Nocentino jump-starts an availability group:

In this post, the fifth in our series, I want to illustrate an example of using the T-SQL Snapshot Backup feature in SQL Server 2022 to seed Availability Groups (AGs) with storage-based snapshots. Efficiently seeding an Availability Group is essential for maintaining high availability and ensuring effective disaster recovery. With the introduction of T-SQL Snapshot Backup in SQL Server 2022, snapshots can now be created at the storage layer. This advancement significantly speeds up the initialization of secondary replicas, particularly in environments that handle large databases.

This post will walk through a PowerShell script that effectively seeds an AG using T-SQL Snapshot Backup, dbatools, and Pure Storage FlashArray.

Click through for the script and the process.

Comments closed

SQL Server Availability Groups in Docker Containers

Published 2025-02-06 by Kevin Feasel

Yvonne Vanslageren builds a high availability solution for containerized SQL Server instances:

For enterprise SQL Server DBAs, high availability is essential for maintaining seamless database operations—particularly in scenarios involving Change Data Capture (CDC) or other mission-critical functionalities. Docker containers can streamline the setup and management of development or testing environments for Always On Availability Groups (AOAG). By bundling configuration files, scripts, and dependencies into containers, teams gain a reproducible, portable, and efficient deployment mechanism.

This guide explains how to build an Always On environment inside Docker containers using Docker Desktop, Docker Compose, and a series of setup scripts. It walks through the creation of two containers (primary and secondary) configured in a clusterless Always On Availability Group scenario.

Click through for the process.

Comments closed

SQL Server Migration via Distributed AG

Published 2025-02-06 by Kevin Feasel

David Fowler makes a move:

Because it doesn’t require a common cluster, a distributed availability group allows us to link servers in situations were a cluster isn’t possible. Servers could be in remote locations, members or different domains, different OS levels or even different operating systems (yes, we can link Windows and Linux based AGs).

The ability to link servers in this way gives us a very nice and easy way to replicate data between servers when thinking about a migration.

David’s scenario involves a SQL Server upgrade. I’ve seen this work really well in practice for a 2017 to 2019 upgrade. With applications pointing to the listener agent and everything in place, you can have as little as a few seconds of downtime for that upgrade, which is amazing when you think about how we’ve historically migrated to new versions of SQL Server.

Comments closed

Always On Lease Timeout Monitoring

Published 2025-01-10 by Kevin Feasel

Yvonne Vanslageren gives us one more thing to check:

SQL Server Always On Availability Groups are a robust solution for achieving high availability and disaster recovery for SQL Server databases. However, simply configuring them is not enough—you also need a solid monitoring strategy to ensure data integrity and system reliability. One key aspect of this monitoring process is keeping an eye on lease timeouts, which can signal larger issues and help prevent potentially catastrophic split-brain scenarios.

In this post, we’ll walk through the various health checks available for Always On Availability Groups, discuss how lease timeouts work, and explore practical methods for monitoring and troubleshooting.

Read on to learn more about the lease timeout concept, as well as where you can get this information and further recommendations around how to deal with the information.

Comments closed

Setting RCSI on a Database in an Availability Group

Published 2025-01-07 by Kevin Feasel

Haripriya Naidu makes a change:

I was working on modifying isolation level of database from Read Committed to Read Committed Snapshot(RCSI) and had to get exclusive access to the database. After letting the application team know about it and having stopped their processes, I tried to set the database to SINGLE_USER but it errored out.

It turns out that you cannot set a database to single user mode if it is in an availability group or part of database mirroring. Nonetheless, there is still a way to make this change. Read on to learn more.

Comments closed