sys.dm_hadr_database_replica_states (Transact-SQL)

  • Article

Retourne une ligne pour chaque base de données qui participe à un groupe de disponibilité AlwaysOn 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

Selon l'action et les états de niveau supérieur, les informations d'état de la base de données peuvent être non disponibles ou obsolètes. En outre, les valeurs ont uniquement une pertinence locale. Par exemple, sur le réplica principal, la valeur de la colonne last_hardened_lsn reflète les informations sur une base de données secondaire donnée actuellement disponible pour le réplica principal, et non la valeur LSN renforcée réelle 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 l'affichage 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 pour l'instance de SQL Server.

1 = La base de données est locale pour l'instance de serveur.

synchronization_state

tinyint

État de déplacement des données, un des suivants :

Valeur

Description

0

Sans 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, indique que la base de données n'a pas commencé la synchronisation du journal en raison d'un problème de connexion, est suspendue, ou passe par des états de transition pendant le démarrage ou lors d'un changement de rôle.

1

Synchronisation.

  • Pour une base de données principale, 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 principale 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

Rétablissement. 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.

AttentionAttention

Lorsqu'une base de données sur un réplica secondaire est dans l'état REVERTING, forcer le basculement 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 principale. La base de données doit se reconnecter comme base de données secondaire, ou vous devez appliquer les nouveaux enregistrements du journal à partir d'une sauvegarde du journal.

4

Initialisation en cours. 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.

AttentionAttention

Lorsqu'une base de données sur un réplica secondaire est dans l'état INITIALIZING, forcer le basculement vers le réplica secondaire laisse la base de données dans un état dans lequel elle doit être démarrée en tant que base de données principale. La base de données doit se reconnecter comme base de données secondaire, ou vous devez appliquer les nouveaux enregistrements du journal à partir d'une sauvegarde du journal.

synchronization_state_desc

nvarchar(60)

Description de l'état de déplacement des données, un des suivants :

NOT SYNCHRONIZING

SYNCHRONIZING

SYNCHRONIZED

REVERTING

INITIALIZING

is_commit_participant

bit

0 = La validation de transaction n'est pas synchronisée par rapport à cette base de données.

1 = La validation de transaction est synchronisée par rapport à cette base de données.

Pour une base de données sur un réplica de disponibilité avec validation asynchrone, cette valeur est toujours de 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 qui est jointe au groupe de disponibilité sur le réplica de disponibilité, ainsi que le mode de disponibilité du réplica de disponibilité (en mode de validation synchrone ou asynchrone), à savoir :

Valeur

Description

0

Non sain. L'état de synchronisation de la base de données est 0 (NOT SYNCHRONIZING).

1

Partiellement sain. Une base de données sur un réplica de disponibilité à validation synchrone est considérée comme partiellement saine si l'état de synchronisation est 1 (SYNCHRONIZING).

2

Sain. Une base de données sur un réplica de disponibilité à validation synchrone est considérée comme saine si l'état de synchronisation est 2 (SYNCHRONIZED). De même, une base de données sur un réplica de disponibilité à validation asynchrone est considérée comme saine si l'état de synchronisation est 1 (SYNCHRONIZING).

synchronization_health_desc

nvarchar(60)

Description de l'état de synchronisation de la base de données de disponibilité.

NOT_HEALTHY

PARTIALLY_HEALTHY

HEALTHY

database_state

tinyint

0 = En ligne

1 = Restauration

2 = Récupération

3 = Récupération en attente

4 = Suspect

5 = Urgence

6 = Hors connexion

[!REMARQUE]

Identique à la colonne state de sys.databases.

database_state_desc

nvarchar(60)

Description de l'état de la base de données du réplica de disponibilité.

ONLINE

RESTORING

RECOVERING

RECOVERY_PENDING

SUSPECT

EMERGENCY

OFFLINE

[!REMARQUE]

Identique à la colonne state de sys.databases.

is_suspended

bit

État de la base de données, un des suivants :

0 = Reprise

1 = Suspendu

suspend_reason

tinyint

Si la base de données est suspendue, la raison de l'état suspendu, une des suivantes :

0 = Action de l'utilisateur

1 = Interruption du partenaire

2 = Rétablir

3 = Capturer

4 = Appliquer

5 = Redémarrer

6 = Annuler

7 = Revalidation

8 = 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 de données

SUSPEND_FROM_PARTNER = le réplica de base de données est suspendue après un basculement forcé

SUSPEND_FROM_REDO = une erreur s'est produite lors de la phase de rétablissement

SUSPEND_FROM_APPLY = une erreur s'est produite lors de l'écriture du journal sur le fichier (consultez le journal des erreurs)

SUSPEND_FROM_CAPTURE = une erreur s'est produite lors de la capture du journal sur le réplica principal

SUSPEND_FROM_RESTART = le réplica de base de données a été suspendu avant le redémarrage de la base de données (consultez le journal des erreurs)

SUSPEND_FROM_UNDO = une erreur s'est produite lors de la phase de restauration (consultez le journal des erreurs)

SUSPEND_FROM_REVALIDATION = une discordance de changement de connexion est détectée lors de la reconnexion (consultez le journal des erreurs)

