Wird ein Exchange Server 2019 mit einem Backup gesichert, denkt man, dass die Transaktionsprotokolle abgeschnitten werden. Doch man erhält keinen freien Platz. Ich bin ehrlich, mir war das Thema auch nicht so sehr bewusst. Aber der Umstand kann sehr wohl zu einer Art „Back Pressure“ führen, was ein gängiges Problem auf Exchange Servern ist. Warum werden die Protokolle denn nicht gelöscht? Und ist das nun eine neue Nummer, die sich da Microsoft einfallen lässt? Schauen wir uns das einfach hier mal an. Allerdings bin ich auch nicht der Erste, der davon erzählt.
Hilfe, Exchange Server 2019 sendet keine Nachrichten mehr!
Wir haben im Support immer wieder damit zu tun, dass Exchange Server plötzlich keine Nachrichten mehr sendet – oder wenn, dann enorm verzögert. Das kann viele Ursachen haben. Eine sehr treffende ist der so genannte „Back Pressure“. Dabei handelt es sich um einen Schutzmechanismus des Transportdienstes, wenn Exchange überlastet ist. Werden bei bestimmten Ressourcen wie Arbeitsspeicher oder Plattenplatz bestimmte Schwellwerte überschritten, verzögert Exchange die Nachrichtenverarbeitung.
Das macht aber nicht erst Exchange Server 2019 so, das gibt es schon seit mindestens Exchange Server 2013. Alles andere wird zurückgefahren, und das System arbeitet ausschließlich an der Verarbeitung der vorhandenen Nachrichten und am Abbau der Lastspitze. Ist diese dann vorbei, nimmt Exchange wieder den Normalbetrieb auf. Überwacht werden dabei unter anderem Plattenplatz, Arbeitsspeicher und Nachrichtenwarteschlange. Das ist alles hier beschrieben.
Was hat das aber mit den Transaction Logs zu tun?
Transaction Logs werden verwendet, um alle möglichen Änderungen zu protokollieren. Dazu kommen Checkpoint-Dateien. Beides wird verwendet, um möglichst Datenverlust zu vermeiden, falls mal etwas passiert. Alle Änderungen an den Datenbanken werden in die Transaction Logs geschrieben, und die Checkpoints protokollieren, welche Transaktionen in die Datenbank geschrieben wurde. Findet ein Backup statt, werden alle Änderungen in die Datenbank übertragen und die Protokolle abgetragen.
Das ist jetzt nichts neues und keine Erfindung für Exchange Server 2019. Das gibt es, so lang ich mit Exchange Servern zu tun habe. Und das ist schon eine Weile. Irgendwie hat man immer im Hinterkopf: Läuft das Backup durch, werden die Logs abgeschnitten, und ich habe mehr Platz. Was aber, wenn dieser Mechanismus so gar nicht zutrifft? Das merkt man dann, wenn die Platte voll ist, obwohl das Backup erfolgreich war, und das oben beschriebene Back Pressure zuschlägt.
Erkennen kann man das durch Events mit den IDs 15004 und 15005 im Application Log des oder der Exchange Server. Dort steht dann auch, welche Ressource „under pressure“ ist und wie der Status („Medium“ oder „High“) ist. Im schlimmsten Fall kommen noch Events mit der ID 26014 dazu, dass der Transport Service Nachrichten ablehnt. Und dort protokolliert Exchange Server 2019, dass die Checkpoint Depth „Hoch“ sei. Das wäre dann der mutmaßliche Grund für das Verhalten.
Checkpoint Depth? Nie gehört
Jetzt muss man sich bewusst machen, dass bei einem erfolgreichen Backup trotzdem einige Transcation Logs übrig bleiben. Normal sind 100. Aber das Ganze kann auch aus dem Ruder laufen. Dann muss Exchange untersucht werden. Und das kann ein Haufen Zeit bedeuten. Denn wenn Exchange nichts mehr tut, weil er mit sich selbst beschäftigt ist, ist es zu spät. Vielleicht ist es sinnvoll, das Thema hierüber nachzuvollziehen:
Get-EventLog -ComputerName COMPUTERNAME -LogName Application -After (Get-Date).AddDays(-1) | where {$_.EventID -eq "15004"}
Get-EventLog -ComputerName COMPUTERNAME -LogName Application -After (Get-Date).AddDays(-1) | where {$_.EventID -eq "15005"}Ich denke aber am Ende, dass es wenig Probleme gibt, wenn diese ominöse Checkpoint Depth im dreistelligen Bereich liegt. Dann liegen beispielsweise bei einem Wert von 350 eben so viele Logs im Log-Verzeichnis. Diese können nicht gelöscht werden. Exchange legt diesen Wert selbst fest und schreibt ihn in die Checkpoint-Datei. Und so lang der Wert nicht in Richtung 10240 geht, ist auch alles gut. Es kommt halt immer darauf an, wie viel Verkehr auf den Datenbanken drauf ist. Je weniger, desto höher die Checkpoint Depth.
Dieses Verhalten ist „by design“. Der Wert wird von Exchange selbst angepasst, und das dynamisch. Sollte der Wert mal höher als „dreistellig“ sein, muss man Exchange Server 2019 – aber auch frühere Versionen – genau untersuchen. Und genau das ist mein täglicher Job. Wir haben da ein gewisses Gespür entwickelt, was zu tun ist. Und da wir noch eine ganze Weile mit Exchange Server 2019 zu tun haben werden, sind solche Themen auch bis auf weiteres relevant.