SQL Server Error 983

Error number

983

Severity

14 (user-correctable error)

State

1

Product

Microsoft SQL Server Database Engine

Versions

SQL Server 2016 to 2025 with Always On availability groups

Category

High Availability

Last reviewed

24 October 2026

What it means

Error 983 means the availability group replica you reached is in the RESOLVING role, typically during a failover or a health event, so none of its availability databases can be used until it becomes primary or secondary again.

A replica can use its availability databases only as PRIMARY (read and write) or SECONDARY (read if allowed). When Always On or the Windows Server Failover Cluster detects a health problem, the replica and its databases move to the RESOLVING role and the databases go offline until the availability group comes online again on this or the partner replica. Any connection or USE during that window gets 983 at level 14. The name in quotes is the database.

Microsoft notes that the resolving period during a normal failover usually lasts a few seconds or less, so a retry often succeeds. If 983 persists, the group cannot settle on a primary: typically the cluster has lost quorum, the automatic failover partner is not synchronised, the failover limit for the period was reached, or the SQL Server service on the primary is not healthy.

Common causes

• A failover is in progress (automatic after a health event, or manual), and the connection arrived during the short resolving window.
• The Windows Server Failover Cluster lost quorum, so the availability group role cannot come online on any node.
• An automatic failover could not complete, for example because the partner replica was not synchronised or the cluster failover limit was reached, leaving the replicas resolving.
• A lease timeout or health check timeout on the primary (high CPU, memory pressure, a memory dump being written) took the group offline.

Diagnose it

Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.

SELECT ag.name AS ag_name, ar.replica_server_name, rs.role_desc, rs.operational_state_desc,
       rs.connected_state_desc, rs.recovery_health_desc, rs.synchronization_health_desc
FROM sys.availability_replicas AS ar
JOIN sys.availability_groups AS ag ON ag.group_id = ar.group_id
LEFT JOIN sys.dm_hadr_availability_replica_states AS rs ON rs.replica_id = ar.replica_id;

SELECT cluster_name, quorum_type_desc, quorum_state_desc
FROM sys.dm_hadr_cluster;

SELECT member_name, member_type_desc, member_state_desc, number_of_quorum_votes
FROM sys.dm_hadr_cluster_members;

SELECT DB_NAME(drs.database_id) AS database_name, ar.replica_server_name, ar.failover_mode_desc,
       drs.synchronization_state_desc, drs.database_state_desc, drs.is_suspended
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

Server=tcp:SalesAgListener,1433;Database=SalesDb;Integrated Security=true;MultiSubnetFailover=True;ConnectRetryCount=3;ConnectRetryInterval=10

ALTER AVAILABILITY GROUP SalesAg FORCE_FAILOVER_ALLOW_DATA_LOSS;

Examples

Using a database while the replica is resolving

Shown as documented by Microsoft; not reproduced here because it needs an availability group during a failover or health event. Microsoft documents state 1 for the error log entry; the query window form was not observed, so no header is shown.

-- Connected to SQL01 while the availability group is failing over
USE SalesDb;

Unable to access availability database 'SalesDb' because the database replica is not in the PRIMARY or SECONDARY role. Connections to an availability database is permitted only when the database replica is in the PRIMARY or SECONDARY role. Try the operation again later.

How to prevent it

Make applications resilient to short failovers: connect through the listener, use MultiSubnetFailover=True and retry on transient errors. Design the cluster quorum (witness, votes) so that losing one node or one site does not take the whole group offline, and alert on replica role changes and on NO_QUORUM.

Keep automatic failover partners synchronised and watch for lease and health check timeouts, which usually come from resource pressure on the primary.

Common questions

Learn more on CodeWithSQL

• RDS Multi-AZ and read replicas

Official documentation

• Troubleshoot failover of Always On availability groups
• WSFC quorum modes and voting configuration
• Perform a forced manual failover of an availability group
• sys.dm_hadr_cluster (Transact-SQL)

Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.