In het tweede deel van deze serie heb ik de structurele hiërarchie van het transactielogboek beschreven. Aangezien dit bericht voornamelijk gaat over de virtuele logbestanden (VLF's) die ik heb beschreven, raad ik u aan het tweede deel te lezen voordat u verdergaat.
Als alles goed is, loopt het transactielogboek eindeloos door, waarbij de bestaande VLF's worden hergebruikt. Dit gedrag noem ik het circulaire karakter van het logboek . Soms gebeurt er echter iets om dit te voorkomen, en het transactielogboek groeit en groeit en voegt steeds meer VLF's toe. In dit bericht zal ik uitleggen hoe dit allemaal werkt, of soms niet.
VLF's en logafbreking
Alle VLF's hebben een headerstructuur met metadata over de VLF. Een van de belangrijkste velden in de structuur is de status van de VLF, en de waarden waarin we geïnteresseerd zijn, zijn nul, wat betekent dat de VLF inactief is. , en twee, wat betekent dat de VLF actief is . Het is belangrijk omdat een inactieve VLF opnieuw kan worden gebruikt, maar een actieve niet. Merk op dat een VLF geheel actief of geheel inactief is.
Een VLF blijft actief zolang de vereiste logboekrecords erin zitten, dus het kan niet opnieuw worden gebruikt en overschreven (de volgende keer bedek ik de logboekrecords zelf). Voorbeelden van redenen waarom logrecords nodig kunnen zijn, zijn onder meer:
- Er is een langlopende transactie waar de logrecords deel van uitmaken, dus ze kunnen niet worden vrijgegeven totdat de transactie is vastgelegd of is teruggedraaid
- Een logback-up heeft nog geen back-up gemaakt van die logrecords
- Dat deel van het logboek is nog niet verwerkt door de Log Reader Agent voor transactionele replicatie of het vastleggen van wijzigingsgegevens
- Dat deel van het logboek is nog niet verzonden naar een asynchrone databasemirror of replica van een beschikbaarheidsgroep
Het is belangrijk op te merken dat als er geen redenen zijn voor een VLF om actief te blijven, deze niet weer inactief zal worden tot een proces genaamd log truncatie komt voor - meer hierover hieronder.
Met behulp van een eenvoudig hypothetisch transactielogboek met slechts vijf VLF's en VLF-volgnummers beginnend bij 1 (onthoud van de vorige keer dat ze dat in werkelijkheid nooit doen), wordt VFL 1 onmiddellijk gemarkeerd als actief, zoals er altijd is geweest. om ten minste één actieve VLF in het transactielogboek te zijn:de VLF waarnaar momenteel logboekblokken worden geschreven. Ons voorbeeldscenario wordt weergegeven in Afbeelding 1 hieronder.
Figuur 1:Hypothetisch, gloednieuw transactielogboek met 5 VLF's, volgnummers 1 t/m 5.
Naarmate er meer logrecords worden gemaakt en er meer logblokken naar het transactielogboek worden geschreven, vult VLF 1 zich, dus moet VLF 2 actief worden om meer logblokken te kunnen schrijven, zoals weergegeven in Afbeelding 2 hieronder.
Figuur 2:Activiteit gaat door het transactielogboek.
SQL Server houdt de start bij van de oudste niet-vastgelegde (actieve) transactie, en deze LSN blijft op schijf staan telkens wanneer een controlepuntbewerking plaatsvindt. De LSN van het meest recente logrecord dat naar het transactielogboek is geschreven, wordt ook bijgehouden, maar het wordt alleen in het geheugen bijgehouden, omdat er geen manier is om het op de schijf te bewaren zonder verschillende race-omstandigheden tegen te komen. Dat maakt niet uit, want het wordt alleen gebruikt tijdens crashherstel en SQL Server kan de LSN van het "einde" van het transactielogboek bepalen tijdens crashherstel. Controlepunten en crashherstel zijn onderwerpen voor toekomstige berichten in de serie.
Uiteindelijk zal VLF 2 vol raken en zal VLF 3 actief worden, enzovoort. De kern van het circulaire karakter van het transactielogboek is dat eerdere VLF's in het transactielogboek inactief worden, zodat ze opnieuw kunnen worden gebruikt. Dit wordt gedaan door een proces genaamd log truncatie , ook wel log clearing . genoemd . Helaas zijn beide termen vreselijke verkeerde benamingen omdat niets daadwerkelijk wordt afgekapt of gewist.
Het afkappen van logboeken is eenvoudigweg het proces waarbij alle VLF's in het transactielogboek worden onderzocht en bepaald welke actieve VLF's nu weer als inactief kunnen worden gemarkeerd, aangezien geen van hun inhoud nog vereist is door SQL Server. Wanneer logafkorting wordt uitgevoerd, is er geen garantie dat actieve VLF's inactief kunnen worden gemaakt - dit hangt volledig af van wat er met de database gebeurt.
Er zijn twee veelvoorkomende misvattingen over het afkappen van logbestanden:
- Het transactielogboek wordt kleiner (de misvatting over "afkappen"). Nee, dat is het niet - er is geen verandering in grootte ten opzichte van het afkappen van logbestanden. Het enige dat het transactielogboek kleiner kan maken, is een expliciete DBCC SHRINKFILE.
- De inactieve VLF's worden op de een of andere manier op nul gezet (de misvatting over 'opruimen'). Nee - er wordt niets naar de VLF geschreven wanneer deze inactief wordt gemaakt, behalve een paar velden in de VLF-header.
Afbeelding 3 hieronder toont ons transactielogboek waar VLF's 3 en 4 actief zijn, en logafbreking was in staat om VLF's 1 en 2 inactief te markeren.
Figuur 3:Logboekkorting markeert eerdere VLF's als inactief.
Wanneer logafbreking plaatsvindt, hangt af van welk herstelmodel voor de database wordt gebruikt:
- Eenvoudig model:logafkapping vindt plaats wanneer een controlepuntbewerking is voltooid
- Volledig model of bulk-gelogd model:logafkapping vindt plaats wanneer een logback-up is voltooid (zolang er geen gelijktijdige volledige of differentiële back-up wordt uitgevoerd, in welk geval logafkapping wordt uitgesteld totdat de gegevensback-up is voltooid) li>
Hier zijn geen uitzonderingen op.
Circulair karakter van het logboek
Om te voorkomen dat het transactielogboek moet groeien, moet logafbreking VLF's inactief kunnen markeren. De eerste fysieke VLF in het logboek moet inactief zijn om het transactielogboek een cirkelvormig karakter te geven.
Beschouw onderstaande afbeelding 4, die laat zien dat VLF's 4 en 5 in gebruik zijn en logafbreking heeft VLF's 1 tot en met 3 gemarkeerd als inactief. Er worden meer logrecords gegenereerd, er worden meer logblokken in VLF 5 geschreven en uiteindelijk raakt het vol.
Figuur 4:Activiteit vult de hoogste fysieke VLF in het transactielogboek.
Op dit punt kijkt de logmanager voor de database naar de status van de eerste fysieke VLF in het transactielog, dat in ons voorbeeld VLF 1 is, met volgnummer 1. VLF 1 is inactief, dus het transactielog kan rond en begin opnieuw met vullen. De logmanager verandert de eerste VLF in actief en verhoogt het volgnummer om één hoger te zijn dan het huidige hoogste VLF-volgnummer. Het wordt dus VLF 6 en het loggen gaat verder met het logblok dat in die VLF wordt geschreven. Dit is het cirkelvormige karakter van het logboek, zoals hieronder weergegeven in afbeelding 5.
Figuur 5:Het circulaire karakter van het transactielogboek en hergebruik van VLF.
Als het fout gaat
Wanneer de eerste fysieke VLF in het transactielogboek niet inactief is, kan het transactielogboek niet rondlopen, dus het zal groeien (zolang het is geconfigureerd om dit te doen en er voldoende schijfruimte is). Dit gebeurt vaak omdat er iets is dat verhindert dat logafbreking VLF's deactiveert. Als u merkt dat het transactielogboek voor een database groeit, kunt u een query uitvoeren op SQL Server om erachter te komen of er een probleem is met het afbreken van de logbestanden met behulp van deze eenvoudige code hieronder:
SELECT
[log_reuse_wait_desc]
FROM [master].[sys].[databases]
WHERE [name] = N'MyDatabase'; Als logafbreking een of meer VLF's kon deactiveren, is het resultaat NIETS. Anders , krijgt u een reden waarom logafkorting geen VLF's kon deactiveren. Er is een lange lijst met mogelijke redenen die hier worden beschreven in de sectie Factoren die het inkorten van logbestanden kunnen vertragen.
Het is belangrijk om de semantiek te begrijpen van wat het resultaat is:het is de reden waarom logafbreking niets kon doen de laatste keer dat het probeerde uit te voeren . Het resultaat kan bijvoorbeeld ACTIVE_BACKUP_OR_RESTORE, . zijn maar je weet dat die langlopende volledige back-up is afgelopen. Dit betekent alleen dat de laatste keer dat het logboek werd afgekapt, de back-up nog actief was.
In mijn ervaring is LOG_BACKUP de meest voorkomende reden waarom het afkappen van logbestanden wordt voorkomen.; d.w.z. ga een logback-up maken! Maar er is ook een interessant, raar gedrag met LOG_BACKUP . Als u het resultaat voortdurend ziet LOG_BACKUP maar u weet dat logback-ups met succes worden gemaakt, dit komt omdat er heel weinig activiteit in de database is en de huidige VLF hetzelfde is als de laatste keer dat een logback-up werd uitgevoerd. Dus LOG_BACKUP betekent "ga een logback-up maken" of "alle logrecords waarvan een back-up is gemaakt, zijn afkomstig van de huidige VLF, dus deze kan niet worden gedeactiveerd." Wanneer het laatste gebeurt, kan het verwarrend zijn.
Terug cirkelen...
Het handhaven van het circulaire karakter van het transactielogboek is erg belangrijk om kostbare loggroei en de noodzaak om corrigerende maatregelen te nemen te voorkomen. Meestal betekent dit dat er regelmatig back-ups van logboeken worden gemaakt om het inkorten van logboeken te vergemakkelijken en het transactielogboek te dimensioneren om grote, langlopende bewerkingen, zoals het opnieuw opbouwen van een index of ETL-bewerkingen, te kunnen uitvoeren zonder dat er logboekgroei optreedt.
In het volgende deel van de serie behandel ik logrecords, hoe ze werken en enkele interessante voorbeelden.