|
1 | 1 | --- |
2 | 2 | title: "sys.dm_hadr_availability_replica_states (Transact-SQL)" |
3 | | -description: sys.dm_hadr_availability_replica_states (Transact-SQL) |
| 3 | +description: Returns a row for each local replica and a row for each remote replica in the same Always On availability group as a local replica. |
4 | 4 | author: rwestMSFT |
5 | 5 | ms.author: randolphwest |
6 | | -ms.date: "02/27/2023" |
| 6 | +ms.date: 12/16/2025 |
7 | 7 | ms.service: sql |
8 | 8 | ms.subservice: system-objects |
9 | | -ms.topic: "reference" |
| 9 | +ms.topic: reference |
10 | 10 | f1_keywords: |
11 | | - - "dm_hadr_availability_replica_states" |
12 | 11 | - "sys.dm_hadr_availability_replica_states_TSQL" |
13 | 12 | - "sys.dm_hadr_availability_replica_states" |
14 | 13 | - "dm_hadr_availability_replica_states_TSQL" |
| 14 | + - "dm_hadr_availability_replica_states" |
15 | 15 | helpviewer_keywords: |
16 | 16 | - "Availability Groups [SQL Server], monitoring" |
17 | 17 | - "sys.dm_hadr_availability_replica_states dynamic management view" |
18 | 18 | dev_langs: |
19 | 19 | - "TSQL" |
20 | 20 | --- |
21 | 21 | # sys.dm_hadr_availability_replica_states (Transact-SQL) |
| 22 | + |
22 | 23 | [!INCLUDE [SQL Server](../../includes/applies-to-version/sqlserver.md)] |
23 | 24 |
|
24 | | - Returns a row for each local replica and a row for each remote replica in the same Always On availability group as a local replica. Each row contains information about the state of a given replica. |
25 | | - |
| 25 | +Returns a row for each local replica and a row for each remote replica in the same Always On availability group as a local replica. Each row contains information about the state of a given replica. |
| 26 | + |
26 | 27 | > [!IMPORTANT] |
27 | | -> To obtain information about every replica in a given availability group, query **sys.dm_hadr_availability_replica_states** on the server instance that is hosting the primary replica. When queried on a server instance that is hosting a secondary replica of an availability group, this dynamic management view returns only local information for the availability group. |
28 | | - |
29 | | -|Column name|Data type|Description| |
30 | | -|-----------------|---------------|-----------------| |
31 | | -|**replica_id**|**uniqueidentifier**|Unique identifier of the replica.| |
32 | | -|**group_id**|**uniqueidentifier**|Unique identifier of the availability group.| |
33 | | -|**is_local**|**bit**|Whether the replica is local, one of:<br /><br /> 0 = Indicates a remote secondary replica in an availability group whose primary replica is hosted by the local server instance. This value occurs only on the primary replica location.<br /><br /> 1 = Indicates a local replica. On secondary replicas, this is the only available value for the availability group to which the replica belongs.| |
34 | | -|**role**|**tinyint**|Current [!INCLUDE[ssHADR](../../includes/sshadr-md.md)] role of a local replica or a connected remote replica, one of:<br /><br /> 0 = Resolving<br /><br /> 1 = Primary<br /><br /> 2 = Secondary<br /><br /> For information about [!INCLUDE[ssHADR](../../includes/sshadr-md.md)] roles, see [Overview of Always On Availability Groups (SQL Server)](../../database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.md).| |
35 | | -|**role_desc**|**nvarchar(60)**|Description of **role**, one of:<br /><br /> RESOLVING<br /><br /> PRIMARY<br /><br /> SECONDARY| |
36 | | -|**operational_state**|**tinyint**|Current operational state of the replica, one of:<br /><br /> 0 = Pending failover<br /><br /> 1 = Pending<br /><br /> 2 = Online<br /><br /> 3 = Offline<br /><br /> 4 = Failed<br /><br /> 5 = Failed, no quorum<br /><br /> NULL = Replica is not local.<br /><br /> For more information, see [Roles and Operational States](#RolesAndOperationalStates), later in this topic.| |
37 | | -|**operational\_state\_desc**|**nvarchar(60)**|Description of **operational\_state**, one of:<br /><br /> PENDING_FAILOVER<br /><br /> PENDING<br /><br /> ONLINE<br /><br /> OFFLINE<br /><br /> FAILED<br /><br /> FAILED_NO_QUORUM<br /><br /> NULL| |
38 | | -|**recovery\_health**|**tinyint**|Rollup of the **database\_state** column of the [sys.dm_hadr_database_replica_states](../../relational-databases/system-dynamic-management-views/sys-dm-hadr-database-replica-states-transact-sql.md) dynamic management view. The following are the possible values and their descriptions.<br /><br /> 0 : In progress. At least one joined database has a database state other than ONLINE (**database\_state** is not 0).<br /><br /> 1 : Online. All the joined databases have a database state of ONLINE (**database_state** is 0).<br /><br /> NULL : **is_local** = 0| |
39 | | -|**recovery_health_desc**|**nvarchar(60)**|Description of **recovery_health**, one of:<br /><br /> ONLINE_IN_PROGRESS<br /><br /> ONLINE<br /><br /> NULL| |
40 | | -|**synchronization\_health**|**tinyint**|Reflects a rollup of the database synchronization state (**synchronization_state**)of all joined availability databases (also known as *replicas*) and the availability mode of the replica (synchronous-commit or asynchronous-commit mode). The rollup will reflect the least healthy accumulated state the databases on the replica. Below are the possible values and their descriptions.<br /><br /> 0 : Not healthy. At least one joined database is in the NOT SYNCHRONIZING state.<br /><br /> 1 : Partially healthy. Some replicas are not in the target synchronization state: synchronous-commit replicas should be synchronized, and asynchronous-commit replicas should be synchronizing.<br /><br /> 2 : Healthy. All replicas are in the target synchronization state: synchronous-commit replicas are synchronized, and asynchronous-commit replicas are synchronizing.| |
41 | | -|**synchronization_health_desc**|**nvarchar(60)**|Description of **synchronization_health**, one of:<br /><br /> NOT_HEALTHY<br /><br /> PARTIALLY_HEALTHY<br /><br /> HEALTHY| |
42 | | -|**connected_state**|**tinyint**|Whether a secondary replica is currently connected to the primary replica. The possible values are shown below with their descriptions.<br /><br /> 0 : Disconnected. The response of an availability replica to the DISCONNECTED state depends on its role: On the primary replica, if a secondary replica is disconnected, its secondary databases are marked as NOT SYNCHRONIZED on the primary replica, which waits for the secondary to reconnect; On a secondary replica, upon detecting that it is disconnected, the secondary replica attempts to reconnect to the primary replica.<br /><br /> 1 : Connected.<br /><br /> Each primary replica tracks the connection state for every secondary replica in the same availability group. Secondary replicas track the connection state of only the primary replica.| |
43 | | -|**connected_state_desc**|**nvarchar(60)**|Description of **connection_state**, one of:<br /><br /> DISCONNECTED<br /><br /> CONNECTED| |
44 | | -|**last_connect_error_number**|**int**|Number of the last connection error.| |
45 | | -|**last_connect_error_description**|**nvarchar(1024)**|Text of the **last_connect_error_number** message.| |
46 | | -|**last_connect_error_timestamp**|**datetime**|Date and time timestamp indicating when the **last_connect_error_number** error occurred.| |
47 | | - |
48 | | -## <a name="RolesAndOperationalStates"></a> Roles and Operational States |
49 | | - The role, **role**, reflects the state of a given availability replica and the operational state, **operational_state**, describes whether the replica is ready to process client requests for all the database of the availability replica. The following is a summary of the operational states that are possible for each role: RESOLVING, PRIMARY, and SECONDARY. |
50 | | - |
51 | | - **RESOLVING:** When an availability replica is in the RESOLVING role, the possible operational states are as shown in the following table. |
52 | | - |
53 | | -|Operational State|Description| |
54 | | -|-----------------------|-----------------| |
55 | | -|PENDING_FAILOVER|A failover command is being processed for the availability group.| |
56 | | -|OFFLINE|All configuration data for the availability replica has been updated on WSFC cluster and, also, in local metadata, but the availability group currently lacks a primary replica.| |
57 | | -|FAILED|A read failure has occurred during an attempt trying to retrieve information from the WSFC cluster.| |
58 | | -|FAILED_NO_QUORUM|The local WSFC node does not have quorum. This is an inferred state.| |
59 | | - |
60 | | - **PRIMARY:** When an availability replica is performing the PRIMARY role, it is currently the primary replica. The possible operational states are as shown in the following table. |
61 | | - |
62 | | -|Operational State|Description| |
63 | | -|-----------------------|-----------------| |
64 | | -|PENDING|This is a transient state, but a primary replica can be stuck in this state if workers are not available to process requests.| |
65 | | -|ONLINE|The availability group resource is online, and all database worker threads have been picked up.| |
66 | | -|FAILED|The availability replica is unable to read to and/or write from the WSFC cluster.| |
67 | | - |
68 | | - **SECONDARY:** When an availability replica is performing the SECONDARY role, it is currently a secondary replica. The possible operational states are as shown in the table below. |
69 | | - |
70 | | -|Operational State|Description| |
71 | | -|-----------------------|-----------------| |
72 | | -|ONLINE|The local secondary replica is connected to the primary replica.| |
73 | | -|FAILED|The local secondary replica is unable to read to and/or write from the WSFC cluster.| |
74 | | -|NULL|On a primary replica, this value is returned when the row relates to a secondary replica.| |
75 | | - |
76 | | -## Permissions |
77 | | - Requires VIEW SERVER STATE permission on the server. |
78 | | - |
79 | | -### Permissions for SQL Server 2022 and later |
80 | | - |
81 | | -Requires VIEW SERVER PERFORMANCE STATE permission on the server. |
82 | | - |
83 | | -## See also |
84 | | - [Overview of Always On Availability Groups (SQL Server)](../../database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.md) |
85 | | - [Monitor Availability Groups (Transact-SQL)](../../database-engine/availability-groups/windows/monitor-availability-groups-transact-sql.md) |
86 | | - |
87 | | - |
| 28 | +> To get information about every replica in a given availability group, query `sys.dm_hadr_availability_replica_states` on the server instance that hosts the primary replica. When you query this dynamic management view on a server instance that hosts a secondary replica of an availability group, it returns only local information for the availability group. |
| 29 | +
|
| 30 | +| Column name | Data type | Nullable | Description | |
| 31 | +| --- | --- | --- | --- | |
| 32 | +| `replica_id` | **uniqueidentifier** | No | Unique identifier of the replica. | |
| 33 | +| `group_id` | **uniqueidentifier** | No | Unique identifier of the availability group. | |
| 34 | +| `is_local` | **bit** | No | Whether the replica is local, one of:<br /><br />`0` = Indicates a remote secondary replica in an availability group whose primary replica is hosted by the local server instance. This value occurs only on the primary replica location.<br /><br />`1` = Indicates a local replica. On secondary replicas, this is the only available value for the availability group to which the replica belongs. | |
| 35 | +| `role` | **tinyint** | Yes | Current [!INCLUDE [ssHADR](../../includes/sshadr-md.md)] role of a local replica or a connected remote replica, one of:<br /><br />`0` = Resolving<br />`1` = Primary<br />`2` = Secondary<br /><br />For information about [!INCLUDE [ssHADR](../../includes/sshadr-md.md)] roles, see [What is an Always On availability group?](../../database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.md) | |
| 36 | +| `role_desc` | **nvarchar(60)** | Yes | Description of `role`, one of:<br /><br />`RESOLVING`<br />`PRIMARY`<br />`SECONDARY` | |
| 37 | +| `operational_state` | **tinyint** | Yes | Current operational state of the replica, one of:<br /><br />`0` = Pending failover<br />`1` = Pending<br />`2` = Online<br />`3` = Offline<br />`4` = Failed<br />`5` = Failed, no quorum<br />`NULL` = Replica isn't local.<br /><br />For more information, see [Roles and Operational States](#RolesAndOperationalStates), later in this article. | |
| 38 | +| `operational_state_desc` | **nvarchar(60)** | Yes | Description of `operational_state`, one of:<br /><br />`PENDING_FAILOVER`<br /><br />`PENDING`<br /><br />`ONLINE`<br /><br />`OFFLINE`<br /><br />`FAILED`<br /><br />`FAILED_NO_QUORUM`<br /><br />`NULL` | |
| 39 | +| `connected_state` | **tinyint** | Yes | Whether a secondary replica is currently connected to the primary replica. The possible values are shown below with their descriptions.<br /><br />`0` = Disconnected. The response of an availability replica to the `DISCONNECTED` state depends on its role: On the primary replica, if a secondary replica is disconnected, its secondary databases are marked as `NOT SYNCHRONIZED` on the primary replica, which waits for the secondary to reconnect; On a secondary replica, upon detecting that it's disconnected, the secondary replica attempts to reconnect to the primary replica.<br /><br />`1` = Connected.<br /><br />Each primary replica tracks the connection state for every secondary replica in the same availability group. Secondary replicas track the connection state of only the primary replica. | |
| 40 | +| `connected_state_desc` | **nvarchar(60)** | Yes | Description of `connection_state`, one of:<br /><br />`DISCONNECTED`<br />`CONNECTED` | |
| 41 | +| `recovery_health` | **tinyint** | Yes | Rollup of the `database_state` column of the [sys.dm_hadr_database_replica_states](sys-dm-hadr-database-replica-states-transact-sql.md) dynamic management view. The following are the possible values and their descriptions.<br /><br />`0` = In progress. At least one joined database has a database state other than `ONLINE` (`database_state` isn't `0`).<br /><br />`1` = Online. All the joined databases have a database state of `ONLINE` (`database_state` is `0`).<br /><br />`NULL`: `is_local` = `0` | |
| 42 | +| `recovery_health_desc` | **nvarchar(60)** | Yes | Description of `recovery_health`, one of:<br /><br />`ONLINE_IN_PROGRESS`<br />`ONLINE`<br />`NULL` | |
| 43 | +| `synchronization_health` | **tinyint** | Yes | Reflects a rollup of the database synchronization state (`synchronization_state`) of all joined availability databases (also known as *replicas*) and the availability mode of the replica (synchronous-commit or asynchronous-commit mode). The rollup will reflect the least healthy accumulated state the databases on the replica. Below are the possible values and their descriptions.<br /><br />`0` = Not healthy. At least one joined database is in the `NOT SYNCHRONIZING` state.<br /><br />`1` = Partially healthy. Some replicas aren't in the target synchronization state: synchronous-commit replicas should be synchronized, and asynchronous-commit replicas should be synchronizing.<br /><br />`2` = Healthy. All replicas are in the target synchronization state: synchronous-commit replicas are synchronized, and asynchronous-commit replicas are synchronizing. | |
| 44 | +| `synchronization_health_desc` | **nvarchar(60)** | Yes | Description of `synchronization_health`, one of:<br /><br />`NOT_HEALTHY`<br />`PARTIALLY_HEALTHY`<br />`HEALTHY` | |
| 45 | +| `last_connect_error_number` | **int** | Yes | Number of the last connection error. | |
| 46 | +| `last_connect_error_description` | **nvarchar(1024)** | Yes | Text of the `last_connect_error_number` message. | |
| 47 | +| `last_connect_error_timestamp` | **datetime** | Yes | Date and time timestamp indicating when the `last_connect_error_number` error occurred. | |
| 48 | +| `write_lease_remaining_ticks` | **bigint** | Yes | [!INCLUDE [ssinternalonly-md](../../includes/ssinternalonly-md.md)] | |
| 49 | +| `current_configuration_commit_start_time_utc` | **datetime** | Yes | [!INCLUDE [ssinternalonly-md](../../includes/ssinternalonly-md.md)] | |
| 50 | +| `is_internal` | **bit** | Yes | [!INCLUDE [ssinternalonly-md](../../includes/ssinternalonly-md.md)] | |
| 51 | +| `operational_state_desc` | **nvarchar(60)** | Yes | Description of `operational_state`, one of:<br /><br />`PENDING_FAILOVER`<br />`PENDING`<br />`ONLINE`<br />`OFFLINE`<br />`FAILED`<br />`FAILED_NO_QUORUM`<br />`NULL` | |
| 52 | +| `recovery_health` | **tinyint** | Yes | Rollup of the `database_state` column of the [sys.dm_hadr_database_replica_states](sys-dm-hadr-database-replica-states-transact-sql.md) dynamic management view. The following are the possible values and their descriptions.<br /><br />`0` = In progress. At least one joined database has a database state other than `ONLINE` (`database_state` isn't `0`).<br /><br />`1` = Online. All the joined databases have a database state of `ONLINE` (`database_state` is `0`).<br /><br />`NULL`: `is_local` isn't `0` | |
| 53 | +| `synchronization_health` | **tinyint** | No | Reflects a rollup of the database synchronization state (`synchronization_state`) of all joined availability databases (also known as *replicas*) and the availability mode of the replica (synchronous-commit or asynchronous-commit mode). The rollup reflects the least healthy accumulated state the databases on the replica. The possible values and their descriptions are:<br /><br />`0` = Not healthy. At least one joined database is in the `NOT SYNCHRONIZING` state.<br /><br />`1` = Partially healthy. Some replicas aren't in the target synchronization state: synchronous-commit replicas should be synchronized, and asynchronous-commit replicas should be synchronizing.<br /><br />`2` = Healthy. All replicas are in the target synchronization state: synchronous-commit replicas are synchronized, and asynchronous-commit replicas are synchronizing. | |
| 54 | + |
| 55 | +<a id="RolesAndOperationalStates"></a> |
| 56 | + |
| 57 | +## Roles and operational states |
| 58 | + |
| 59 | +The role, `role`, reflects the state of a given availability replica. The operational state, `operational_state`, describes whether the replica is ready to process client requests for all the databases of the availability replica. The following table summarizes the operational states that are possible for each role: `RESOLVING`, `PRIMARY`, and `SECONDARY`. |
| 60 | + |
| 61 | +`RESOLVING`: When an availability replica is in the `RESOLVING` role, the possible operational states are as shown in the following table. |
| 62 | + |
| 63 | +| Operational state | Description | |
| 64 | +| --- | --- | |
| 65 | +| `PENDING_FAILOVER` | The system is processing a failover command for the availability group. | |
| 66 | +| `OFFLINE` | All configuration data for the availability replica is updated on WSFC cluster and, also, in local metadata, but the availability group currently lacks a primary replica. | |
| 67 | +| `FAILED` | A read failure occurred during an attempt to retrieve information from the WSFC cluster. | |
| 68 | +| `FAILED_NO_QUORUM` | The local WSFC node doesn't have quorum. This state is inferred. | |
| 69 | + |
| 70 | +`PRIMARY`: When an availability replica performs the `PRIMARY` role, it's currently the primary replica. The possible operational states are as shown in the following table. |
| 71 | + |
| 72 | +| Operational state | Description | |
| 73 | +| --- | --- | |
| 74 | +| `PENDING` | This state is transient, but a primary replica can be stuck in this state if workers aren't available to process requests. | |
| 75 | +| `ONLINE` | The availability group resource is online, and all database worker threads have been picked up. | |
| 76 | +| `FAILED` | The availability replica can't read to or write from the WSFC cluster. | |
| 77 | + |
| 78 | +`SECONDARY`: When an availability replica performs the `SECONDARY` role, it's currently a secondary replica. The possible operational states are as shown in the table below. |
| 79 | + |
| 80 | +| Operational state | Description | |
| 81 | +| --- | --- | |
| 82 | +| `ONLINE` | The local secondary replica is connected to the primary replica. | |
| 83 | +| `FAILED` | The local secondary replica can't read to or write from the WSFC cluster. | |
| 84 | +| `NULL` | On a primary replica, this value is returned when the row relates to a secondary replica. | |
| 85 | + |
| 86 | +## Permissions |
| 87 | + |
| 88 | +[!INCLUDE [sssql19-md](../../includes/sssql19-md.md)] and earlier versions require `VIEW SERVER STATE` permission on the server. |
| 89 | + |
| 90 | +[!INCLUDE [sssql22-md](../../includes/sssql22-md.md)] and later versions require `VIEW SERVER PERFORMANCE STATE` permission on the server. |
| 91 | + |
| 92 | +## Related content |
| 93 | + |
| 94 | +- [What is an Always On availability group?](../../database-engine/availability-groups/windows/overview-of-always-on-availability-groups-sql-server.md) |
| 95 | +- [Monitor Availability Groups (Transact-SQL)](../../database-engine/availability-groups/windows/monitor-availability-groups-transact-sql.md) |
0 commit comments