Transaktionsprotokollüberwachung

Im letzten Jahr habe ich mehrere Male auf SQLPerformance.com über Probleme mit der Transaktionsprotokollleistung gebloggt (siehe hier) und ich habe versprochen, die Überwachung von Transaktionsprotokollen zu diskutieren, was ich in diesem Beitrag tun werde. Ich werde einige der Metriken vorstellen, die Sie verfolgen können, warum Sie sich darum kümmern sollten, und Ratschläge zum Umgang mit dem angegebenen Problem geben.

DMVs

Die einfachste Möglichkeit, Transaktionsprotokoll-E/A-Latenzen zu überwachen, ist die Verwendung von sys.dm_io_virtual_file_stats DMV. Sie müssen etwas rechnen, um nützliche Ergebnisse zu erhalten, und Sie können Beispielcode im VirtualFileStats.sql-Skript in dieser Demo-Zip-Datei abrufen. Sie möchten wirklich Schreiblatenzen von weniger als 5 ms für das Transaktionsprotokoll sehen.

Anfang November habe ich die Ergebnisse einer Umfrage gebloggt, die die Latenzen von Transaktionsprotokollen und tempdb-Datendateien für mehr als 25.000 Datenbanken auf der ganzen Welt zeigt (siehe hier), wobei 80 % der Datenbanken die 5-ms-Marke oder weniger für die Latenz beim Schreiben von Transaktionsprotokollen erreichen. P>

Wenn Ihre Schreiblatenz höher als 5 ms ist, können Sie:

• Arbeiten Sie daran, die Menge der generierten Protokolle und/oder die Anzahl der Protokolllöschungen zu reduzieren, die durch winzige Transaktionen auftreten, wie ich in früheren Beiträgen beschrieben habe.
• Folgen Sie einigen der Schritte zur Fehlerbehebung, die ich oben im Umfrage-Blogbeitrag beschreibe.
• Wechseln Sie zu einem schnelleren E/A-Subsystem und denken Sie daran, dass Sie zwei in einer RAID-1-Konfiguration verwenden müssen, wenn Sie sich für eine SSD entscheiden.

Eine andere Sache, die Sie beobachten können, ist sicherzustellen, dass Sie nicht die harte Grenze von 32 ausstehenden Schreib-I/Os für das Transaktionsprotokoll jeder Datenbank in 2008 R2 und früher erreichen (ab SQL Server 2012 auf 2012 angehoben). Sie können dies versuchen, indem Sie sich die Physical Disk/Avg. Disk Write Queue Length, aber das gilt für ein ganzes Volume, nicht pro Datei. Wenn sich also neben der Protokolldatei, an der Sie interessiert sind, noch etwas anderes auf dem Volume befindet, erhalten Sie keine gültige Zahl. Eine bessere Möglichkeit besteht darin, die Ergebnisse der sys.dm_io_pending_io_requests zu aggregieren DMV, das alle ausstehenden I/Os auflistet. Hier ist ein Code dafür:

SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

Sie können dies leicht ändern, um nur Ergebnisse für Protokolldateien anzuzeigen (Filtern Sie nach type_desc ='LOG' ) und nur für die Datenbank-ID, an der Sie interessiert sind.

Wenn Sie feststellen, dass Sie die 32-Grenze für eine bestimmte Datenbank erreichen, haben Sie folgende Möglichkeiten:

• Reduzieren Sie die Anzahl der Log-Flushes, indem Sie die Anzahl kleiner Transaktionen reduzieren und auf Dinge wie Seitenaufteilungen und ungenutzte/doppelte Indizes achten, die während Datenänderungsvorgängen geändert werden. In diesem Blogbeitrag können Sie mehr über die Optimierung von Log-Flushes lesen
• Versuchen Sie es mit einem schnelleren E/A-Subsystem
• Upgrade auf SQL Server 2012 oder höher, wobei das Limit 112 ist
• Probieren Sie die delayed durability feature aus DMV, das in SQL Server 2014 hinzugefügt wurde
• Verteilen Sie als letzten Ausweg die Arbeitslast auf mehrere Datenbanken oder Server

Wenn Sie sehen möchten, wie viel Transaktionsprotokoll von Ihren Transaktionen generiert wird, können Sie sys.dm_tran_database_transactions verwenden DMV, in ähnlichem Code wie unten:

BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

Sie werden möglicherweise sehr überrascht sein, wie viel Protokoll generiert wird, insbesondere in tempdb für Code, der temporäre Objekte verwendet. Und natürlich kann das Transaktionsprotokoll von tempdb genau wie bei einer Benutzerdatenbank ein Engpass sein.

Leistungsüberwachungszähler

Die protokollbezogenen Leistungsindikatoren befinden sich alle im Datenbankleistungsobjekt. Hier sind einige der wichtigsten, die Sie beobachten sollten (entweder mit dem Leistungsmonitor selbst oder mit SQL Agent-Warnungen oder mit dem sys.dm_os_performance_counters DMV oder in Ihrem bevorzugten Überwachungstool eines Drittanbieters):

