Overvågning af transaktionslog

I løbet af det sidste år har jeg blogget flere gange på SQLPerformance.com om transaktionslog-ydelsesproblemer (se her), og jeg lovede at diskutere transaktionslogovervågning, hvilket jeg vil gøre i dette indlæg. Jeg vil præsentere nogle af de målinger, du kan spore, hvorfor du bør bekymre dig, og alle råd til at håndtere det angivne problem.

DMV'er

Den nemmeste måde at overvåge transaktionslog I/O-forsinkelser på er at bruge sys.dm_io_virtual_file_stats DMV. Du bliver nødt til at udføre noget matematik for at få nyttige resultater, og du kan få noget eksempelkode i VirtualFileStats.sql-scriptet i denne demo-zip-fil. Du ønsker virkelig at se skriveforsinkelser på mindre end 5ms for transaktionsloggen.

Tidligere i november bloggede jeg resultaterne af en undersøgelse, der viste transaktionslog- og tempdb-datafilforsinkelser for mere end 25.000 databaser rundt om i verden (se her), hvor 80 % af databaserne rammer 5 ms eller mindre for skrivelatens for transaktionslog.

Hvis din skriveforsinkelse er højere end 5ms, kan du:

• Arbejd på at reducere mængden af ​​log, der genereres, og/eller mængden af ​​log-flush, der opstår fra små transaktioner, som jeg har beskrevet i tidligere indlæg.
• Følg nogle af de fejlfindingstrin, jeg beskriver i undersøgelsens blogindlæg ovenfor.
• Flyt til et hurtigere I/O-undersystem, og husk, at hvis du beslutter dig for at bruge en SSD, skal du bruge to i en RAID-1-konfiguration.

En anden ting, du kan, er at se for at sikre, at du ikke når den hårde grænse på 32 udestående skrive-I/O'er for hver databases transaktionslog i 2008 R2 og før (forhøjet til 2012 fra SQL Server 2012 og fremefter). Du kan prøve at gøre dette ved at se på den fysiske disk/Gns. Diskskrivningskølængde, men det er for en hel volumen, ikke pr. fil, så hvis der er andet på diskenheden end den logfil, du er interesseret i, vil det ikke give dig et gyldigt nummer. En bedre måde er at samle resultaterne af sys.dm_io_pending_io_requests DMV, som viser alle udestående I/O'er. Her er noget kode til at gøre det:

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

Du kan nemt ændre dette til kun at vise resultater for logfiler (filter på type_desc ='LOG' ) og kun for det database-id, du er interesseret i.

Hvis du opdager, at du rammer grænsen på 32 for en bestemt database, kan du:

• Reducer mængden af ​​logudskydelser ved at reducere antallet af små transaktioner og passe på ting som sideopdelinger og ubrugte/duplikerede indekser, der ændres under dataændringsoperationer. Du kan læse mere om optimering af log flushes i dette blogindlæg
• Prøv at bruge et hurtigere I/O-undersystem
• Opgrader til SQL Server 2012 eller højere, hvor grænsen er 112
• Prøv funktionen delayed durability feature DMV, der blev tilføjet i SQL Server 2014
• Som en sidste udvej skal du dele arbejdsbyrden over flere databaser eller servere

Hvis du er interesseret i at se, hvor meget transaktionslog, der genereres af dine transaktioner, kan du bruge sys.dm_tran_database_transactions DMV, i kode svarende til nedenstående:

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

Du kan blive meget overrasket over, hvor meget log, der genereres, især i tempdb for kode, der gør brug af midlertidige objekter. Og selvfølgelig kan tempdbs transaktionslog være en flaskehals ligesom for en brugerdatabase.

Performance Monitor-tællere

De log-relaterede ydeevnetællere er alle i Databases performance-objektet. Her er nogle af de vigtigste at se (enten med selve Performance Monitor eller ved at bruge SQL Agent-advarsler eller ved at bruge sys.dm_os_performance_counters DMV eller i dit foretrukne tredjepartsovervågningsværktøj):

