Pourquoi ces deux DMV HADR signalent-ils des états différents?

SQL Server 2012 (11.0.5058.0) Enterprise Edition

Nous avons 8 groupes de disponibilité dans un cluster 2 (HA) +1 (DR) et nos DMV de surveillance rapportent des résultats qui me déroutent. 6 Les groupes de disponibilité sont configurés pour HA et DR, 1 est configuré pour HA uniquement et 1 est configuré pour DR uniquement.

Chacun des 6 groupes de disponibilité HA / DR a «SQLB» en tant que réplique HA (SQLA) secondaire et «SQLA» en tant que réplique secondaire (synchrone) et «SQLC» en tant que réplique secondaire (async).

Sur les deux secondaires:

SELECT dhags.group_id, dhags.synchronization_health_desc
FROM sys.dm_hadr_availability_group_states dhags

signale que tous les états de synchronisation de la réplication du groupe de disponibilité sont NOT_HEALTHYet

select replica_id,synchronization_health_desc
from sys.dm_hadr_availability_replica_states

signale que toutes les répliques ont un état de synchronisation de HEALTHY.

Le réplica principal signale tous les groupes de disponibilité et réplicas avec un état de synchronisation de HEALTHY.

Bien que je comprenne qu'un rapport sur la santé de la synchronisation des répliques et les autres rapports sur la santé de la synchronisation AG, il me semble logique que si l'état plus granulaire (AG) n'était pas sain, cela affecterait la santé globale du contexte plus large (réplique) . Je ne trouve pas de documentation MSDN qui décrit comment l'état de santé est déterminé à chaque niveau.

Pourquoi les secondaires établiraient-ils un rapport NOT_HEALTHYsur l'intégrité de la synchronisation du groupe de disponibilité, mais HEALTHYsur l'intégrité de la synchronisation des réplicas, et pourquoi cela diffère-t-il du rapport du principal?

sql-server-2012 availability-groups dmv

— swasheck
source

Pouvez-vous confirmer que vous voyez NOT_HEALTHYuniquement sur la réplique ASYNC secondaire?

— Kin Shah

je vois NOT_HEALTHYà la fois sur les répliques SYNC et ASYNC.

— swasheck

Malheureusement, sys.dm_hadr_availability_replica n'est pas un indicateur fiable de l'intégrité des répliques. Voici l'élément Connect sur l'un des bogues que nous avons rencontrés où DMV cesse de se rafraîchir - notez dans les commentaires que log_send_queue_size dans le DMV sys.dm_hadr_database_replica_states affiche 0 même lorsqu'il y a des données de journal à envoyer.

Notez que l'élément Connect est marqué comme ne sera pas résolu. Trombone triste.

— Brent Ozar
source

Le lien atteint une page indiquant que MS Connect a pris sa retraite. Ce Q&R était 2015. C'est quatre ans plus tard. Je suis ici parce que je vois la même chose que l'OP. Je suppose qu'ils voulaient dire "ne va pas réparer". C'est un peu boiteux. D'un autre côté - quelqu'un connaît-il un bon script pour signaler la santé et la configuration d'AG, du groupe à la réplique au niveau de synchronisation de la base de données?

— youcantryreachingme

PS. Pour moi, sys.dm_hadr_availability_group_states.synchronization_health_desc(ce que je comprends, c'est un rapport sur la santé de l'ensemble du groupe) des rapports NOT_HEALTHYsur les secondaires, mais HEALTHYsur les primaires (3 répliques). Les documents décrivent le col comme "un cumul de synchronization_health de toutes les réplicas de disponibilité dans le groupe de disponibilité". Cela montre la disparité au sein du système sans même regarder sys.dm_hadr_availability_replica_states (qui est, vraisemblablement, d'où les données sont remontées).

— youcantryreachingme

@youcantryreachingme c'est une question différente - votre meilleur pari serait de commencer une nouvelle question.

— Brent Ozar