Kapazitätsplanung – Ja, der Transaktionsprotokoll-Speicherplatz ist wichtig, um die Integrität und Verfügbarkeit Ihrer Datenbanken sicherzustellen







Veröffentlichung des Originalartikels: 09.11.2011


Neulich chattete ich mit Nino Bilic, einem unserer Supportability Program Manager, und er erwähnte etwas, das ziemlich alarmierend war: Der Grund für die meisten kritischen Exchange 2010-Situationen bei unseren Premier-Kunden ist, dass die Bereitstellung der Postfachdatenbanken aufgehoben wurde, da in der Transaktionsprotokoll-LUN zu wenig Speicherplatz verfügbar ist. 


Ich habe das einen Moment sacken lassen. Natürlich war ich geschockt…um ehrlich zu sein, dachte ich, dass wir das Problem mit unserem Postfachanforderungsrechner und unseren diesbezüglichen Tipps und Informationen auf TechNet in den Griff bekommen hätten. Nachdem er mich also informiert hatte, entschied Nino, dass ich und nicht er einen Blogbeitrag zum Thema Transaktionsprotokoll-Kapazitätsplanung schreiben sollte (toll, danke Nino!).


1x1 der Kapazitätsplanung


Um die richtige Größe einer Transaktionsprotokoll-LUN zu ermitteln, müssen wir einige Informationen über die Umgebung sammeln:



  1. Wie viele Postfächer befinden sich in der Datenbank?
  2. Welches Nachrichtenprofil haben die Postfächer in der Datenbank?
  3. Wie ist die durchschnittliche Nachrichtengröße?
  4. Wie ist die durchschnittliche Postfachgröße?
  5. Wie viele Postfächer werden pro Tag verschoben?
  6. Welche Sicherungs- und Wiederherstellungslösung wird verwendet?
  7. Berücksichtigt die Lösung andere Ausfallszenarien, beispielsweise einen Netzwerkausfall?

Nehmen wir zur Demonstrationszwecken an, dass jede Datenbank 250 Postfächer enthält. Jedes Postfach sendet/empfängt 150 Nachrichten pro Tag mit einer durchschnittlichen Nachrichtengröße von 100 KB. Der Tabelle in Grundlegendes zu Postfachdatenbank- und Protokollkapazität können wir entnehmen, dass das Nachrichtenprofil „150“ mit einer durchschnittlichen Nachrichtengröße von 75 KB täglich 30 Transaktionsprotokolle generiert (24-Stunden-Intervall). Da unsere durchschnittliche Nachrichtengröße höher als 75 KB ist, müssen wir dies beim Wert für die Generierung von Transaktionsprotokollen pro Postfach berücksichtigen. Die Richtlinie lautet:


Wenn sich die durchschnittliche Nachrichtengröße auf 150 KB verdoppelt, nehmen die pro Postfach generierten Protokolle um einen Faktor von 1,9 zu. Diese Zahl stellt den Prozentsatz der Datenbank dar, die die Anlagen- und Nachrichtentabellen enthält (Nachrichtentexte und Anlagen).


Daher können wir die Auswirkung einer durchschnittlichen Nachrichtengröße von 100 KB mithilfe der folgenden Formel bestimmen:


150 : 1,9 = [durchschnittliche Nachrichtengröße des Profils] : x


x = (100 x 1,9) : 150


x = 1,266666666666667 ~ 1,27


Wenn also die Nachrichtengröße 25 KB höher als der Basiswert ist, erhöht sich die Anzahl der täglich pro Postfach generierten Transaktionsprotokolle um den Faktor 1,27. Das bedeutet: 30 Transaktionsprotokolle x 1,27 = 39 Transaktionsprotokolle pro Tag und Postfach. Für eine Datenbank mit 250 Postfächer generiert jede Datenbank also 39 x 250 = 9.750 postfachgenerierte Transaktionsprotokolle pro Tag und Datenbank.


Auch beim Verschieben von Postfächern werden Transaktionsprotokolle generiert. Für jedes Postfach, das in die Zieldatenbank verschoben wird, werden Protokolle (am Ziel, nicht an der Quelle) generiert, deren Größe ungefähr der Größe des Postfachs entspricht (einschließlich des Inhalts der Ordner „Wiederherstellbare Elemente“). Beispiel: Wenn täglich 1 % der Postfächer verschoben werden, werden 2,5 Postfächer pro Tag in eine Datenbank verschoben. Wenn jedes Postfach durchschnittlich 5,4 GB groß ist (einschließlich einer Aufbewahrungszeit für gelöschte Elemente von 14 Tagen mit aktivierter Wiederherstellung einzelner Elemente ), werden 2,5 x 5,4 GB : 1024 = 13.888 Transaktionsprotokolle aufgrund von Postfachverschiebungen pro Tag und Datenbank generiert.


