Groupes de disponibilité AlwaysOn log_send_rate

Sur toutes nos configurations AlwaysOn, exécutant Windows 2012 et SQL Server 2012 sur des machines virtuelles et sur du bare-metal, je trouve que log_send_rate in renvoie sys.dm_hadr_database_replica_statessystématiquement des valeurs incorrectes.

Par exemple (pour le mode synchrone)

sys.dm_hadr_database_replica_states.log_send_rate (ave = 36,571 (kb / s répertoriés dans bol))

Perfmon - SQLServer: réplique de disponibilité - octets envoyés à la réplique / s (max = 486 000 000, moyenne = 259 000 000)

Perfmon - SQLServer: Bases de données - Octets de journal vidés / s (max = 653 044 000, moyenne = 341 000 000)

Je n'ai vu aucun article à ce sujet mais cela ne semble pas fonctionner correctement. Une log_send_ratevaleur correcte est utile pour surveiller AlwaysOn.

Quelqu'un d'autre a-t-il vécu cela?

Oui, cela a été corrigé récemment dans le Service Pack 2, mise à jour cumulative 3. Voici l'article de la base de connaissances: http://support.microsoft.com/kb/3012182

«CORRECTIF: la colonne Log_Send_Rate dans sys.dm_hadr_database_replica_states ne peut pas refléter le taux avec précision dans SQL Server 2012»

La raison pour laquelle le log_send_rate(et redo_rate) est un peu difficile à comprendre et à "corréler", en particulier lorsque nous sommes habitués au transfert de données sur un type de pensée à point de temps ininterrompu, c'est que ces deux taux sont calculés pendant les périodes actives, pas toujours. .

En d'autres termes, le log_send_ratesera ajusté lorsqu'il y aura des blocs de journaux envoyés, mais il ne descendra pas lorsqu'il est silencieux et que la réplique principale attend l'envoi du journal. De même, la même chose à l'inverse sur les secondaires avec redo_rate.

J'ai examiné les valeurs log_send_rate dans le cadre du dépannage d'un problème de latence que nous avons dans l'un de nos environnements de production.

J'ai proposé à Microsoft que leur définition du champ est erronée, comme mentionné ici ( http://technet.microsoft.com/en-us/library/ff877972(v=sql.110).aspx ). "Taux d'envoi des enregistrements de journal aux bases de données secondaires, en kilo-octets (Ko) / seconde."

Je pense que ma définition ci-dessous est meilleure. C'est ... "La vitesse à laquelle les enregistrements de journal sont effacés de la file d'attente d'envoi", et les enregistrements de journal ne peuvent être effacés de cette file d'attente que lorsqu'ils ont déjà été renforcés sur tous les secondaires, et cela ne peut se produire que lorsqu'ils ont déjà été envoyés et reçus, indépendamment du temps qu'il a fallu à ces enregistrements pour arriver, du temps qu'il leur a fallu pour être durcis et du temps qu'il a fallu au secondaire pour renvoyer les accusés de réception au primaire.

C'est une définition très différente, même si elles sont esthétiquement identiques. Les données peuvent être supprimées d'une file d'attente locale en mémoire (log_send_queue) beaucoup plus rapidement qu'elles ne peuvent être envoyées aux secondaires d'une autre région, d'un pays ou d'un centre de données.

Nikos

@Thomas (je suis toujours trop noob pour ajouter des commentaires ici, excuses. Si je peux plus facilement fournir mon email de travail et nous pouvons discuter hors ligne, et mettre à jour ici quand un consensus est atteint?) Salut Thomas

Malheureusement, bien que votre point soit correct, ce n'est pas le point en jeu. Oui, il est plus difficile de corréler pour toutes les raisons que vous avez décrites, mais ce n'est pas le problème que j'essaie de souligner.

Le fait est que le champ "log_send_rate" dans le DMV n'est pas réellement la vitesse à laquelle les enregistrements de journal sont envoyés aux répliques.

Plus précisément, c'est la vitesse à laquelle les enregistrements de journal sont supprimés de la file d'attente d'envoi, APRÈS qu'ils ont DÉJÀ été envoyés au secondaire, renforcés au secondaire, puis renvoyés un accusé de réception au primaire. Ce n'est qu'alors qu'ils peuvent être supprimés de la file d'attente d'envoi principale.

C'est une signification complètement différente de celle répertoriée dans le lien que j'ai inclus dans mon premier post. Il est également beaucoup plus facile de voir la différence lorsque vous traitez avec des taux d'envoi transrégionaux (tels que Londres à New York), plutôt que d'envoyer des taux depuis et vers le centre de données local.