Gruppi di disponibilità AlwaysOn log_send_rate

In tutte le nostre configurazioni AlwaysOn, che eseguono Windows 2012 e SQL Server 2012 su macchine virtuali e su bare metal, trovo che log_send_rate sys.dm_hadr_database_replica_statesrestituisca costantemente valori errati.

Ad esempio (per la modalità sincrona)

sys.dm_hadr_database_replica_states.log_send_rate (ave = 36.571 (kb / s elencati in bol))

Perfmon - SQLServer: Disponibilità Disponibilità - Byte inviati a Replica / sec (max = 486.000.000, avg = 259.000.000)

Perfmon - SQLServer: database - log byte scaricati / sec (max = 653.044.000, avg = 341.000.000)

Non ho visto alcun post su questo, ma non sembra funzionare correttamente. Un log_send_ratevalore corretto è utile per monitorare AlwaysOn.

Qualcun altro ha sperimentato questo?

Sì, questo è stato risolto di recente in Service Pack 2, Aggiornamento cumulativo 3. Ecco l'articolo KB: http://support.microsoft.com/kb/3012182

"FIX: la colonna Log_Send_Rate in sys.dm_hadr_database_replica_states non può riflettere accuratamente la velocità in SQL Server 2012"

Il motivo per cui log_send_rate(e redo_rate) è un po 'complicato da comprendere e "correlare", specialmente quando siamo abituati al trasferimento di dati su un tipo di pensiero ininterrotto del punto di tempo è che queste due velocità sono calcolate durante i periodi attivi, non tutte le volte .

In altre parole, log_send_rateverrà regolato quando vengono inviati blocchi di registro, ma non diminuirà quando è silenzioso e la replica primaria è in attesa sul registro per l'invio. Allo stesso modo, lo stesso al contrario con i secondari redo_rate.

Ho esaminato i valori log_send_rate come parte della risoluzione dei problemi di latenza che abbiamo in uno dei nostri ambienti di produzione.

Ho proposto a Microsoft che la loro definizione del campo è errata, come menzionato qui ( http://technet.microsoft.com/en-us/library/ff877972(v=sql.110).aspx ). "Velocità di invio dei record di registro ai database secondari, in kilobyte (KB) / secondo."

Penso che la mia definizione di seguito sia migliore. È ... "La velocità con cui i record di registro vengono cancellati dalla coda di invio" e i record di registro possono essere cancellati da questa coda solo quando sono già stati rafforzati su tutti i secondari e ciò può avvenire solo quando sono già stati inviato e ricevuto, a prescindere da quanto tempo impiegassero quei dischi per arrivare, e quanto tempo impiegarono per essere induriti, e quanto tempo impiegò il secondario a rimandare gli ack al primario.

È una definizione molto diversa, anche se sembrano esteticamente uguali. I dati possono essere rimossi da un locale nella coda di memoria (log_send_queue) molto più velocemente di quanto possano essere inviati ai secondari in un'altra regione, paese o centro dati.

Nikos

@Thomas (Sono ancora troppo indifferente per aggiungere commenti qui, scuse. Se più semplice posso fornire la mia e-mail di lavoro e possiamo discutere offline e aggiornare qui quando viene raggiunto il consenso?) Ciao Thomas

Sfortunatamente, mentre il tuo punto è corretto, non è il punto in gioco. Sì, è più difficile correlare per tutti i motivi che hai descritto, ma non è il problema che sto cercando di evidenziare.

Il punto è che il campo "log_send_rate" nel DMV non è in realtà la velocità con cui i record di log vengono inviati alle repliche.

Più precisamente, è la velocità con cui i record di registro vengono rimossi dalla coda di invio, DOPO che sono già stati inviati al secondario, induriti al secondario e quindi rispediti al primario. Solo allora possono essere cancellati dalla coda di invio principale.

Questo è un significato completamente diverso da quello elencato nel link che ho incluso nel mio primo post. È anche molto più facile vedere la discrepanza quando si ha a che fare con le tariffe di invio interregionale (come da Londra a New York), piuttosto che inviare le tariffe da e verso il datacenter locale.