SUSPEND_FROM_XRF_UPDATE = impossible de trouver le point de journal commun (consultez 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 principale 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 numéro séquentiel dans le journal (NSE) renforcé actuel (last_hardened_lsn), recovery_lsn est la valeur à laquelle cette base de données secondaire doit être resynchronisée (c'est-à-dire, rétablie et réinitialisée). Si cette valeur est supérieure ou égale au numéro séquentiel dans le journal renforcé actuel, la resynchronisation n'est pas nécessaire et ne se produira pas.

recovery_lsn reflète un ID de bloc de journal complété avec des zéros. Il ne s'agit pas d'un numéro séquentiel réel dans le journal (LSN). Pour plus d'informations sur la façon dont cette valeur est dérivée, consultez Présentation des valeurs de colonne de numéro séquentiel dans le journal, plus loin dans cette rubrique.

truncation_lsn

numeric(25,0)

Sur le réplica principal pour la base de données principale, 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 complété avec des zéros. Il ne s'agit pas d'un numéro séquentiel réel dans le journal.

last_sent_lsn

numeric(25,0)

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. ID du bloc suivant de journal qui sera 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 complété avec des zéros. Il ne s'agit pas d'un numéro séquentiel réel dans le journal.

last_sent_time

datetime

Heure à laquelle le dernier bloc du journal a été envoyé.

last_received_lsn

numeric(25,0)

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.

last_received_lsn reflète un ID de bloc de journal complété avec des zéros. Il ne s'agit pas d'un numéro séquentiel réel dans le journal.

last_received_time

datetime

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 du LSN de dernière sécurisation renforcée sur une base de données secondaire.

Sur une base de données principale avec validation asynchrone ou sur une base de données avec validation synchrone dont la stratégie actuelle est « delay », la valeur est NULL. Pour les autres bases de données principales avec validation synchrone, last_hardened_lsn indique la valeur minimale de LSN renforcé dans toutes les bases de données secondaires.

[!REMARQUE]

last_hardened_lsn reflète un ID de bloc de journal complété avec des zéros. Il ne s'agit pas d'un numéro séquentiel réel dans le journal. Pour plus d'informations, consultez Présentation des valeurs de colonne de numéro séquentiel dans le journal, plus loin dans cette rubrique.

last_hardened_time

datetime

Sur une base de données secondaire, heure de l'identificateur de bloc de journal pour le LSN de dernière sécurisation renforcée (last_hardened_lsn). Sur une base de données principale, 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. last_redone_lsn est toujours inférieur à 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

Quantité d'enregistrements du journal dans la base de données principale, en kilo-octets (Ko), qui n'a pas encore été envoyée aux bases de données secondaires.

log_send_rate

bigint

Fréquence à laquelle les enregistrements de journal sont envoyés aux bases de données secondaires, en kilo-octets (Ko)/seconde.

redo_queue_size

bigint

Quantité d'enregistrements du journal dans les fichiers journaux du réplica secondaire qui n'a pas encore été réexécutée, en kilo-octets (Ko).

redo_rate

bigint

Fréquence à laquelle les enregistrements de journal sont rétablis sur une base de données secondaire donnée, en kilo-octets (Ko)/seconde.

filestream_send_rate

bigint

Fréquence à laquelle les fichiers FILESTREAM sont envoyés sur le réplica secondaire en kilo-octets/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 le LSN de fin de journal, depuis les derniers messages de progression que les réplicas secondaires ont envoyés au réplica principal.

end_of_log_lsn reflète un ID de bloc de journal complété avec des zéros. Il ne s'agit pas d'un numéro séquentiel réel dans le journal. Pour plus d'informations, consultez Présentation des valeurs de colonne de numéro séquentiel dans le journal, plus loin dans cette rubrique.

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 indiquent le numéro séquentiel dans le journal 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 indique l'heure que le réplica secondaire qui héberge la base de données secondaire a signalé au réplica principal. La différence d'heure entre la ligne de base de données primaire et une ligne de base de données secondaire donnée représente approximativement la durée maximale d'interruption admissible (RTO, Recovery Time Objective), en supposant que le processus de restauration par progression a rattrapé son retard et que la progression a été signalé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 avec le temps, cela implique que le nettoyage des enregistrements fantômes ne se produit pas. 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).

Présentation des valeurs de colonne de numéro séquentiel dans le journal

Les valeurs des colonnes end_of_log_lsn, last_hardened_lsn, last_received_lsn, last_sent_lsn, recovery_lsn et truncation_lsn ne sont pas des numéros séquentiels dans le journal (LSN) réels. 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_lsn et recovery_lsn sont des LSN de vidage. Par exemple, last_hardened_lsn indique le début du bloc suivant après les blocs qui sont déjà sur le disque. Ainsi, n'importe quel numéro séquentiel dans le journal < à la valeur de last_hardened_lsn est sur le disque. Les LSN >= à cette valeur ne sont pas vidés.

Parmi les LSN retournés par sys.dm_hadr_database_replica_states, seul last_redone_lsn est un LSN réel.

Sécurité

Autorisations

Nécessite l'autorisation VIEW SERVER STATE sur le serveur.

Voir aussi

Concepts

Groupes de disponibilité AlwaysOn (SQL Server)

Surveiller des groupes de disponibilité (Transact-SQL)