Transactielogboekbewaking

Het afgelopen jaar heb ik verschillende keren op SQLPerformance.com geblogd over prestatieproblemen met transactielogboeken (zie hier) en ik heb beloofd om het monitoren van transactielogboeken te bespreken, wat ik in dit bericht zal doen. Ik ga enkele van de statistieken presenteren die u kunt volgen, waarom u er iets om zou moeten geven, en enig advies om het aangegeven probleem aan te pakken.

DMV's

De eenvoudigste manier om de I/O-latenties van transactielogboeken te controleren, is door de sys.dm_io_virtual_file_stats te gebruiken DMV. U moet wat rekenwerk uitvoeren om bruikbare resultaten te krijgen en u kunt een voorbeeldcode krijgen in het VirtualFileStats.sql-script in dit demo-zipbestand. U wilt echt schrijfvertragingen van minder dan 5 ms zien voor het transactielogboek.

Eerder in november heb ik de resultaten geblogd van een onderzoek met latenties van transactielogboeken en tempdb-gegevensbestanden voor meer dan 25.000 databases over de hele wereld (zie hier), waarbij 80% van de databases de 5 ms of minder bereikt voor de latentie voor het schrijven van transactielogboeken.

Als uw schrijflatentie hoger is dan 5 ms, kunt u:

• Werk aan het verminderen van de hoeveelheid logboek die wordt gegenereerd en/of het aantal logboekspoelingen dat optreedt bij kleine transacties, zoals ik in eerdere berichten heb beschreven.
• Volg enkele van de stappen voor probleemoplossing die ik beschrijf in de bovenstaande blogpost over het onderzoek.
• Ga naar een sneller I/O-subsysteem en onthoud dat als u besluit een SSD te gebruiken, u er twee moet gebruiken in een RAID-1-configuratie.

Een ander ding dat u kunt doen, is ervoor zorgen dat u de harde limiet van 32 uitstaande schrijf-I/O's voor het transactielogboek van elke database in 2008 R2 en eerder (verhoogd naar 2012 vanaf SQL Server 2012 en later) niet bereikt. U kunt dit proberen door te kijken naar de Physical Disk/Avg. Lengte schijfschrijfwachtrij, maar dat is voor een heel volume, niet per bestand, dus als er iets anders op het volume staat dan het logbestand waarin u geïnteresseerd bent, krijgt u geen geldig nummer. Een betere manier is om de resultaten van de sys.dm_io_pending_io_requests te verzamelen DMV, waarin alle uitstaande I/O's worden vermeld. Hier is wat code om dat te doen:

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];

U kunt dit eenvoudig wijzigen om alleen resultaten voor logbestanden weer te geven (filter op type_desc ='LOG' ) en alleen voor de database-ID waarin u geïnteresseerd bent.

Als u merkt dat u de 32-limiet voor een bepaalde database bereikt, kunt u:

• Verminder het aantal logboekspoelingen door het aantal kleine transacties te verminderen en uit te kijken voor zaken als paginasplitsingen en ongebruikte/dubbele indexen die worden gewijzigd tijdens gegevenswijzigingsbewerkingen. In deze blogpost lees je meer over het optimaliseren van log flushes
• Probeer een sneller I/O-subsysteem te gebruiken
• Upgrade naar SQL Server 2012 of hoger, waarbij de limiet 112 is
• Probeer de functie delayed durability feature DMV die is toegevoegd in SQL Server 2014
• Verdeel als laatste redmiddel de werklast over meerdere databases of servers

Als u wilt zien hoeveel transactielogboek uw transacties genereren, kunt u de sys.dm_tran_database_transactions gebruiken DMV, in code vergelijkbaar met die hieronder:

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

Het zal je misschien verbazen hoeveel log er wordt gegenereerd, vooral in tempdb voor code die gebruikmaakt van tijdelijke objecten. En natuurlijk kan het transactielogboek van tempdb een knelpunt zijn, net als voor een gebruikersdatabase.

Prestatiemonitortellers

De logboekgerelateerde prestatiemeteritems bevinden zich allemaal in het prestatieobject Databases. Hier zijn enkele van de belangrijkste om te bekijken (met Performance Monitor zelf, of met SQL Agent-waarschuwingen, of met behulp van de sys.dm_os_performance_counters DMV, of in uw favoriete monitoringtool van derden):