Aus Sicherungs-/Wiederherstellungsperspektive muss der Typ der eingesetzten Sicherungsarchitektur berücksichtigt werden. Bei jedem Sicherungsszenario gibt es eine empfohlene Anzahl von zusätzlichen Tagen, die Sie aus Kapazitätsperspektive für die postfachgenerierten Transaktionsprotokolle einräumen sollten. Durch Bereitstellung von zusätzlichem Speicherplatz können Sie mehrere Fehler schadlos überstehen, ohne dass es zu einem Ausfall kommt. Weitere Informationen zum Abschneiden von Transaktionsprotokollen finden Sie unter Grundlegendes zu Sicherung, Wiederherstellung und Notfallwiederherstellung.



























  Transaktionsprotokollabschneidung Empfohlener Schutz vor Sicherungsfehlern
Tägliche vollständige Sicherung Täglich 3 Tage
Wöchentliche vollständige Sicherung/tägliche inkrementelle Sicherung Täglich 3 Tage
Wöchentliche vollständige Sicherung/tägliche differenzielle Sicherung Wöchentlich 7 Tage
Zweimonatliche vollständige Sicherung/täglich inkrementelle Sicherung Täglich 3 Tage
Systemeigener Exchange-Datenschutz Wenn Protokolle nicht mehr erforderlich sind 3 Tage

Natürlich müssen ggf. auch andere Szenarien berücksichtigt werden. Wenn Sie beispielsweise eine DAG (Database Availability Group) bereitstellen, die sich auf zwei Datacenter erstreckt, tritt eine Protokollabschneidung nur auf, wenn die Netzwerkverbindung zwischen den beiden Datencentern betriebsbereit ist und die Datenbankkopien fehlerfrei sind. Wenn Sie wissen, dass die Reparatur einer ausgefallenen WAN-Verbindung 5 Tage dauern könnte, sollten Sie den Schutz vor Sicherungsfehlern entsprechend anpassen.


Für unser Szenario wird angenommen, dass nur sichergestellt werden muss, dass wir 3 Tage mit Protokollabschneidungsfehler unbeschadet überstehen. Wir benötigen also 9.750 : 1024 x 3 = 28,5 GB Speicherplatz für die postfachgenerierten Transaktionsprotokolle.


Zudem müssen wir den Speicherplatz berücksichtigen, der für Postfachverschiebungen in einer ganzen Woche erforderlich ist: 13.888 : 1014 x 7 Tage = 94,9 GB Speicherplatz für Postfachverschiebungsvorgänge.


Alles in allem ist pro Datenbank also 123 GB Speicherplatz für Transaktionsprotokolle erforderlich. Wir sollten auch einen Faktor für eine eventuell höhere Datenmenge in die Berechnung einfließen lassen, um für unvorhergesehene Ereignisse gerüstet zu sein: 123 GB x 1,2 = 148 GB Speicherplatz für Transaktionsprotokolle.


Wenn wir eine spezielle LUN für die Transaktionsprotokolle bereitstellen, reicht eine LUN von 150 GB nicht aus, da der gesamte Speicherplatz belegt werden könnte, wenn Sicherungsfehler auftreten oder sehr viele Postfachverschiebungsvorgänge stattfinden. Normalerweise sollten Sie sicherstellen, dass bei der bereitgestellten LUN nur 80 % der Speicherplatzkapazität genutzt wird. Die entsprechende Formel ist:


LUN-Speicherplatz = [voraussichtliche Speicherplatznutzung] : (1 – [gewünschter freier Speicherplatz in Prozent])


LUN-Speicherplatz = 148 GB : (1 – 0,2) = 148 GB : 0,8 = 185 GB LUN-Speicherplatz für das dedizierte Transaktionsprotokollvolume


Wenn Sie Transaktionsprotokolle auf derselben LUN wie die Datenbank bereitstellen, würden Sie einfach die Speicherplatzanforderungen der Transaktionsprotokolle mit denen der Datenbank kombinieren, um den Wert für die [voraussichtliche Speicherplatznutzung] zu ermitteln.


Wie kann ich verhindern, dass der gesamte Transaktionsprotokoll-Speicherplatz verbraucht wird?


In erster Linie müssen Sie Basiswerte für Ihre Umgebung aufstellen, um auf der Grundlage dieser Basiswerte die typische Protokollgenerierungsrate pro Tag zu ermitteln. Zudem müssen Sie eine Überwachung einrichten und Maßnahmen für generierte Warnungen ergreifen. Die Überwachung sollte auf folgende Szenarien ausgerichtet sein:



  1. Speicherplatz der Transaktionsprotokoll-LUN. Richten Sie mehrere Schwellenwerte und verschiedene Warnungsmechanismen ein. Die erste Warnung sollte generiert werden, wenn 90 % des Speicherplatzes verbraucht wurde. Wenn Sie Ihren typischen Basiswert für die Protokollgenerierung kennen, können Sie beispielsweise einen Schwellenwert einrichten, um benachrichtigt zu werden, wenn dieser Wert um 20 % überschritten wird.
  2. Überwachen Sie den erfolgreichen Abschluss der Sicherungen (wenn Sie nicht den systemeigenen Exchange-Datenschutz verwenden). Sie sollten nicht erst dann von den Sicherungsfehlern erfahren, wenn der Speicherplatz erschöpft ist.
  3. Überwachen Sie die Abschneidungsereignisse im Anwendungsprotokoll.
  4. Überwachen Sie die Replikationsintegrität bei Datenbankkopien. 