Logvækst

Du ønsker ikke at se denne tæller stige, da det siger, at der sker noget i databasen, der forårsager, at der genereres mere transaktionslog, end der er aktuel plads. Det indebærer, at transaktionsloggen ikke er i stand til at rydde, så du bør undersøge årsagen ved at forespørge i log_reuse_wait_desc-feltet i sys.databases og tage de nødvendige handlinger (se Books Online-emnet Faktorer, der kan forsinke logtrunkering for flere detaljer). Nogle eksempler på kode ville være:

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

Når der sker en logvækst, skal den nyligt tildelte del af transaktionsloggen nulstilles, plus at der tilføjes flere virtuelle logfiler – som begge kan forårsage problemer, som jeg tidligere bloggede om.

Log krymper

Medmindre du er den person, der udfører krympeoperationen for at bringe en transaktionslog uden for kontrol igen under kontrol, ønsker du ikke at se denne tæller stige. Hvis nogen bare formindsker transaktionsloggen uden god grund, vil den sandsynligvis vokse igen, hvilket forårsager problemer, som jeg bloggede om tidligere.

Procent log brugt

Du bør overvåge denne tæller og være bekymret, hvis værdien bliver højere end 90 %, da det indikerer, at en logvækst kan være nært forestående, og transaktionsloggen ikke er i stand til at rydde korrekt, som jeg diskuterede ovenfor.

Log skylleventer/sek.

Du ønsker, at denne værdi skal forblive den samme eller falde. Hvis det stiger, betyder det, at du har en I/O-undersystem-flaskehals eller en flaskehals inde i log-skyllemekanismen, fordi du skyller mange små portioner af log. En stigning her kan også korrelere med at ramme de 32 udestående I/O'er for loggen. Se diskussionen om sys.dm_io_pending_io_requests ovenfor for flere detaljer.

Logbytes tømmes/sek. og log tømmes/sek.

Disse to tællere giver dig mulighed for at finde ud af den gennemsnitlige skyllestørrelse ved at dividere den første tæller med den anden. Resultatet vil være en værdi mellem 512 og 61440 (hhv. minimums- og maksimumstørrelsen for en træskylning). En lavere værdi er mere tilbøjelig til at korrelere med stigende logskylleventer/sek. Se igen diskussionen om sys.dm_io_pending_io_requests ovenfor for flere detaljer.

Udvidede begivenheder

For de mere avancerede blandt jer er der nogle udvidede begivenheder, som du kan bruge til at se, hvad der sker med loggen. Jeg anbefaler, at du starter med at bruge databaselogfilens IO-sporingsskabelon i SQL Server 2012 SSMS. Du kan komme til dette ved at gå til Object Explorer og derefter din instans -> Management -> Extended Events og højreklikke på Sessions for at vælge New Session Wizard. Indtast et sessionsnavn i det vindue, der kommer op, og vælg sporingsskabelonen fra rullemenuen. Tryk derefter på Ctrl+Shift+N, og sessionen vil blive scriptet til et forespørgselsvindue. Detaljerne om alt derinde ligger desværre uden for dette indlægs omfang, men skabelonbeskrivelsen er ret forklarende:

Der er også en ny udvidet begivenhed i SQL Server 2012 kaldet transaktionslog, der kan bruges til at lave alle mulige interessante analyser af, hvilke logposter der genereres. Det er bestemt et emne, jeg vil dække i et fremtidigt indlæg.

Oversigt

I betragtning af alle ovenstående oplysninger burde du være i stand til at komme med et ret godt overvågningssystem for transaktionslog. Transaktionslogsundhed er af afgørende betydning for at sikre, at din arbejdsbyrde fungerer, som den skal være, og jeg håber, at de fire indlæg i denne serie (plus alle de andre links) har hjulpet dig med at forbedre den overordnede ydeevne af dit SQL Server-miljø.