Log groei

U wilt niet dat deze teller stijgt, want dat zegt dat er iets in de database gebeurt dat ervoor zorgt dat er meer transactielogboek wordt gegenereerd dan er momenteel ruimte is. Dit houdt in dat het transactielogboek niet kan worden gewist, dus u moet de oorzaak onderzoeken door het veld log_reuse_wait_desc van sys.databases te doorzoeken en de benodigde actie te ondernemen (zie het Books Online-onderwerp Factoren die het afbreken van logbestanden kunnen vertragen voor meer informatie). Een voorbeeldcode zou zijn:

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

Telkens wanneer een logboekgroei optreedt, moet het nieuw toegewezen deel van het transactielogboek op nul worden gezet en worden er meer virtuele logbestanden toegevoegd - die beide problemen kunnen veroorzaken, zoals ik eerder heb geblogd.

Log krimpt

Tenzij u de persoon bent die de krimpbewerking uitvoert om een ​​uit de hand gelopen transactielogboek weer onder controle te krijgen, wilt u deze teller niet zien stijgen. Als iemand het transactielogboek zonder goede reden verkleint, zal het waarschijnlijk weer groeien en problemen veroorzaken, zoals ik eerder heb geblogd.

Percentage logboek gebruikt

U moet deze teller in de gaten houden en u zorgen maken als de waarde hoger wordt dan 90%, omdat dit aangeeft dat er een logboekgroei op handen is en het transactielogboek niet correct kan worden gewist, zoals ik hierboven heb besproken.

Log Flush wacht/sec

U wilt dat deze waarde gelijk blijft of afneemt. Als het toeneemt, betekent dit dat u een I/O-subsysteemknelpunt hebt of een knelpunt in het houtspoelmechanisme omdat u veel kleine porties hout doorspoelt. Een toename hier kan ook correleren met het bereiken van de 32 openstaande I/O's voor het logboek. Zie de bespreking van sys.dm_io_pending_io_requests hierboven voor meer details.

Logbytes gespoeld/sec en log spoelen/sec

Met deze twee tellers kunt u de gemiddelde grootte van de logspoeling berekenen door de eerste teller door de tweede te delen. Het resultaat is een waarde tussen 512 en 61440 (respectievelijk de minimum- en maximumgrootte van een logspoeling). Een lagere waarde correleert waarschijnlijk met toenemende Log Flush Waits/sec. Nogmaals, zie de bespreking van sys.dm_io_pending_io_requests hierboven voor meer details.

Uitgebreide evenementen

Voor de meer gevorderden onder jullie zijn er enkele uitgebreide evenementen die je kunt gebruiken om te kijken wat er met het logboek gebeurt. Ik raad u aan om te beginnen met de sjabloon Database Log File IO Tracking in SQL Server 2012 SSMS. U kunt dit bereiken door naar Objectverkenner te gaan en vervolgens naar uw exemplaar -> Beheer -> Uitgebreide gebeurtenissen en met de rechtermuisknop op Sessies te klikken om Wizard Nieuwe sessie te selecteren. Typ in het venster dat verschijnt een sessienaam en selecteer de trackingsjabloon in de vervolgkeuzelijst. Druk vervolgens op Ctrl+Shift+N en de sessie wordt gescript naar een queryvenster. De details van alles daarin vallen helaas buiten het bestek van dit bericht, maar de sjabloonbeschrijving is behoorlijk verklarend:

Er is ook een nieuwe Extended Event in SQL Server 2012 genaamd transaction_log die kan worden gebruikt om allerlei interessante analyses uit te voeren van welke logboekrecords worden gegenereerd. Dat is zeker een onderwerp dat ik in een volgende post zal behandelen.

Samenvatting

Gezien alle bovenstaande informatie, zou u een redelijk goed monitoringsysteem voor transactielogboeken moeten kunnen bedenken. De status van het transactielogboek is van het allergrootste belang om ervoor te zorgen dat uw werkbelasting naar behoren presteert en ik hoop dat de vier berichten in deze serie (plus alle andere links) u hebben geholpen om de algehele prestaties van uw SQL Server-omgeving te verbeteren.