How to register and monitor SQL Server Availability Groups in DPA

7/21/2026 3:29 PM

7/21/2026 3:29 PM

Before you begin

Before registering SQL Server instances or an AG listener in DPA, confirm the following:

• The SQL Server AG deployment is a supported configuration. DPA does not support monitoring distributed AGs (DAGs), Distributed Network Name (DNN) for AGs, or SQL Server multi-subnet failover clusters / MultiSubnetFailover for AGs.

• For DPA to collect metrics from a monitored SQL Server instance, the SQL option NUMERIC_ROUNDABOUT must be set to OFF.

• If you plan to register an AG listener, create the DPA login on every SQL Server instance in the cluster that can become the primary replica for that AG.

For general SQL Server registration guidance, see Register a SQL Server database instance.

Supported ways to register SQL Server AGs in DPA

DPA supports two approaches:

• Register each SQL Server instance in the cluster.

• Register the AG listener.

The right choice depends on whether you want to monitor all node activity or primarily track whichever instance currently owns the AG primary replica.

Database Performance Analyzer

Option 1: Register each SQL Server instance in the cluster

This is the recommended option when multiple AGs exist in the cluster, because it helps prevent DPA from monitoring the same instance more than once.

When you register each instance:

• DPA monitors all activity on each SQL Server instance, including primary and secondary AG activity.

• DPA does not follow AGs automatically during failover, because each node is monitored as its own registered instance.

• Monitoring all instances ensures you still see activity when AG failovers occur.

Use this option when

• You want visibility into both primary and secondary replicas.

• The cluster contains multiple AGs.

• You want to avoid duplicate monitoring caused by multiple listeners resolving to the same primary replica.

Important limitation for read-intent only secondaries

If you register each SQL Server instance directly, the following Availability Group configuration is not supported:

• Connections in primary role: Allow read/write connections

• Readable secondary: Read-intent only

In that scenario, DPA can connect only part of the time:

• If the required connection property is set, DPA can connect only when the instance is in the secondary role.

• If the property is not set, DPA can connect only when the instance is in the primary role.

Option 2: Register the AG listener

Register the AG listener if your main goal is to monitor the SQL Server instance that currently hosts the AG primary replica.

When you register the listener:

• DPA follows the listener when the AG fails over.

• After failover, DPA begins monitoring the SQL Server instance that becomes the new primary replica.

• DPA automatically names the registered AG instance using this format: <PrimaryReplicaName> via <ListenerName>.

• After failover, the displayed name is automatically updated to reflect the new primary replica.

• If you manually rename an AG that is registered through the listener, DPA overwrites that name each time the monitor starts unless the advanced Support option AG_INSTANCE_NAME_UPDATE_ENABLED is changed.

Use this option when

• You primarily care about the active primary replica.

• You want monitoring to move with the AG during failover.

• You can ensure the cluster design will not cause duplicate monitoring.

Important listener considerations

• SolarWinds recommends registering only one listener per cluster unless you can ensure that no SQL Server instance will act as the primary replica for multiple AGs.

• If you register multiple listeners and the same SQL Server instance becomes the primary replica for more than one AG, DPA can monitor that instance multiple times.

• SQL Server logins are not replicated automatically. To preserve monitoring after failover, manually create the DPA login on all instances that can become the primary replica.

• If the AG uses Read-intent only for readable secondaries, register each instance instead of registering the listener.

What happens during failover

DPA behavior during failover depends on how the AG was registered.

If you registered each instance directly

• DPA continues monitoring the individual SQL Server instances already registered in DPA.

• If DPA is monitoring both instances involved in the failover, DPA sends an alert for each monitored instance involved.

• If DPA is monitoring only one of the instances involved, it sends only one failover alert.

• DPA also creates an annotation for each monitored instance involved in the failover.

If you registered the AG through the listener

• DPA follows the listener to the new primary replica.

• DPA sends one failover alert for the AG associated with that listener.

• DPA adds one failover annotation for the AG associated with that listener.

• DPA updates the AG display name automatically to reflect the new primary replica.

AG status behavior in DPA

DPA provides AG status information, annotations, and alerts for monitored SQL Server AGs.

• On the DPA home page, AG status icons identify database instances that include AGs.

• If DPA is monitoring an instance directly and the instance acts as a secondary replica for all AGs, the AG status typically appears as Unknown.

• If DPA is also monitoring one or more AGs where that same instance acts as the primary replica, the Unknown status from secondary-only AGs is ignored and DPA shows the worst status among the AGs where the instance is primary.

• If the instance is monitored via the listener, DPA uses the aggregate status by default. If needed, the advanced Support option AG_STATUS_ROLLUP_USE_PRIMARY can be changed to use only the AG associated with the listener.

Unsupported configurations

At this time, DPA does not support the following for SQL Server AG monitoring:

• Distributed Availability Groups (DAGs). DPA can still monitor the participating SQL Server instances, but AG-specific monitoring features are not enabled for DAGs.

• Distributed Network Name (DNN) for AGs.

• MultiSubnetFailover for AGs / SQL Server multi-subnet failover clusters.

Recommended decision guide

Use the following guidance to decide how to register a SQL Server AG:

• Register each instance in the cluster if you want full node-level visibility, have multiple AGs, or want to avoid duplicate monitoring.

• Register the AG listener if you want DPA to follow the active primary replica during failover.

• Do not register the listener when readable secondaries are configured as Read-intent only; register each instance instead.

Troubleshooting tips

If AG monitoring does not behave as expected:

• Verify whether you registered the individual instances or the AG listener.

• Confirm the DPA monitoring login exists on every SQL Server instance that can become the primary replica.

• Review whether the AG uses unsupported configurations such as DAGs, DNN, or multi-subnet failover.

• Check whether readable secondaries are configured with Read-intent only, which changes the supported registration method.

• Confirm NUMERIC_ROUNDABOUT is set to OFF.

• If a listener-based AG name keeps changing back after you rename it, review the advanced Support option AG_INSTANCE_NAME_UPDATE_ENABLED.