In meinen letzten beiden Beiträgen habe ich Möglichkeiten besprochen, wie die Menge des generierten Transaktionsprotokolls reduziert werden kann und wie sichergestellt werden kann, dass das Transaktionsprotokoll immer ordnungsgemäß gelöscht werden kann. In diesem Beitrag möchte ich mit dem Thema Transaktionsprotokollleistung fortfahren und einige Probleme bei der Konfiguration von Transaktionsprotokollen erörtern, die Probleme verursachen können.
Zu viele VLFs
Das Transaktionsprotokoll wird in Blöcke aufgeteilt, die als virtuelle Protokolldateien (VLFs) bezeichnet werden, sodass das Protokollverwaltungssystem leicht nachverfolgen kann, welche Teile des Transaktionsprotokolls zur Wiederverwendung verfügbar sind. Es gibt eine Formel dafür, wie viele VLFs Sie erhalten, wenn Sie Ihr Transaktionsprotokoll erstellen, manuell vergrößern oder automatisch vergrößern:
| Bis zu 1 MB | 2 VLFs, jeweils etwa 1/2 der Gesamtgröße |
|---|---|
| 1 MB bis 64 MB | 4 VLFs, jeweils ungefähr 1/4 der Gesamtgröße |
| 64 MB bis 1 GB | 8 VLFs, jeweils ungefähr 1/8 der Gesamtgröße |
| Mehr als 1 GB | 16 VLFs, jedes etwa 1/16 der Gesamtgröße |
Wenn Sie beispielsweise ein Transaktionsprotokoll mit 8 GB erstellen, erhalten Sie 16 VLFs mit jeweils ungefähr 512 MB. Wenn Sie das Protokoll dann um weitere 4 GB vergrößern, erhalten Sie weitere 16 VLFs mit jeweils etwa 256 MB, also insgesamt 32 VLFs.
Hinweis:Dieser Algorithmus wurde für SQL Server 2014 leicht geändert, um die VLF-Fragmentierungsprobleme zu verringern – Einzelheiten finden Sie in diesem Blogbeitrag
Eine allgemeine bewährte Methode besteht darin, die automatische Protokollvergrößerung auf einen anderen Wert als die standardmäßigen 10 % festzulegen, damit Sie die Pause steuern können, die erforderlich ist, wenn neuer Transaktionsprotokollspeicherplatz mit Null initialisiert wird. Angenommen, Sie erstellen ein 256-MB-Transaktionsprotokoll und stellen die automatische Vergrößerung auf 32 MB ein, und dann wächst das Protokoll auf eine stabile Größe von 16 GB an. In Anbetracht der obigen Formel führt dies dazu, dass Ihr Transaktionsprotokoll mehr als 2.000 VLFs enthält.
Diese vielen VLFs führen wahrscheinlich zu einigen Leistungsproblemen bei Vorgängen, die das Transaktionsprotokoll verarbeiten (z. B. Wiederherstellung nach einem Absturz, Löschen von Protokollen, Protokollsicherungen, Transaktionsreplikation, Datenbankwiederherstellungen). Diese Situation wird als VLF-Fragmentierung bezeichnet. Im Allgemeinen ist jede Anzahl von mehr als tausend VLFs problematisch und muss angegangen werden (das Höchste, von dem ich je gehört habe, sind 1,54 Millionen VLFs in einem Transaktionsprotokoll, das mehr als 1 TB groß war!). P>
Um festzustellen, wie viele VLFs Sie haben, verwenden Sie das undokumentierte (und absolut sichere) DBCC LOGINFO Befehl. Die Anzahl der Ausgabezeilen ist die Anzahl der VLFs in Ihrem Transaktionsprotokoll. Wenn Sie denken, dass Sie zu viele haben, können Sie sie wie folgt reduzieren:
- Erlauben Sie, dass das Protokoll gelöscht wird
- Log manuell verkleinern
- Wiederholen Sie die Schritte 1 und 2, bis das Protokoll eine kleine Größe erreicht (was auf einem ausgelasteten Produktionssystem schwierig sein kann)
- Vergrößern Sie das Protokoll manuell auf die gewünschte Größe, in Schritten von bis zu 8 GB, sodass jede VLF nicht größer als etwa 0,5 GB ist
Weitere Informationen zu VLF-Fragmentierungsproblemen und dem Verfahren zu ihrer Behebung finden Sie unter:
- Microsoft KB-Artikel, der empfiehlt, VLF-Nummern zu reduzieren
- Kann das Wachstum von Protokolldateien DML beeinflussen?
- 8 Schritte zu einem besseren Transaktionsprotokolldurchsatz
Tempdb
Das Transaktionsprotokoll von Tempdb muss wie jede andere Datenbank konfiguriert werden, und es kann wie jede andere Datenbank wachsen. Aber es hat auch ein heimtückisches Verhalten, das Ihnen Probleme bereiten kann.
Wenn eine SQL Server-Instanz aus irgendeinem Grund neu gestartet wird, werden die Daten- und Protokolldateien von tempdb auf die Größe zurückgesetzt, auf die sie zuletzt eingestellt waren. Dies unterscheidet sich von allen anderen Datenbanken, die nach einem Neustart der Instanz auf ihrer aktuellen Größe bleiben.
Dieses Verhalten bedeutet, dass Sie ein ALTER DATABASE ausführen müssen, wenn das tempdb-Transaktionsprotokoll angewachsen ist, um die normale Arbeitslast zu bewältigen um die Größe der Protokolldatei festzulegen, sonst sinkt ihre Größe nach einem Neustart der Instanz und sie muss erneut wachsen. Jedes Mal, wenn eine Protokolldatei wächst oder automatisch wächst, muss der neue Speicherplatz mit Null initialisiert werden, und die Protokollierungsaktivität wird währenddessen angehalten. Wenn Sie also die Größe Ihrer tempdb-Protokolldatei nicht richtig verwalten, zahlen Sie einen Leistungsnachteil, da sie nach jedem Neustart der Instanz anwächst.
Regelmäßige Verkleinerung der Protokolldatei
Ziemlich oft höre ich Leute sagen, dass sie normalerweise das Transaktionsprotokoll einer Datenbank verkleinern, nachdem es durch einen regelmäßigen Vorgang (z. B. einen wöchentlichen Datenimport) gewachsen ist. Das ist nicht gut.
Wie ich oben erklärt habe, gibt es immer dann, wenn das Transaktionsprotokoll wächst oder automatisch wächst, eine Pause, während der neue Teil der Protokolldatei mit Null initialisiert wird. Wenn Sie das Transaktionsprotokoll regelmäßig verkleinern, weil es auf die Größe X anwächst, bedeutet dies, dass Sie regelmäßig unter Leistungsproblemen leiden, da das Transaktionsprotokoll automatisch wieder auf die Größe X anwächst.
Wenn Ihr Transaktionsprotokoll immer weiter auf die Größe X anwächst, lassen Sie es in Ruhe! Stellen Sie es proaktiv auf Größe X ein, verwalten Sie Ihre VLFs wie oben beschrieben, und akzeptieren Sie Größe X als die Größe, die für Ihre normale Arbeitslast erforderlich ist. Ein größeres Transaktionsprotokoll ist kein Problem.
Mehrere Protokolldateien
Es gibt keinen Leistungsgewinn durch das Erstellen mehrerer Protokolldateien für eine Datenbank. Das Hinzufügen einer zweiten Protokolldatei kann jedoch erforderlich sein, wenn die vorhandene Protokolldatei keinen Platz mehr hat und Sie nicht bereit sind, das Löschen des Transaktionsprotokolls zu erzwingen, indem Sie zum einfachen Wiederherstellungsmodell wechseln und einen Prüfpunkt ausführen (da dies die Protokollsicherung unterbricht). Kette).
Ich werde oft gefragt, ob es einen dringenden Grund gibt, die zweite Protokolldatei zu entfernen, oder ob es in Ordnung ist, sie an Ort und Stelle zu lassen. Die Antwort ist, dass Sie es so schnell wie möglich entfernen sollten.
Obwohl die zweite Protokolldatei keine Leistungsprobleme für Ihren Workload verursacht, wirkt sie sich auf die Notfallwiederherstellung aus. Wenn Ihre Datenbank aus irgendeinem Grund zerstört wird, müssen Sie sie von Grund auf wiederherstellen. Die erste Phase jeder Wiederherstellungssequenz besteht darin, die Daten- und Protokolldateien zu erstellen, falls sie nicht vorhanden sind.
Sie können die Datendatei fast augenblicklich erstellen, indem Sie die sofortige Dateiinitialisierung aktivieren, die die Nullinitialisierung überspringt, aber das gilt nicht für Protokolldateien. Das bedeutet, dass die Wiederherstellung alle Protokolldateien erstellen muss, die vorhanden waren, als die vollständige Sicherung erstellt wurde (oder die während des Zeitraums erstellt wurden, der von einer Transaktionsprotokollsicherung abgedeckt wird) und sie mit Null initialisieren muss. Wenn Sie eine zweite Protokolldatei erstellt und vergessen haben, sie erneut zu löschen, wird die Nullinitialisierung während eines Notfallwiederherstellungsvorgangs die Gesamtausfallzeit verlängern. Dies ist kein Workload-Leistungsproblem, wirkt sich jedoch auf die Verfügbarkeit des Servers als Ganzes aus.
Zurücksetzen von einem Datenbank-Snapshot
Das letzte Problem in meiner Liste ist eigentlich ein Fehler in SQL Server. Wenn Sie einen Datenbank-Snapshot verwenden, um schnell zu einem bekannten Zeitpunkt zurückzukehren, ohne Sicherungen wiederherstellen zu müssen (bekannt als Wiederherstellung vom Snapshot), können Sie viel Zeit sparen. Es gibt jedoch einen großen Nachteil.
Wenn die Datenbank vom Datenbank-Snapshot zurückgesetzt wird, wird das Transaktionsprotokoll mit zwei 0,25-MB-VLFs neu erstellt. Das bedeutet, dass Sie Ihr Transaktionsprotokoll wieder auf seine optimale Größe und Anzahl von VLFs vergrößern müssen (oder es wird automatisch wachsen), mit all den Null-Initialisierungs- und Workload-Pausen, die ich zuvor besprochen habe. Eindeutig nicht das gewünschte Verhalten.
Zusammenfassung
Wie Sie diesem Beitrag und meinen beiden vorherigen Beiträgen entnehmen können, gibt es viele Dinge, die zu einer schlechten Leistung des Transaktionsprotokolls führen können, was sich wiederum auf die Leistung Ihrer gesamten Arbeitslast auswirkt.
Wenn Sie sich um all diese Dinge kümmern können, haben Sie gesunde Transaktionsprotokolle. Aber das ist noch nicht alles, denn Sie müssen sicherstellen, dass Sie Ihre Transaktionsprotokolle überwachen, damit Sie auf Dinge wie automatisches Wachstum und übermäßige Lese- und Schreib-I/O-Latenzen aufmerksam gemacht werden. Wie das geht, erkläre ich in einem zukünftigen Beitrag.
