sys.dm_hadr_database_replica_states (Transact-SQL)
S’applique à : 
SQL Server Azure SQL Managed Instance
Retourne une ligne pour chaque base de données qui participe à un groupe de disponibilité Always On pour lequel l'instance locale de SQL Server héberge un réplica de disponibilité. Cette vue de gestion dynamique expose les informations d'état sur les réplicas principaux et secondaires. Sur un réplica secondaire, cette vue retourne une ligne pour chaque base de données secondaire sur l'instance de serveur. Sur le réplica principal, cette vue retourne une ligne pour chaque base de données primaire et une ligne supplémentaire pour la base de données secondaire correspondante.
Important
En fonction de l’action et des états de niveau supérieur, les informations d’état de base de données peuvent être indisponibles ou obsolètes. En outre, les valeurs ont uniquement une pertinence locale. Par exemple, sur le réplica principal, la valeur de la last_hardened_lsn colonne reflète les informations relatives à une base de données secondaire donnée actuellement disponible pour le réplica principal, et non le numéro de séquence de journal renforcé réel (LSN) que le réplica secondaire peut avoir actuellement.
| Nom de la colonne | Type de données | Description (sur le réplica principal) |
|---|---|---|
database_id |
int | Identificateur de la base de données, unique dans une instance de SQL Server. Il s’agit de la même valeur que celle affichée dans la vue catalogue sys.databases . |
group_id |
uniqueidentifier | Identificateur du groupe de disponibilité auquel la base de données appartient. |
replica_id |
uniqueidentifier | Identificateur du réplica de disponibilité dans le groupe de disponibilité. |
group_database_id |
uniqueidentifier | Identificateur de la base de données dans le groupe de disponibilité. Cet identificateur est identique sur chaque réplica auquel cette base de données est attachée. |
is_local |
bit | Si la base de données de disponibilité est locale, une des valeurs suivantes :0 = La base de données n’est pas locale à l’instance SQL Server.1 = La base de données est locale à l’instance du serveur. |
is_primary_replica |
bit | Retourne 1 si le réplica est principal ou 0 s’il s’agit d’un réplica secondaire.S’applique à : SQL Server 2014 (12.x) et versions ultérieures. |
synchronization_state |
tinyint | État de déplacement des données, l’une des valeurs suivantes.0 = Pas de synchronisation. Pour une base de données primaire, indique que la base de données n’est pas prête à synchroniser son journal des transactions avec les bases de données secondaires correspondantes. Pour une base de données secondaire, cette valeur indique que la base de données n’a pas démarré la synchronisation des journaux en raison d’un problème de connexion, est suspendue ou passe par des états de transition pendant le démarrage ou un commutateur de rôle.1 = Synchronisation. Pour une base de données primaire, indique que la base de données est prête à recevoir une demande d'analyse d'une base de données secondaire. Pour une base de données secondaire, indique qu'un déplacement des données actif a lieu pour la base de données.2 = Synchronisé. Une base de données primaire s’affiche SYNCHRONIZED à la place de SYNCHRONIZING. Une base de données secondaire avec validation synchrone affiche Synchronisé lorsque le cache local indique que la base de données est prête pour le basculement et que la synchronisation est en cours.3 = Restauration. Indique la phase dans le processus de restauration lorsqu'une base de données secondaire obtient activement les pages de la base de données primaire.Attention : lorsqu’une base de données sur un réplica secondaire est dans l’état REVERTING , le basculement forcé vers le réplica secondaire laisse la base de données dans un état dans lequel elle ne peut pas être démarrée en tant que base de données primaire. Soit la base de données doit se reconnecter en tant que base de données secondaire, soit vous devez appliquer de nouveaux enregistrements de journal à partir d’une sauvegarde de journal.4 = Initialisation. Indique la phase de restauration lorsque le journal des transactions requis pour qu'une base de données secondaire rattrape le retard du numéro séquentiel de restauration dans le journal est livré et renforcé sur un réplica secondaire.Attention : lorsqu’une base de données sur un réplica secondaire est dans l’état INITIALIZING , le basculement forcé vers le réplica secondaire laisse la base de données dans un état dans lequel elle ne peut pas être démarrée en tant que base de données primaire. Soit la base de données doit se reconnecter en tant que base de données secondaire, soit vous devez appliquer de nouveaux enregistrements de journal à partir d’une sauvegarde de journal. |
synchronization_state_desc |
nvarchar(60) | Description de l'état de déplacement des données, un des suivants :NOT SYNCHRONIZINGSYNCHRONIZINGSYNCHRONIZEDREVERTINGINITIALIZING |
is_commit_participant |
bit | 0 = La validation de transaction n’est pas synchronisée par rapport à cette base de données.1 = La validation des transactions est synchronisée par rapport à cette base de données.Pour une base de données sur un réplica de disponibilité de validation asynchrone, cette valeur est toujours 0.Pour une base de données sur un réplica de disponibilité avec validation synchrone, cette valeur est exacte uniquement sur la base de données primaire. |
synchronization_health |
tinyint | Reflète l’intersection de l’état de synchronisation d’une base de données jointe au groupe de disponibilité sur le réplica de disponibilité et le mode de disponibilité du réplica de disponibilité (mode de validation synchrone ou de validation asynchrone). Il peut s’agir de l’une des valeurs suivantes.0 = Pas sain. La synchronization_state base de données est 0 (NOT SYNCHRONIZING).1 = Partiellement sain. Une base de données sur un réplica de disponibilité de validation synchrone est considérée comme partiellement saine si synchronization_state elle est 1 (SYNCHRONIZING).2 = Sain. Une base de données sur un réplica de disponibilité de validation synchrone est considérée comme saine si synchronization_state elle est 2 (SYNCHRONIZED) et une base de données sur un réplica de disponibilité de validation asynchrone est considérée comme saine si synchronization_state elle est 1 (SYNCHRONIZING). |
synchronization_health_desc |
nvarchar(60) | Description de la synchronization_health base de données de disponibilité.NOT_HEALTHYPARTIALLY_HEALTHYHEALTHY |
database_state |
tinyint | 0 = En ligne1 = Restauration2 = Récupération3 = Récupération en attente4 = Suspect5 = Urgence6 = Hors connexionRemarque : Identique à state la colonne dans sys.databases. |
database_state_desc |
nvarchar(60) | Description du database_state réplica de disponibilité.ONLINERESTORINGRECOVERINGRECOVERY_PENDINGSUSPECTEMERGENCYOFFLINERemarque : Identique à state_desc la colonne dans sys.databases. |
is_suspended |
bit | État de la base de données, un des suivants :0 = Reprise1 = Suspendu |
suspend_reason |
tinyint | Si la base de données est suspendue, la raison de l'état suspendu, une des suivantes :0 = Action utilisateur1 = Suspendre du partenaire2 = Rétablir3 = Capture4 = Appliquer5 = Redémarrer6 = Annuler7 = Revalidation8 = Erreur dans le calcul du point de synchronisation du réplica secondaire |
suspend_reason_desc |
nvarchar(60) | Description de la raison de l'état d'interruption, une des suivantes :SUSPEND_FROM_USER = Un utilisateur a suspendu manuellement le déplacement des donnéesSUSPEND_FROM_PARTNER = Le réplica de base de données est suspendu après un basculement forcéSUSPEND_FROM_REDO = Une erreur s’est produite pendant la phase de rétablissementSUSPEND_FROM_APPLY = Une erreur s’est produite lors de l’écriture du journal dans le fichier (voir journal des erreurs)SUSPEND_FROM_CAPTURE = Une erreur s’est produite lors de la capture du journal sur le réplica principalSUSPEND_FROM_RESTART = Le réplica de base de données a été suspendu avant le redémarrage de la base de données (voir le journal des erreurs)SUSPEND_FROM_UNDO = Une erreur s’est produite pendant la phase d’annulation (voir le journal des erreurs)SUSPEND_FROM_REVALIDATION = La non-correspondance des modifications du journal est détectée lors de la reconnexion (voir le journal des erreurs)SUSPEND_FROM_XRF_UPDATE = Impossible de trouver le point de journal commun (voir le journal des erreurs) |
recovery_lsn |
numeric(25,0) | Sur le réplica principal, la fin du journal des transactions avant que la base de données primaire n'écrive de nouveaux enregistrements de journal après la récupération ou le basculement. Pour une base de données secondaire donnée, si cette valeur est inférieure au LSN renforcé actuel (last_hardened_lsn), recovery_lsn est la valeur à laquelle cette base de données secondaire doit resynchroniser (autrement dit, rétablir et réinitialiser). Si cette valeur est supérieure ou égale au LSN renforcé actuel, la resynchronisation n’est pas nécessaire et ne se produit pas.Reflète recovery_lsn un ID de bloc de journal rembourré avec des zéros. Ce n’est pas un LSN réel. Pour plus d’informations sur la façon dont cette valeur est dérivée, consultez Comprendre les valeurs de colonne LSN, plus loin dans cet article. |
truncation_lsn |
numeric(25,0) | Sur le réplica principal pour la base de données primaire, reflète la valeur minimale de LSN de troncation de journal sur toutes les bases de données secondaires correspondantes. Si la troncation du journal en local est bloquée (notamment par une opération de sauvegarde), ce LSN peut être supérieur au LSN de troncation en local. Pour une base de données secondaire donnée, reflète le point de troncation de cette base de données. truncation_lsn reflète un ID de bloc de journal rembourré avec des zéros. Il ne s’agit pas d’un numéro de séquence de journal réel. |
last_sent_lsn |
numeric(25,0) | Lorsque vous interrogez le réplica principal, last_sent_lsn il est signalé pour chaque ligne de base de données de réplica secondaire. Identificateur du bloc du journal qui indique le point jusqu'auquel tous les blocs du journal ont été envoyés par la base de données primaire. Il s’agit de l’ID du bloc de journal suivant qui est envoyé, plutôt que l’ID du bloc de journal le plus récemment envoyé.last_sent_lsn reflète un ID de bloc de journal rembourré avec des zéros. Il ne s’agit pas d’un numéro de séquence de journal réel. |
last_sent_time |
datetime | Lorsque vous interrogez le réplica principal, last_sent_time il est signalé pour chaque ligne de base de données de réplica secondaire. Heure à laquelle le dernier bloc du journal a été envoyé. |
last_received_lsn |
numeric(25,0) | Lorsque vous interrogez un réplica secondaire, last_received_lsn il est signalé pour la ligne de base de données du réplica secondaire local. ID de bloc du journal qui identifie le point jusqu'auquel tous les blocs du journal ont été reçus par le réplica secondaire qui héberge cette base de données secondaire.Reflète last_received_lsn un ID de bloc de journal rembourré avec des zéros. Il ne s’agit pas d’un numéro de séquence de journal réel. |
last_received_time |
datetime | Lorsque vous interrogez un réplica secondaire, last_received_time il est signalé pour la ligne de base de données du réplica secondaire local. Heure à laquelle l'ID de bloc de journal du dernier message reçu a été lu sur le réplica secondaire. |
last_hardened_lsn |
numeric(25,0) | Début du bloc de journal contenant les enregistrements de journal des derniers LSN renforcés sur une base de données secondaire. Sur une base de données primaire de validation asynchrone ou sur une base de données de validation synchrone dont la stratégie actuelle est delay, la valeur est NULL. Pour les autres bases de données primaires de validation synchrone, last_hardened_lsn indique le minimum du LSN renforcé sur toutes les bases de données secondaires.Remarque : reflète last_hardened_lsn un ID de bloc de journal rembourré avec des zéros. Il ne s’agit pas d’un numéro de séquence de journal réel. Pour plus d’informations, consultez Comprendre les valeurs de colonne LSN, plus loin dans cet article. |
last_hardened_time |
datetime | Sur une base de données secondaire, heure de l’identificateur de bloc de journal pour le dernier LSN renforcé (last_hardened_lsn). Sur une base de données primaire, reflète l'heure correspondant à la valeur minimale de LSN renforcé. |
last_redone_lsn |
numeric(25,0) | Numéro séquentiel dans le journal réel du dernier enregistrement du journal qui a été restauré sur la base de données secondaire. La valeur last_redone_lsn est toujours inférieure à last_hardened_lsn. |
last_redone_time |
datetime | Heure à laquelle le dernier enregistrement du journal a été restauré sur la base de données secondaire. |
log_send_queue_size |
bigint | Nombre d’enregistrements de journal de la base de données primaire qui n’a pas été envoyée aux bases de données secondaires, en kilo-octets (Ko). |
log_send_rate |
bigint | Taux moyen auquel l’instance de réplica principale a envoyé des données pendant la dernière période active, en kilo-octets (Ko)/seconde. |
redo_queue_size |
bigint | Nombre d’enregistrements de journal dans les fichiers journaux du réplica secondaire qui ne sont pas encore restaurés, en kilo-octets (Ko). |
redo_rate |
bigint | Taux moyen auquel les enregistrements de journal sont refaire sur une base de données secondaire donnée, en kilo-octets (Ko)/seconde.redo_rate est calculé en divisant le nombre total d’octets de journal depuis le démarrage du moteur de base de données par l’intervalle de temps pendant lequel le rétablissement était en cours d’exécution, plutôt que par le temps écoulé. Étant donné que le rétablissement peut ne pas s’exécuter en continu, la valeur résultante peut être différente (supérieure) à la valeur du compteur de Database Replica:Redone Bytes/sec performances. |
filestream_send_rate |
bigint | Spécifie le taux auquel les fichiers FILESTREAM sont envoyés au réplica secondaire, en kilo-octets (Ko)/seconde. |
end_of_log_lsn |
numeric(25,0) | LSN de fin de journal local. Numéro séquentiel réel dans le journal correspondant au dernier enregistrement du journal dans le cache du journal sur les bases de données primaire et secondaire. Sur le réplica principal, les lignes secondaires reflètent la fin du numéro LSN du journal à partir des derniers messages de progression envoyés par les réplicas secondaires au réplica principal.end_of_log_lsn reflète un ID de bloc de journal rembourré avec des zéros. Il ne s’agit pas d’un numéro de séquence de journal réel. Pour plus d’informations, consultez Comprendre les valeurs de colonne LSN, plus loin dans cet article. |
last_commit_lsn |
numeric(25,0) | Numéro séquentiel réel dans le journal correspondant au dernier enregistrement de validation dans le journal des transactions. Sur la base de données primaire, cet argument correspond au dernier enregistrement de validation traité. Les lignes des bases de données secondaires affichent le numéro de séquence de journaux que le réplica secondaire a envoyé au réplica principal. Sur le réplica secondaire, il s'agit du dernier enregistrement de validation qui a été restauré. |
last_commit_time |
datetime | Heure correspondant au dernier enregistrement de validation. Sur la base de données secondaire, cette heure est la même que dans la base de données primaire. Sur le réplica principal, chaque ligne de base de données secondaire affiche l’heure à laquelle le réplica secondaire qui héberge la base de données secondaire renvoyée au réplica principal. La différence de temps entre la ligne de base de données primaire et une ligne de base de données secondaire donnée représente approximativement l’objectif de point de récupération (RPO), en supposant que le processus de restauration est rattrapé et que la progression a été renvoyée au réplica principal par le réplica secondaire. |
low_water_mark_for_ghosts |
bigint | Nombre à croissance monotone pour la base de données, qui indique une limite inférieure utilisée par la tâche de nettoyage des enregistrements fantômes sur la base de données primaire. Si ce nombre n’augmente pas au fil du temps, cela signifie que le nettoyage fantôme peut ne pas se produire. Pour déterminer quelles lignes fantômes nettoyer, le réplica principal utilise la valeur minimale de cette colonne pour cette base de données sur tous les réplicas de disponibilité (y compris le réplica principal). |
secondary_lag_seconds |
bigint | Nombre de secondes que le réplica secondaire se trouve derrière le réplica principal pendant la synchronisation. Sur le réplica principal, le délai de synchronisation (décalage) de chaque base de données secondaire est calculé comme le nombre de secondes depuis le renforcement du LSN renforcé le plus ancien sur le réplica principal qui n’est pas encore renforcé sur le réplica secondaire. Cette valeur indique que 0 le déplacement des données est suspendu. Le déplacement des données doit être dans un état non suspendu pour que cette valeur affiche le décalage actif.S’applique à : SQL Server 2016 (13.x) et versions ultérieures. |
Comprendre les valeurs de colonne LSN
Les valeurs des numéros de end_of_log_lsnrecovery_lsnlast_hardened_lsnlast_received_lsnlast_sent_lsntruncation_lsn séquence de journaux (LSN) ne sont pas des nombres de séquences de journaux réels ( LSN). Chacune de ces valeurs reflète plutôt un ID de bloc de journal complété avec des zéros.
end_of_log_lsn, last_hardened_lsnet recovery_lsn sont vider les réseaux LSN. Par exemple, last_hardened_lsn indique le début du bloc suivant au-delà des blocs déjà sur le disque. Ainsi, tout LSN réduit la valeur d’un last_hardened_lsn disque. Les réseaux LSN supérieurs ou égaux à cette valeur ne sont pas vidés.
Parmi les valeurs LSN retournées par sys.dm_hadr_database_replica_states, il s’agit uniquement last_redone_lsn d’un LSN réel.
autorisations
SQL Server 2019 (15.x) et les versions antérieures nécessitent VIEW SERVER STATE une autorisation sur le serveur.
SQL Server 2022 (16.x) et versions ultérieures nécessitent VIEW SERVER PERFORMANCE STATE une autorisation sur le serveur.