Protokollwachstum

Sie möchten nicht, dass dieser Zähler ansteigt, da dies anzeigt, dass in der Datenbank etwas passiert, das dazu führt, dass mehr Transaktionsprotokolle generiert werden, als derzeit Speicherplatz vorhanden ist. Dies impliziert, dass das Transaktionsprotokoll nicht gelöscht werden kann, also sollten Sie die Ursache untersuchen, indem Sie das Feld log_reuse_wait_desc von sys.databases abfragen und die erforderlichen Maßnahmen ergreifen (weitere Einzelheiten finden Sie im Thema Faktoren, die das Abschneiden von Protokollen verzögern können, in der Onlinedokumentation). Ein Beispielcode wäre:

SELECT [log_reuse_wait_desc]
	FROM sys.databases
	WHERE [name] = N'YourDB';
GO

Immer wenn ein Protokollwachstum auftritt, muss der neu zugewiesene Teil des Transaktionsprotokolls auf Null gesetzt werden, und es werden weitere virtuelle Protokolldateien hinzugefügt – was beides Probleme verursachen kann, wie ich zuvor gebloggt habe.

Protokollschwund

Wenn Sie nicht die Person sind, die den Verkleinerungsvorgang durchführt, um ein außer Kontrolle geratenes Transaktionsprotokoll wieder unter Kontrolle zu bringen, möchten Sie nicht, dass dieser Zähler steigt. Wenn jemand das Transaktionsprotokoll einfach ohne triftigen Grund verkleinert, wird es wahrscheinlich wieder wachsen und Probleme verursachen, über die ich zuvor gebloggt habe.

Verwendetes Protokoll in Prozent

Sie sollten diesen Zähler überwachen und sich Sorgen machen, wenn der Wert über 90 % steigt, da dies darauf hindeutet, dass ein Protokollwachstum unmittelbar bevorstehen könnte und das Transaktionsprotokoll nicht korrekt gelöscht werden kann, wie ich oben besprochen habe.

Löschwartezeiten/Sek. protokollieren

Dieser Wert soll gleich bleiben oder sinken. Wenn es zunimmt, bedeutet dies, dass Sie einen E/A-Subsystem-Engpass oder einen Engpass innerhalb des Protokoll-Flush-Mechanismus haben, weil Sie viele kleine Protokollteile leeren. Eine Erhöhung hier kann auch mit dem Erreichen der 32 ausstehenden I/Os für das Protokoll korrelieren. Siehe die Diskussion von sys.dm_io_pending_io_requests oben für weitere Details.

Gelöschte Protokollbytes/s und Protokolllöschungen/s

Mit diesen beiden Zählern können Sie die durchschnittliche Log-Flush-Größe ermitteln, indem Sie den ersten Zähler durch den zweiten dividieren. Das Ergebnis ist ein Wert zwischen 512 und 61440 (die minimale bzw. maximale Größe eines Log-Flush). Ein niedrigerer Wert korreliert eher mit steigenden Log Flush Waits/sec. Siehe auch hier die Diskussion von sys.dm_io_pending_io_requests oben für weitere Details.

Erweiterte Veranstaltungen

Für die Fortgeschrittenen unter Ihnen gibt es einige erweiterte Ereignisse, mit denen Sie beobachten können, was mit dem Protokoll vor sich geht. Ich empfehle Ihnen, mit der Vorlage „E/A-Verfolgung der Datenbankprotokolldatei“ in SQL Server 2012 SSMS zu beginnen. Sie können dazu gelangen, indem Sie zum Objekt-Explorer und dann zu Ihrer Instanz -> Verwaltung -> Erweiterte Ereignisse gehen und mit der rechten Maustaste auf Sitzungen klicken, um den Assistenten für neue Sitzungen auszuwählen. Geben Sie im angezeigten Fenster einen Sitzungsnamen ein und wählen Sie die Tracking-Vorlage aus der Dropdown-Liste aus. Drücken Sie dann Strg+Umschalt+N und die Sitzung wird in ein Abfragefenster geschrieben. Die Details zu allem, was darin enthalten ist, würden leider den Rahmen dieses Beitrags sprengen, aber die Vorlagenbeschreibung ist ziemlich erklärend:

Es gibt auch ein neues erweitertes Ereignis in SQL Server 2012 namens transaction_log, das verwendet werden kann, um alle möglichen interessanten Analysen darüber durchzuführen, welche Protokolleinträge generiert werden. Das ist definitiv ein Thema, das ich in einem zukünftigen Beitrag behandeln werde.

Zusammenfassung

Angesichts all der oben genannten Informationen sollten Sie in der Lage sein, ein ziemlich gutes Transaktionsprotokoll-Überwachungssystem zu entwickeln. Der Zustand des Transaktionsprotokolls ist von größter Bedeutung, um sicherzustellen, dass Ihre Workload die gewünschte Leistung erbringt, und ich hoffe, die vier Posts in dieser Reihe (plus alle anderen Links) haben Ihnen geholfen, die Gesamtleistung Ihrer SQL Server-Umgebung zu verbessern.