I mit tidligere indlæg om strømlining af transaktionsloggens operationer diskuterede jeg to af de mest almindelige årsager til, at ekstra logposter genereres:dødvægt fra ubrugte ikke-klyngede indekser og sideopdelingsoperationer (der forårsager indeksfragmentering). Hvis du antager, at du har læst det indlæg, nævnte jeg, at der er mere subtile problemer, der kan være skadelige for transaktionsloggens ydeevne, og jeg vil dække disse her.
Mange, mange små transaktioner
En gang imellem vil SQL Server tømme en del af transaktionsloggen til disken. En log-skyl opstår, når:
- Der genereres en logbog for transaktionsbekræftelse.
- En transaktionsafbrydelseslogpost genereres i slutningen af en transaktionsrulning.
- 60KB af logposter er blevet genereret siden den forrige logrensning.
Den mindst mulige log-flush er en enkelt 512-byte logblok. Hvis alle transaktioner i en arbejdsbelastning er meget små (f.eks. indsættelse af en enkelt, lille tabelrække), vil der forekomme masser af log-flush af minimal størrelse. Log-flush udføres asynkront for at tillade en anstændig transaktionsloggennemstrømning, men der er en fast grænse på 32 samtidige log-flush I/O'er på ethvert tidspunkt (forhøjet til 112 på SQL Server 2012).
Der er to mulige virkninger, dette kan have:
- På et langsomt ydende I/O-undersystem kan mængden af små transaktionslogskrivninger overvælde I/O-undersystemet, hvilket fører til skrivninger med høj latens og efterfølgende forringelse af transaktionsloggennemstrømningen. Denne situation kan identificeres ved høje skriveforsinkelser for transaktionslogfilen i outputtet af sys.dm_io_virtual_file_stats (se demo-linkene øverst i det forrige indlæg)
- På et højtydende I/O-undersystem kan skrivningerne fuldføre ekstremt hurtigt, men grænsen på 32 samtidige log-flush I/O'er skaber en flaskehals, når man forsøger at gøre logposterne holdbare på disken. Denne situation kan identificeres ved lave skriveforsinkelser og et næsten konstant antal udestående transaktionslogskrivninger tæt på 32 i det aggregerede output af sys.dm_io_pending_io_requests (se de samme demolinks).
I begge tilfælde kan det at gøre transaktioner længere (hvilket er meget kontraintuitivt!) reducere hyppigheden af tømning af transaktionslog og øge ydeevnen. Derudover, i tilfælde #1, kan flytning til et I/O-undersystem med højere ydeevne hjælpe – men kan føre til tilfælde #2. Med case #2, hvis transaktionerne ikke kan foretages længere, er det eneste alternativ at opdele arbejdsbyrden over flere databaser for at omgå den faste grænse på 32 samtidige log-flush I/O'er eller opgradere til SQL Server 2012 eller højere.
Automatisk vækst i transaktionslog
Hver gang der tilføjes ny plads til transaktionsloggen, skal den nul-initialiseres (udskrive nuller for at overskrive den tidligere brug af den del af disken), uanset om den øjeblikkelige filinitialiseringsfunktion er aktiveret eller ej. Dette gælder for oprettelse, manuel vækst og automatisk vækst af transaktionsloggen. Mens nul-initialiseringen finder sted, kan logposter ikke tømmes til loggen, så auto-vækst under en arbejdsbelastning, der ændrer data, kan føre til et mærkbart fald i gennemløbet, især hvis størrelsen på den automatiske vækst er indstillet til at være stor ( sige gigabyte, eller lad være med standard 10%).
Autovækst bør derfor undgås, hvis det overhovedet er muligt, ved at lade transaktionsloggen rydde, så der altid er ledig plads, der kan genbruges til nye logposter. Rydning af transaktionslog (også kendt som afkortning af transaktionslog, ikke at forveksle med formindskelse af transaktionslog) udføres af sikkerhedskopiering af transaktionslog, når du bruger fuld- eller bulk-logget gendannelsestilstand, og af kontrolpunkter, når du bruger Simple recovery-tilstand.
Logrydning kan kun ske, hvis intet kræver, at logposterne i sektionen af transaktionsloggen ryddes. Et almindeligt problem, der forhindrer logrydning, er at have langvarige transaktioner. Indtil en transaktion forpligter eller ruller tilbage, er alle log-registreringer fra begyndelsen af transaktionen og fremefter nødvendige i tilfælde af, at transaktionen ruller tilbage – inklusive alle log-registreringer fra andre transaktioner, der er spækket med dem fra den langvarige transaktion. Længerevarende transaktioner kan for eksempel være på grund af dårligt design, kode, der venter på menneskelig input, eller ukorrekt brug af indlejrede transaktioner. Alle disse kan undgås, når de er identificeret som et problem.
Det kan du læse mere om her og her.
Højtilgængelige funktioner
Nogle funktioner med høj tilgængelighed kan også forsinke rydning af transaktionslog:
- Databasespejling og tilgængelighedsgrupper, når de kører asynkront, kan opbygge en kø af logposter, der endnu ikke er blevet sendt til den redundante databasekopi. Disse logposter skal opbevares, indtil de sendes, hvilket forsinker rydningen af transaktionsloggen.
- Transaktionsreplikering (og også Change Data Capture) er afhængig af et Log Reader Agent-job til periodisk at scanne transaktionsloggen for transaktioner, der ændrer en tabel indeholdt i en replikeringspublikation. Hvis Log Reader Agent kommer bagud af en eller anden grund, eller er bevidst lavet til at køre sjældent, skal alle de logposter, der ikke er blevet scannet af jobbet, opbevares, hvilket forsinker rydningen af transaktionsloggen.
Når du kører i synkron tilstand, kan databasespejling og tilgængelighedsgrupper forårsage andre problemer med logningsmekanismen. Ved at bruge synkron databasespejling som et eksempel kan enhver transaktion, der forpligter sig på principalen, faktisk ikke vende tilbage til brugeren eller applikationen, før alle logposter, den genererede, er blevet sendt til spejlserveren, hvilket tilføjer en forpligtelsesforsinkelse på principalen. Hvis den gennemsnitlige transaktionsstørrelse er lang, og forsinkelsen er kort, er dette muligvis ikke mærkbart, men hvis den gennemsnitlige transaktion er meget kort, og forsinkelsen er ret lang, kan dette have en mærkbar effekt på arbejdsbyrden. I så fald skal enten ydeevnemålene for arbejdsbyrden ændres, højtilgængelighedsteknologien ændres til asynkron tilstand, eller netværkets båndbredde og hastighed mellem de primære og redundante databaser skal øges.
Den samme slags problem kan i øvrigt opstå, hvis selve I/O-undersystemet spejles synkront – med en potentiel forsinkelse for alle skrivninger, som SQL Server udfører.
Oversigt
Som du kan se, handler transaktionslogydeevne ikke kun om, at der genereres ekstra transaktionslogposter – der er mange miljøfaktorer, der også kan have en dybtgående effekt.
Den nederste linje er, at transaktionslogs sundhed og ydeevne er af afgørende betydning for at opretholde den samlede arbejdsbyrdeydelse. I disse to indlæg har jeg beskrevet de vigtigste årsager til problemer med ydeevnen i transaktionsloggen, så forhåbentlig vil du være i stand til at identificere og afhjælpe enhver, du har.
Hvis du vil lære meget mere om transaktionslogoperationer og justering af ydeevne, anbefaler jeg, at du tjekker mit 7,5 timers onlinekursus om logning, gendannelse og transaktionsloggen, tilgængelig via Pluralsight.