AlwaysOn-Verfügbarkeitsgruppen log_send_rate

Bei all unseren AlwaysOn-Setups, bei denen Windows 2012 und SQL Server 2012 in virtuellen Maschinen und auf Bare-Metal ausgeführt werden, gibt die log_send_rate in sys.dm_hadr_database_replica_statesdurchweg falsche Werte zurück.

Zum Beispiel (für den synchronen Modus)

sys.dm_hadr_database_replica_states.log_send_rate (ave = 36.571 (kb / s in bol aufgeführt))

Perfmon - SQLServer: Verfügbarkeitsreplik - An Replikat gesendete Bytes / Sek. (Max = 486.000.000, Durchschnitt = 259.000.000)

Perfmon - SQLServer: Datenbanken - Protokollbytes geleert / Sek. (Max = 653.044.000, Durchschnitt = 341.000.000)

Ich habe keine Beiträge dazu gesehen, aber es scheint nicht richtig zu funktionieren. Ein korrekter log_send_rateWert ist nützlich für die Überwachung von AlwaysOn.

Hat das noch jemand erlebt?

Ja, dies wurde kürzlich in Service Pack 2, Cumulative Update 3, behoben. Hier ist der KB-Artikel: http://support.microsoft.com/kb/3012182

"UPDATE: Die Spalte Log_Send_Rate in sys.dm_hadr_database_replica_states kann die Rate in SQL Server 2012 nicht genau wiedergeben."

Der Grund, warum das log_send_rate(und redo_rate) etwas schwierig zu verstehen und zu "korrelieren" ist, insbesondere wenn wir an die Datenübertragung über einen ununterbrochenen Zeitpunkt gewöhnt sind, ist, dass diese beiden Raten während aktiver Zeiten berechnet werden, nicht immer .

Mit anderen Worten, das log_send_ratewird angepasst, wenn Protokollblöcke gesendet werden, aber es wird nicht heruntergefahren, wenn es leise ist und das primäre Replikat auf das Senden des Protokolls wartet. Ebenso das gleiche umgekehrt bei Secondaries mit redo_rate.

Ich habe mir die log_send_rate-Werte als Teil der Fehlerbehebung bei einem Latenzproblem angesehen, das in einer unserer Produktionsumgebungen auftritt.

Ich habe Microsoft vorgeschlagen, dass ihre Definition des Feldes falsch ist, wie hier erwähnt ( http://technet.microsoft.com/en-us/library/ff877972(v=sql.110).aspx ). "Rate, mit der Protokollsätze an die sekundären Datenbanken gesendet werden, in Kilobyte (KB) / Sekunde."

Ich denke, meine Definition unten ist besser. Es ist ... "Die Rate, mit der Protokolldatensätze aus der Sendewarteschlange gelöscht werden", und Protokolldatensätze können nur aus dieser Warteschlange gelöscht werden, wenn sie bereits auf allen Sekundärdateien gehärtet wurden, und dies kann nur geschehen, wenn sie bereits gespeichert wurden gesendet und empfangen, unabhängig davon, wie lange es gedauert hat, bis diese Aufzeichnungen eingegangen sind, wie lange es gedauert hat, bis sie gehärtet sind, und wie lange es gedauert hat, bis die Sekundärseite die Bestätigungen an die Primärdatenbank zurückgeschickt hat.

Das ist eine ganz andere Definition, auch wenn sie kosmetisch gleich aussehen. Daten können viel schneller aus einer lokalen Warteschlange (log_send_queue) entfernt werden, als sie an die sekundären in einer anderen Region, einem anderen Land oder einem anderen Rechenzentrum gesendet werden können.

Nikos

@Thomas (Ich bin immer noch zu noob, um hier Kommentare hinzuzufügen, entschuldige mich. Wenn es einfacher ist, kann ich meine Arbeits-E-Mail bereitstellen und wir können offline diskutieren und hier aktualisieren, wenn ein Konsens erreicht ist?) Hallo Thomas

Obwohl Ihr Punkt korrekt ist, geht es leider nicht um den Punkt. Ja, es ist aus all den Gründen, die Sie beschrieben haben, schwieriger zu korrelieren, aber es ist nicht das Problem, das ich hervorheben möchte.

Der Punkt ist, dass das Feld "log_send_rate" in der DMV nicht die Rate ist, mit der Protokolldatensätze an die Replikate gesendet werden.

Genauer gesagt ist dies die Rate, mit der Protokolldatensätze aus der Sendewarteschlange entfernt werden, nachdem sie BEREITS an die Sekundärseite gesendet, an der Sekundärseite gehärtet und dann eine Bestätigung an die Primärdatenbank zurückgesendet wurden. Nur dann können sie aus der primären Sendewarteschlange gelöscht werden.

Das ist eine ganz andere Bedeutung als die, die in dem Link aufgeführt ist, den ich in meinem ersten Beitrag aufgenommen habe. Es ist auch viel einfacher, die Diskrepanz zu erkennen, wenn Sie mit überregionalen Sendegebühren (z. B. von London nach New York) arbeiten, als mit Übertragungsraten von und zum lokalen Rechenzentrum.