In meinem vorherigen Beitrag zur Rationalisierung der Vorgänge des Transaktionsprotokolls habe ich zwei der häufigsten Ursachen für die Generierung zusätzlicher Protokolldatensätze besprochen:Totgewicht durch ungenutzte Nonclustered-Indizes und Seitenaufteilungsvorgänge (die eine Indexfragmentierung verursachen). Angenommen, Sie haben diesen Beitrag gelesen, ich habe erwähnt, dass es subtilere Probleme gibt, die sich nachteilig auf die Leistung des Transaktionsprotokolls auswirken können, und ich werde diese hier behandeln.
Viele, viele kleine Transaktionen
Von Zeit zu Zeit schreibt SQL Server einen Teil des Transaktionsprotokolls auf die Festplatte. Ein Log-Flush findet immer dann statt, wenn:
- Ein Transaktions-Commit-Log-Datensatz wird generiert.
- Am Ende eines Transaktions-Rollbacks wird ein Transaktionsabbruch-Protokollsatz generiert.
- 60 KB an Protokolldatensätzen wurden seit der letzten Protokolllöschung generiert.
Die kleinstmögliche Protokolllöschung ist ein einzelner 512-Byte-Protokollblock. Wenn alle Transaktionen in einer Arbeitslast sehr klein sind (z. B. Einfügen einer einzelnen, kleinen Tabellenzeile), treten viele minimal große Protokolllöschungen auf. Log-Flushes werden asynchron durchgeführt, um einen angemessenen Transaktionslog-Durchsatz zu ermöglichen, aber es gibt ein festes Limit von 32 gleichzeitigen Log-Flush-I/Os gleichzeitig (angehoben auf 112 auf SQL Server 2012).
Dies kann zwei mögliche Auswirkungen haben:
- Auf einem E/A-Subsystem mit langsamer Leistung könnte das Volumen winziger Transaktionsprotokollschreibvorgänge das E/A-Subsystem überfordern, was zu Schreibvorgängen mit hoher Latenz und einer anschließenden Verschlechterung des Transaktionsprotokolldurchsatzes führen kann. Diese Situation kann durch hohe Schreiblatenzen für die Transaktionsprotokolldatei in der Ausgabe von sys.dm_io_virtual_file_stats identifiziert werden (siehe die Demo-Links oben im vorherigen Post)
- Auf einem Hochleistungs-I/O-Subsystem können die Schreibvorgänge extrem schnell abgeschlossen werden, aber die Begrenzung von 32 gleichzeitigen Log-Flush-I/Os erzeugt einen Engpass, wenn versucht wird, die Log-Einträge auf der Festplatte dauerhaft zu machen. Diese Situation kann durch niedrige Schreiblatenzen und eine nahezu konstante Anzahl ausstehender Transaktionsprotokollschreibvorgänge in der Nähe von 32 in der aggregierten Ausgabe von sys.dm_io_pending_io_requests identifiziert werden (siehe dieselben Demo-Links).
In beiden Fällen kann das Verlängern von Transaktionen (was sehr kontraintuitiv ist!) die Häufigkeit von Transaktionslog-Flushes reduzieren und die Leistung steigern. Außerdem kann in Fall Nr. 1 der Wechsel zu einem leistungsstärkeren E/A-Subsystem hilfreich sein – kann aber zu Fall Nr. 2 führen. Wenn in Fall 2 die Transaktionen nicht länger durchgeführt werden können, besteht die einzige Alternative darin, die Arbeitslast auf mehrere Datenbanken aufzuteilen, um das feste Limit von 32 gleichzeitigen Log-Flush-I/Os zu umgehen, oder auf SQL Server 2012 oder höher zu aktualisieren.
Automatisches Wachstum des Transaktionsprotokolls
Immer wenn dem Transaktionsprotokoll neuer Speicherplatz hinzugefügt wird, muss es mit Nullen initialisiert werden (Nullen werden geschrieben, um die vorherige Verwendung dieses Teils der Festplatte zu überschreiben), unabhängig davon, ob die Funktion zur sofortigen Dateiinitialisierung aktiviert ist oder nicht. Dies gilt für die Erstellung, das manuelle Wachstum und das automatische Wachstum des Transaktionsprotokolls. Während die Nullinitialisierung stattfindet, können Protokolldatensätze nicht in das Protokoll geleert werden, sodass die automatische Vergrößerung während einer Workload, die Daten ändert, zu einem merklichen Rückgang des Durchsatzes führen kann, insbesondere wenn die Größe der automatischen Vergrößerung auf groß eingestellt ist ( B. Gigabyte, oder belassen Sie den Standardwert von 10 %).
Automatisches Wachstum sollte daher nach Möglichkeit vermieden werden, indem das Transaktionsprotokoll gelöscht wird, damit immer freier Speicherplatz vorhanden ist, der für neue Protokolleinträge wiederverwendet werden kann. Das Löschen des Transaktionsprotokolls (auch bekannt als Abschneiden des Transaktionsprotokolls, nicht zu verwechseln mit dem Verkleinern des Transaktionsprotokolls) wird durch Transaktionsprotokollsicherungen durchgeführt, wenn der vollständige oder massenprotokollierte Wiederherstellungsmodus verwendet wird, und durch Prüfpunkte, wenn der einfache Wiederherstellungsmodus verwendet wird.
Das Löschen des Protokolls kann nur erfolgen, wenn die Protokolldatensätze im Abschnitt des Transaktionsprotokolls nicht gelöscht werden müssen. Ein häufiges Problem, das das Löschen von Protokollen verhindert, sind Transaktionen mit langer Laufzeit. Bis eine Transaktion festgeschrieben oder zurückgesetzt wird, sind alle Protokolldatensätze ab dem Beginn der Transaktion erforderlich, falls die Transaktion zurückgesetzt wird – einschließlich aller Protokolldatensätze von anderen Transaktionen, die mit denen der lang andauernden Transaktion durchsetzt sind. Transaktionen mit langer Laufzeit können beispielsweise auf schlechtes Design, Code, der auf menschliche Eingaben wartet, oder die unsachgemäße Verwendung verschachtelter Transaktionen zurückzuführen sein. All dies kann vermieden werden, sobald es als Problem erkannt wird.
Hier und hier können Sie mehr darüber lesen.
Hochverfügbarkeitsfunktionen
Einige Hochverfügbarkeitsfunktionen können auch das Löschen des Transaktionsprotokolls verzögern:
- Datenbankspiegelung und Verfügbarkeitsgruppen können bei asynchroner Ausführung eine Warteschlange mit Protokolldatensätzen aufbauen, die noch nicht an die redundante Datenbankkopie gesendet wurden. Diese Protokolldatensätze müssen aufbewahrt werden, bis sie gesendet werden, was das Löschen des Transaktionsprotokolls verzögert.
- Transaktionsreplikation (und auch Change Data Capture) basiert auf einem Auftrag des Protokollleseagenten, um das Transaktionsprotokoll regelmäßig nach Transaktionen zu durchsuchen, die eine in einer Replikationsveröffentlichung enthaltene Tabelle ändern. Wenn der Protokolllese-Agent aus irgendeinem Grund in Verzug gerät oder absichtlich selten ausgeführt wird, müssen alle Protokolldatensätze, die nicht von dem Job gescannt wurden, aufbewahrt werden, wodurch das Löschen des Transaktionsprotokolls verzögert wird.
Bei Ausführung im synchronen Modus können Datenbankspiegelung und Verfügbarkeitsgruppen andere Probleme mit dem Protokollierungsmechanismus verursachen. Am Beispiel der synchronen Datenbankspiegelung kann jede Transaktion, die auf dem Prinzipal festschreibt, nicht tatsächlich an den Benutzer oder die Anwendung zurückkehren, bis alle von ihr generierten Protokolldatensätze erfolgreich an den Spiegelserver gesendet wurden, wodurch eine Festschreibungsverzögerung auf dem Prinzipal entsteht. Wenn die durchschnittliche Transaktionsgröße lang und die Verzögerung kurz ist, fällt dies möglicherweise nicht auf, aber wenn die durchschnittliche Transaktion sehr kurz und die Verzögerung ziemlich lang ist, kann sich dies spürbar auf den Workload-Durchsatz auswirken. In diesem Fall müssen entweder die Leistungsziele der Workload geändert, die Hochverfügbarkeitstechnologie in den asynchronen Modus geändert oder die Netzwerkbandbreite und -geschwindigkeit zwischen der Haupt- und der redundanten Datenbank erhöht werden.
Übrigens kann die gleiche Art von Problem auftreten, wenn das E/A-Subsystem selbst synchron gespiegelt wird – mit einer potenziellen Verzögerung für alle Schreibvorgänge, die SQL Server durchführt.
Zusammenfassung
Wie Sie sehen können, geht es bei der Leistung von Transaktionsprotokollen nicht nur darum, dass zusätzliche Transaktionsprotokolldatensätze generiert werden – es gibt auch viele Umgebungsfaktoren, die tiefgreifende Auswirkungen haben können.
Das Fazit ist, dass der Zustand und die Leistung des Transaktionsprotokolls von größter Bedeutung für die Aufrechterhaltung der Gesamtleistung der Arbeitslast sind. In diesen beiden Beiträgen habe ich die Hauptursachen für Leistungsprobleme beim Transaktionsprotokoll detailliert beschrieben, sodass Sie hoffentlich in der Lage sein werden, alle Probleme zu identifizieren und zu beheben.
Wenn Sie mehr über Transaktionsprotokolloperationen und Leistungsoptimierung erfahren möchten, empfehle ich Ihnen, sich meinen 7,5-stündigen Online-Schulungskurs zu Protokollierung, Wiederherstellung und Transaktionsprotokoll anzusehen, der über Pluralsight verfügbar ist.