Was ist zu tun, wenn die Größe der Transaktionsprotokolle unerwartet zunimmt?


Mein Freud, Mike Lagase, hat einen hervorragenden Artikel zur Problembehandlung für dieses Szenario geschrieben – http://blogs.technet.com/b/mikelag/archive/2009/07/12/troubleshooting-store-log-database-growth-issues.aspx (beachten Sie, dass dieser Artikel vor dem Hintergrund von Exchange 2007 geschrieben wurde, sodass mehrere Tools und/oder Empfehlungen möglicherweise für Exchange 2010 nicht mehr gültig sind). Zusätzlich zu den im Blogbeitrag von Mike genannten Schritten können Sie in Exchange 2010 folgende Aktionen durchführen, um die Ursache für das unerklärliche Wachstum der Transaktionsprotokolle zu finden (herzlichen Dank an Todd Luttinen, der diese Liste zusammengestellt hat):



  1. Sie können das Cmdlet für die Speichernutzungsstatistik (get-StoreUsageStatistics mit DigestCategory = „LogBytes“) verwenden, um die Postfächer zu ermitteln, die Protokolle mit hoher Byteanzahl generieren. Beachten Sie, dass dies nicht immer funktioniert, falls die Protokollbytes nicht vom Postfachinhaber generiert werden oder der Vorgang im Auftrag des Clients (z. B. CopyOnWrite) durchgeführt wird und keine Protokollbytes beinhaltet, die von den Systemdiensten generiert wurden (berichtet in Ereignis-ID 9826). Diese Statistiken stellen eine Zusammenfassung der letzten 10 Minuten an Aktivität für die wichtigsten Postfächer bereit, die Protokollaktivität generieren (bis zu 6 Beispiele beziehen sich auf die letzte Stunde). Die folgende Abbildung veranschaulicht, wie anhand von Speichernutzungsstatistiken die Postfächer ermittelt werden können, die in der letzten Stunde die meisten Protokollbytes generiert haben:

    [PS] C:\>$stats = Get-StoreUsageStatistics –Database <Database Name>
    [PS] C:\>$stats | ? {$_.DigestCategory -eq 'LogBytes'} | group MailboxGuid |sort count -Descending | Select -first 1 -ExpandProperty Group | sort SampleTime | ft -a MailboxGuid,Sample*,Log*













































    MailboxGuid SampleID SampleTime LogRecordCount LogRecordBytes
    c007c87a-e030-4414-b741-9cf61e88b9de 5 11/7/2011 4:25:05 PM 237 274163
    c007c87a-e030-4414-b741-9cf61e88b9de 4 11/7/2011 4:35:05 PM 451 387362
    c007c87a-e030-4414-b741-9cf61e88b9de 3 11/7/2011 4:45:06 PM 483 144999
    c007c87a-e030-4414-b741-9cf61e88b9de 2 11/7/2011 4:55:06 PM 734 293433
    c007c87a-e030-4414-b741-9cf61e88b9de 1 11/7/2011 5:05:06 PM 933 411485
    c007c87a-e030-4414-b741-9cf61e88b9de 0 11/7/2011 5:15:06 PM 247 209987


  2. Es gibt auch Anwendungsereignisse, die für administrative Clients generiert werden (Ereignis-ID 9826). Die folgenden Statistiken stellen 2 Stunden an Aktivität dar:

    Starting from <date/time> service <name> has performed this activity on the server:
    RPC Operations: 24168.
    Database Pages Read: 1329 (of which 629 pages preread).
    Database Pages Updated: 12418 (of which 11555 pages reupdated).
    Database Log Records Generated: 13906.
    Database Log Records Bytes Generated: 660331.
    Time in Server: 19142 ms.
    Time in User Mode: 6100 ms.
    Time in Kernel Mode: 63 ms.


  3. Mit dem Leistungsindikator „MSExchangeIS Client(*)\JET Log Record Bytes/sec“ kann ermittelt werden, welcher Clienttyp die Zunahme der Protokollgröße verursacht.

Ich denke, dass jetzt allen klar ist, wie wichtig eine ausreichende Speicherplatzkapazität ist, um die Verfügbarkeit der Datenbank sicherzustellen. Ich hoffe, dass Ihnen diese Informationen beim Planen der Transportprotokollkapazität helfen.


Ross Smith IV
Principal Program Manager
Exchange Customer Experience



Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter Capacity Planning – Yes Transaction Log Space is Critical to Keeping your Databases Healthy and Mounted


Comments (0)

Skip to main content