Das Transaktionsprotokoll log_reuse_wait_desc - AVAILABILITY_REPLICA kann nicht abgeschnitten werden

Heute Morgen wurde ich von einem vollständigen Transaktionsprotokoll-Alarm in einer unserer Datenbanken geweckt. Dieser Server ist ein Alwayson-Cluster und auch ein Abonnent für die Transaktionsreplikation. Ich habe log_reuse_wait_desc überprüft und es wurde eine Rückmeldung angezeigt. Jemand hatte die Protokollierungsjobs 4 Tage zuvor versehentlich deaktiviert. Ich habe den Protokollsicherungsjob wieder aktiviert und das Protokoll wurde gelöscht. Da es 4 Uhr morgens war, dachte ich, ich werde später am Morgen ins Büro gehen und das Protokoll shirnk, da es auf 400 GB angewachsen ist.

10 Uhr - Ich bin im Büro und überprüfe die Protokollnutzung, bevor ich sie verkleinere. Sie lag bei 16%. Ich war überrascht und überprüfe das log_reuse_wait_desc, das die Replikation zeigte. Ich war verwirrt, weil dies ein Replikationsabonnent war. Wir haben dann gesehen, dass die Datenbank für CDC aktiviert war und dachten, dass dies die Ursache sein könnte. Deaktivierte CDC und jetzt zeigt log_reuse_wait_desc AVAILABILITY_REPLICA an.

Die Holznutzung wächst mittlerweile stetig und liegt nun bei 17%. Ich überprüfe das Alwayson-Dashboard und überprüfe die gesendete und die Wiederherstellungswarteschlange, und beide sind praktisch Null. Ich bin nicht sicher, warum die Wiederverwendung des Protokolls als AVAILABILITY_REPLICA angezeigt wird und das Protokoll nicht gelöscht werden kann.

Irgendeine Idee, warum das passiert?

Wenn du das tust:

SELECT * FROM sys.databases

Und log_reuse_wait_desc zeigt AVAILABILITY_REPLICA an. Dies bedeutet, dass SQL Server darauf wartet, Protokolldaten an eines Ihrer Replikate der Always On Availability Group zu senden. Eine der Replikate kann aufgrund eines langsamen Netzwerks zurückbleiben oder ganz ausfallen.

Wenn Sie das AG-Dashboard überprüfen und keine Warteschlangen anzeigen, sind Sie möglicherweise Opfer einer Thread-Erschöpfung geworden. Es ist ein bekanntes Problem, dass das AG-Dashboard nach Erschöpfung des Worker-Threads nicht mehr aktualisiert wird. Sie müssen den Status jedes Replikats direkt überprüfen, anstatt sich auf das primäre zu verlassen. Nicks Anmerkung in diesem Connect-Element besagt, dass Sie nur die Eigenschaften eines Replikats ändern können, um die Replikation neu zu starten. Dies funktioniert jedoch nicht immer (insbesondere, wenn auf einem Replikat Hunderte von Datenbanken mit einer großen Datenmenge vorhanden sind, die gesendet werden muss, und Ein Neustart der Replikation kann nur dazu führen, dass der Worker-Thread erneut erschöpft ist.)

Wenn der letzte Typ eine AG-Replik eingerichtet hat und diese nicht mehr existieren soll, ist es Zeit, diese AG und / oder Replik zu entfernen. Achten Sie nur darauf, dass Apps nicht auf den Listenernamen zeigen, um eine Verbindung zu Ihrem SQL Server herzustellen.