Perché questi due DMV HADR riportano stati diversi?

SQL Server 2012 (11.0.5058.0) Enterprise Edition

Abbiamo 8 gruppi di disponibilità in un cluster 2 (HA) +1 (DR) e i nostri DMV di monitoraggio segnalano risultati che mi confondono. 6 I gruppi di disponibilità sono configurati per HA e DR, 1 è configurato solo per HA e 1 è configurato solo per DR.

Ciascuno dei 6 gruppi di disponibilità HA / DR ha "SQLB" come primario e "SQLA" come replica HA secondaria (sincrona) e "SQLC" come replica secondaria (asincrona).

Su entrambi i secondari:

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

segnala che tutti gli stati di sincronizzazione della replica del gruppo di disponibilità sono NOT_HEALTHYe

select replica_id,synchronization_health_desc
from sys.dm_hadr_availability_replica_states

segnala che tutte le repliche hanno uno stato di sincronizzazione di HEALTHY.

La replica primaria riporta tutti i gruppi di disponibilità e le repliche con uno stato di sincronizzazione di HEALTHY.

Mentre capisco che uno riporta l'integrità della sincronizzazione delle repliche e l'altro sull'integrità della sincronizzazione AG, mi sembra logico che se lo stato più granulare (AG) non fosse integro, ciò influirebbe sull'integrità generale del contesto più ampio (replica) . Non riesco a trovare la documentazione MSDN che descrive come viene determinata la salute ad ogni livello.

Perché i secondari segnalano l' NOT_HEALTHYintegrità del gruppo di disponibilità, ma l' HEALTHYintegrità della sincronizzazione delle repliche e perché differisce dal rapporto del primario?

sql-server-2012 availability-groups dmv

— swasheck
fonte

Puoi confermare che stai vedendo solo NOT_HEALTHYsulla replica ASYNC secondaria?

— Kin Shah,

sto vedendo NOT_HEALTHYsu entrambe le repliche SYNC e ASYNC.

— sweckeck,

Purtroppo, gli stati sys.dm_hadr_availability_replica non sono un indicatore affidabile dell'integrità della replica. Ecco l'elemento Connect su uno dei bug che abbiamo riscontrato in cui DMV interrompe l'aggiornamento. Nota nei commenti che log_send_queue_size in DMV sys.dm_hadr_database_replica_states mostra 0 anche quando ci sono dati di registro da inviare.

Si noti che l'elemento Connect è contrassegnato come Non risolto. Trombone triste

— Brent Ozar
fonte

Il collegamento raggiunge una pagina in cui si dice che MS Connect si è ritirato. Questo è stato il 2015. Sono passati quattro anni. Sono qui perché vedo la stessa cosa dell'OP. Immagino volessero dire che "non risolverà". È un po 'zoppo. Il rovescio della medaglia: qualcuno conosce un buon script per riportare l'integrità e la configurazione di AG, dal gruppo alla replica al livello di sincronizzazione del database?

— Youcantryreachingme,

PS. Per me sys.dm_hadr_availability_group_states.synchronization_health_desc(che capisco è riferire sulla salute di tutto il gruppo) riferisce NOT_HEALTHYsui secondari, ma HEALTHYsui primari (3 repliche). I documenti descrivono il col come "un rollup di synchronization_health di tutte le repliche di disponibilità nel gruppo di disponibilità". Ciò mostra disparità all'interno del sistema senza nemmeno guardare sys.dm_hadr_availability_replica_states (che è, presumibilmente, da dove vengono raccolti i dati).

— Youcantryreachingme,

@youcantryreachingme è una domanda diversa: la tua scommessa migliore sarebbe iniziare una nuova domanda.

— Brent Ozar,