Arkitektur och hanteringsguide för SQL Server-transaktionsloggar

Gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalysplattformssystem (PDW)SQL-databas i Förhandsversion av Microsoft Fabric

Varje SQL Server-databas har en transaktionslogg som registrerar alla transaktioner och de databasändringar som görs av varje transaktion. Transaktionsloggen är en viktig komponent i databasen och om det uppstår ett systemfel kan transaktionsloggen krävas för att återställa databasen till ett konsekvent tillstånd. Den här guiden innehåller information om transaktionsloggens fysiska och logiska arkitektur. Att förstå arkitekturen kan förbättra effektiviteten i hanteringen av transaktionsloggar.

Logisk arkitektur för transaktionsloggar

SQL Server-transaktionsloggen fungerar logiskt som om transaktionsloggen är en sträng med loggposter. Varje loggpost identifieras med ett loggsekvensnummer (LSN). Varje ny loggpost skrivs till den logiska änden av loggen med ett LSN som är högre än LSN för posten före den. Loggposter lagras i en seriesekvens när de skapas, så att om LSN2 är större än LSN1 inträffade ändringen som beskrivs av loggposten som LSN2 refererar till efter ändringen som beskrivs av loggposten LSN1. Varje loggpost innehåller ID:t för den transaktion som den tillhör. För varje transaktion länkas alla loggposter som är associerade med transaktionen individuellt i en kedja med hjälp av bakåtpekare som påskyndar återställningen av transaktionen.

Den grundläggande strukturen för ett LSN är [VLF ID:Log Block ID:Log Record ID]. Mer information finns i avsnitten VLF och loggblock .

Här är ett exempel på ett LSN: 00000031:00000da0:0001, där 0x31 är ID för VLF, 0xda0 är loggblocks-ID och 0x1 är den första loggposten i loggblocket. Exempel på LSN:er finns i utdata från sys.dm_db_log_info DMV och undersök vlf_create_lsn kolumnen.

Loggposter för dataändringar registrerar antingen den logiska åtgärd som utförts eller registrerar före och efter bilder av ändrade data. Före-avbildningen är en kopia av data innan åtgärden utförs. efterbilden är en kopia av data när åtgärden har utförts.

Stegen för att återställa en åtgärd beror på typen av loggpost:

• Logisk åtgärd loggad

  • För att vidarebefordra den logiska åtgärden utförs åtgärden igen.
  • För att återställa den logiska åtgärden utförs den omvända logiska åtgärden.

• Före och efter att avbildningen loggats

  • För att vidarebefordra åtgärden tillämpas efterbilden.
  • För att återställa operationen appliceras den tidigare avbildningen.

Många typer av åtgärder registreras i transaktionsloggen. Dessa åtgärder omfattar följande:

• Start och slut för varje transaktion.

• Varje dataändring (infoga, uppdatera eller ta bort). Ändringar omfattar ändringar av system lagrade procedurer eller DDL-instruktioner (datadefinitionsspråk) i valfri tabell, inklusive systemtabeller.

• Tilldelning och avallokering av varje omfattning och sida.

• Skapa eller ta bort en tabell eller ett index.

Återställningsoperationer loggas också. Varje transaktion reserverar utrymme i transaktionsloggen för att se till att det finns tillräckligt med loggutrymme för att stödja en återgång som orsakas av antingen ett explicit rollback-kommando eller om ett fel uppstår. Mängden reserverat utrymme beror på vilka åtgärder som utförs i transaktionen, men i allmänhet är det lika med mängden utrymme som används för att logga varje åtgärd. Det här reserverade utrymmet frigörs när transaktionen har slutförts.

Avsnittet i loggfilen från den första loggposten som måste finnas för en lyckad databasomfattande återställning till den senast skrivna loggposten kallas den aktiva delen av loggen, den aktiva loggen eller loggens svans. Det här är avsnittet i loggen som krävs för en fullständig återställning av databasen. Ingen del av den aktiva loggen kan någonsin trunkeras. Loggsekvensnumret (LSN) för den första loggposten kallas minsta återställnings-LSN (MinLSN). Mer information om åtgärder som stöds av transaktionsloggen finns i Transaktionsloggen.

Differentiala och loggsäkerhetskopior flyttar den återställda databasen till en senare tidpunkt, vilket motsvarar ett högre LSN.

Fysisk arkitektur för transaktionsloggar

Databastransaktionsloggen mappar över en eller flera fysiska filer. Konceptuellt är loggfilen en sträng med loggposter. Fysiskt lagras sekvensen med loggposter effektivt i den uppsättning fysiska filer som implementerar transaktionsloggen. Det måste finnas minst en loggfil för varje databas.

Virtuella loggfiler (VLFs)

SQL Server Database Engine delar in varje fysisk loggfil internt i flera virtuella loggfiler (VLFs). Virtuella loggfiler har ingen fast storlek och det finns inget fast antal virtuella loggfiler för en fysisk loggfil. Databasmotorn väljer storleken på de virtuella loggfilerna dynamiskt när loggfilerna skapas eller utökas. Databasmotorn försöker underhålla några virtuella filer. Storleken på de virtuella filerna efter att en loggfil har utökats är summan av storleken på den befintliga loggen och storleken på den nya filökningen. Storleken eller antalet virtuella loggfiler kan inte konfigureras eller anges av administratörer.

Skapa virtuell loggfil

Skapandet av virtuell loggfil (VLF) följer den här metoden:

• I SQL Server 2014 (12.x) och senare versioner skapar du 1 VLF som täcker tillväxtstorleken om nästa tillväxt är mindre än 1/8 av den aktuella fysiska loggstorleken.
• Om nästa tillväxt är mer än 1/8 av den aktuella loggstorleken använder du metoden före 2014, nämligen:
  • Om tillväxten är mindre än 64 MB skapar du 4 VLF:er som täcker tillväxtstorleken (till exempel för tillväxt på 1 MB skapar du 4 VLF:er med storlek 256 KB).
    • I Azure SQL Database och från och med SQL Server 2022 (16.x) (alla utgåvor) skiljer sig logiken något åt. Om tillväxten är mindre än eller lika med 64 MB skapar databasmotorn bara en VLF för att täcka tillväxtstorleken.
  • Om tillväxten är från 64 MB upp till 1 GB skapar du 8 VLF:er som täcker tillväxtstorleken (till exempel för tillväxt på 512 MB skapar du 8 VLF:er av storlek 64 MB).
  • Om tillväxten är större än 1 GB skapar du 16 VLF:er som täcker tillväxtstorleken, till exempel för tillväxt på 8 GB, och skapar 16 VLF:er med storleken 512 MB).

Om loggfilerna växer till en stor storlek i många små steg får de många virtuella loggfiler. Detta kan göra databasstarten långsammare, säkerhetskopierings- och återställningsåtgärderna för loggar och orsaka transaktionsreplikering/CDC och AlwaysOn-svarstid. Om loggfilerna däremot är inställda på en stor storlek med några få eller bara en ökning, innehåller de få mycket stora virtuella loggfiler. Mer information om hur du beräknar önskad storlek och autogrow-inställning för en transaktionslogg finns i avsnittet Rekommendationer i Hantera storleken på transaktionsloggfilen.

Vi rekommenderar att du skapar dina loggfiler nära den slutliga storlek som krävs, med hjälp av de steg som krävs för att uppnå optimal VLF-distribution och har ett relativt stort growth_increment värde.

Se följande tips för att fastställa den optimala VLF-fördelningen för den aktuella transaktionsloggstorleken:

• Storleksvärdet som anges av SIZE argumentet ALTER DATABASE för är den ursprungliga storleken för loggfilen.
• Det growth_increment värdet (även kallat autogrow-värdet), som FILEGROWTH argumentet för ALTER DATABASE anger, är mängden utrymme som läggs till i filen varje gång nytt utrymme krävs.

Mer information om FILEGROWTH och SIZE argument för ALTER DATABASEfinns i ALTER DATABASE (Transact-SQL) Fil- och filgruppsalternativ.

Vad händer när du har för många VLFs?

Under de inledande stegen i en databasåterställningsprocess identifierar SQL Server alla VLF:er i alla transaktionsloggfiler och skapar en lista över dessa VLF:er. Den här processen kan ta lång tid beroende på antalet VLF:er som finns i den specifika databasen. Ju fler VLF:er, desto längre blir processen. En databas kan få ett stort antal VLF:er om frekvent autogenerering av transaktionsloggen eller manuell ökning påträffas i små steg. När antalet VLFs når intervallet på flera hundra tusen kan du stöta på några eller de flesta av följande symtom:

• En eller flera databaser tar mycket lång tid att slutföra återställningen under SQL Server-starten.
• Det tar mycket lång tid att återställa en databas.
• Det tar mycket lång tid att ansluta en databas.
• När du försöker konfigurera databasspegling visas felmeddelandena 1413, 1443 och 1479, vilket indikerar en tidsgräns.
• Du får minnesrelaterade fel som 701 när du försöker återställa en databas.
• Transaktionsreplikering eller insamling av ändringsdata kan få betydande svarstider.

När du undersöker SQL Server-felloggen kanske du märker att en betydande mängd tid ägnas innan analysfasen i databasåterställningsprocessen. Till exempel:

2022-05-08 14:42:38.65 spid22s Starting up database 'lot_of_vlfs'.
2022-05-08 14:46:04.76 spid22s Analysis of database 'lot_of_vlfs' (16) is 0% complete (approximately 0 seconds remain). Phase 1 of 3. This is an informational message only. No user action is required.

Dessutom kan SQL Server logga ett MSSQLSERVER_9017 fel när du återställer en databas med ett stort antal VLF:er:

Database %ls has more than %d virtual log files which is excessive. Too many virtual log files can cause long startup and backup times. Consider shrinking the log and using a different growth increment to reduce the number of virtual log files.

Mer information finns i MSSQLSERVER_9017.

Åtgärda databaser med ett stort antal VLF-filer

Om du vill hålla det totala antalet VLFs på ett rimligt belopp, till exempel högst flera tusen, kan du återställa transaktionsloggfilen så att den innehåller ett mindre antal VLFs genom att utföra följande steg:

1. Krymp transaktionsloggfilerna manuellt.

2. Utöka filerna till den storlek som krävs manuellt i ett steg med hjälp av följande T-SQL-skript:

   ALTER DATABASE <database name> MODIFY FILE (NAME='Logical file name of transaction log', SIZE = <required size>);

   Note

   Det här steget är också möjligt i SQL Server Management Studio med hjälp av sidan databasegenskaper.

När du har angett den nya layouten för transaktionsloggfilen med färre VLF:er granskar du och gör nödvändiga ändringar i inställningarna för automatisk uppväxning av transaktionsloggen. Den här inställningsverifieringen säkerställer att loggfilen undviker att stöta på samma problem i framtiden.

Innan du utför någon av dessa åtgärder kontrollerar du att du har en giltig återställningsbar säkerhetskopia om du stöter på problem senare.

Om du vill fastställa den optimala VLF-distributionen för den aktuella transaktionsloggstorleken för alla databaser i en viss instans, och de tillväxtökningar som krävs för att uppnå den storlek som krävs, kan du använda följande GitHub-skript för att åtgärda VLF:er.

Loggblock

Varje VLF innehåller ett eller flera loggblock. Varje loggblock består av loggposterna (justerade vid en gräns på 4 byte). Ett loggblock är variabelt i storlek och är alltid en heltalsmultipel på 512 byte (den minsta sektorstorlek som SQL Server stöder) med en maximal storlek på 60 kB. Ett loggblock är den grundläggande I/O-enheten för transaktionsloggning.

Sammanfattningsvis är ett loggblock en container med loggposter som används som den grundläggande transaktionsloggningsenheten när loggposter skrivs till disk.

Varje loggblock i en VLF hanteras unikt av dess blockförskjutning. Det första blocket har alltid ett blockoffset som pekar förbi de första 8 kB i VLF:en.

I allmänhet fylls en VLF alltid med loggblock. Det är möjligt att det sista loggblocket i en VLF är tomt (till exempel inte innehåller några loggposter). Detta inträffar när en loggpost som ska skrivas inte passar in i det aktuella loggblocket och även när utrymmet som finns kvar på VLF inte räcker för att lagra den här loggposten. I det här fallet skapas ett tomt loggblock som fyller upp den virtuella loggfilen (VLF). Loggposten infogas i det första blocket på nästa VLF.

Transaktionsloggens cirkulära karaktär

Transaktionsloggen är en omslutande fil. Anta till exempel att en databas med en fysisk loggfil är uppdelad i fyra VLF:er. När databasen skapas börjar den logiska loggfilen i början av den fysiska loggfilen. Nya loggposter läggs till i slutet av den logiska loggen och expanderas mot slutet av den fysiska loggen. Loggtrunkering frigör alla virtuella loggar vars poster alla visas framför minsta återställningsloggsekvensnummer (MinLSN). MinLSN är loggsekvensnumret för den äldsta loggposten som krävs för en lyckad databasomfattande återställning. Transaktionsloggen i exempeldatabasen skulle se ut ungefär som i följande diagram.

När slutet av den logiska loggen når slutet av den fysiska loggfilen, börjar de nya loggposterna om från början av den fysiska loggfilen.

Den här cykeln upprepas oändligt, så länge slutet aldrig når början av den logiska loggen. Om de gamla loggposterna trunkeras tillräckligt ofta för att alltid lämna tillräckligt med utrymme för alla nya loggposter som skapas via nästa kontrollpunkt fylls loggen aldrig. Men om slutet av den logiska loggen når början av den logiska loggen sker en av två saker:

• Om inställningen FILEGROWTH är aktiverad för loggen och utrymmet är tillgängligt på disken utökas filen med det belopp som anges i parametern growth_increment och de nya loggposterna läggs till i tillägget. Mer information om inställningen finns i FILEGROWTHALTER DATABASE (Transact-SQL) Fil- och filgruppsalternativ.

• Om inställningen FILEGROWTH inte är aktiverad eller om den disk som innehåller loggfilen har mindre ledigt utrymme än den mängd som anges i growth_increment genereras ett 9002-fel. Mer information finns i Felsöka en fullständig transaktionslogg (SQL Server-fel 9002).

Om loggen innehåller flera fysiska loggfiler flyttas den logiska loggen genom alla fysiska loggfiler innan den omsluts till början av den första fysiska loggfilen.

Loggtrunkering

Loggtrunkering är viktigt för att loggen inte ska fyllas i. Loggtrunkering tar bort inaktiva virtuella loggfiler från den logiska transaktionsloggen för en SQL Server-databas, vilket frigör utrymme i den logiska loggen för återanvändning av den fysiska transaktionsloggen. Om en transaktionslogg aldrig trunkeras kommer den så småningom att fylla allt diskutrymme som allokeras till dess fysiska loggfiler. Men innan loggen kan trunkeras måste en kontrollpunktsåtgärd utföras. En kontrollpunkt skriver de aktuella ändrade sidorna i minnet (kallas för smutsiga sidor) och transaktionslogginformation från minne till disk. När kontrollpunkten utförs markeras den inaktiva delen av transaktionsloggen som återanvändbar. Därefter kan en loggtrunkering frigöra den inaktiva delen. Mer information om kontrollpunkter finns i Databaskontrollpunkter (SQL Server).

Följande diagram visar en transaktionslogg före och efter trunkering. Det första diagrammet visar en transaktionslogg som aldrig har trunkerats. För närvarande används fyra virtuella loggfiler av den logiska loggen. Den logiska loggen börjar längst fram i den första virtuella loggfilen och slutar vid virtuell logg 4. MinLSN-posten finns i virtuell logg 3. Virtuell logg 1 och virtuell logg 2 innehåller endast inaktiva loggposter. Dessa poster kan kortas. Den virtuella loggen 5 är fortfarande oanvänd och ingår inte i den aktuella logiska loggen.

Det andra diagrammet visar hur loggen ser ut efter att den trunkerats. Virtuell logg 1 och virtuell logg 2 har frigjorts för återanvändning. Den logiska loggen startar nu i början av den virtuella loggen 3. Den virtuella loggen 5 är fortfarande oanvänd och ingår inte i den aktuella logiska loggen.

Loggtrunkering sker automatiskt efter följande händelser, förutom när det fördröjs av någon anledning:

• Under den enkla återställningsmodellen, efter en kontrollpunkt.
• Under den fullständiga återställningsmodellen eller den massloggade återställningsmodellen efter en loggsäkerhetskopia, om en kontrollpunkt har inträffat sedan den föregående säkerhetskopieringen.

Loggtrunkering kan fördröjas av olika faktorer. I händelse av en lång fördröjning i loggtrunkeringen kan transaktionsloggen fyllas upp. Mer information finns i Faktorer som kan fördröja loggtrunkering och Felsöka en fullständig transaktionslogg (SQL Server-fel 9002).

Transaktionslogg med skrivning i förväg

I det här avsnittet beskrivs rollen för skriv-framåt-transaktionsloggen för att registrera dataändringar på disken. SQL Server använder en WAL-algoritm (write-ahead loggning) som garanterar att inga dataändringar skrivs till disken innan den associerade loggposten skrivs till disken. Detta upprätthåller ACID-egenskaperna för en transaktion.

Mer information om WAL finns i grunderna för SQL Server I/O.

För att förstå hur loggning före skrivning fungerar i förhållande till transaktionsloggen är det viktigt att du vet hur ändrade data skrivs till disken. SQL Server underhåller en buffertcache (kallas även en buffertpool) där den läser datasidor när data måste hämtas. När en sida ändras i buffertcachen skrivs den inte omedelbart tillbaka till disken. i stället markeras sidan som smutsig. En datasida kan ha fler än en logisk skrivning gjord innan den skrivs fysiskt till disk. För varje logisk skrivning infogas en transaktionsloggpost i loggcachen som registrerar ändringen. Loggposterna måste skrivas till disken innan den associerade smutsiga sidan tas bort från buffertcachen och skrivs till disken. Kontrollpunktsprocessen söker regelbundet igenom buffertcachen efter buffertar med sidor från en angiven databas och skriver alla smutsiga sidor till disken. Kontrollpunkter sparar tid under en senare återställning genom att skapa en punkt där alla smutsiga sidor garanterat har skrivits till disk.

Att skriva en ändrad datasida från buffertcachen till disken kallas tömning av sidan. SQL Server har logik som förhindrar att en felaktig sida töms innan den associerade loggposten skrivs. Loggposter skrivs till disk när loggbuffertarna töms. Detta inträffar när en transaktion bekräftas eller när loggbuffertarna blir fulla.

Säkerhetskopior av transaktionsloggar

I det här avsnittet beskrivs begrepp om hur du säkerhetskopierar och återställer (tillämpar) transaktionsloggar. Under de fullständiga och massloggade återställningsmodellerna krävs rutinmässiga säkerhetskopieringar av transaktionsloggar (loggsäkerhetskopior) för att återställa data. Du kan säkerhetskopiera loggen medan alla fullständiga säkerhetskopior körs. Mer information om återställningsmodeller finns i Säkerhetskopiera och återställa SQL Server-databaser.

Innan du kan skapa den första loggsäkerhetskopian måste du skapa en fullständig säkerhetskopia, till exempel en databassäkerhetskopia eller den första i en uppsättning säkerhetskopior av filer. Det kan bli komplicerat att återställa en databas med hjälp av endast filsäkerhetskopior. Därför rekommenderar vi att du börjar med en fullständig databassäkerhetskopia när du kan. Därefter är det nödvändigt att säkerhetskopiera transaktionsloggen regelbundet. Detta minimerar inte bara exponering för arbetsförluster utan möjliggör även trunkering av transaktionsloggen. Vanligtvis trunkeras transaktionsloggen efter varje konventionell loggbackup.

För att begränsa antalet loggsäkerhetskopior som du behöver återställa är det viktigt att du regelbundet säkerhetskopierar dina data. Du kan till exempel schemalägga en fullständig databassäkerhetskopiering varje vecka och dagliga differentiella databassäkerhetskopior.

Tänk på nödvändig RTO och RPO när du implementerar din återställningsstrategi, och specifikt den fullständiga och differentiella säkerhetskopieringen av databasen.

Mer information om säkerhetskopieringar av transaktionsloggar finns i Säkerhetskopior av transaktionsloggar (SQL Server).

Säkerhetskopieringsfrekvens och affärskrav

Du bör göra tillräckligt många loggsäkerhetskopior för att stödja dina affärskrav, särskilt din tolerans för arbetsförluster som kan orsakas av en skadad logglagring.

Lämplig frekvens för att ta loggsäkerhetskopior beror på din tolerans för exponering för arbetsförlust som balanseras av hur många loggsäkerhetskopior du kan lagra, hantera och eventuellt återställa. Tänk på det nödvändiga målet för återställningstid (RTO) och mål för återställningspunkt (RPO) när du implementerar din återställningsstrategi, och särskilt frekvensen för loggsäkerhetskopiering.

Det kan räcka med en loggsäkerhetskopia var 15:e till 30:e minut. Om ditt företag kräver att du minimerar exponeringen för arbetsförluster bör du överväga att göra loggsäkerhetskopior oftare. Mer frekventa loggsäkerhetskopior har den extra fördelen att öka loggtrunkeringens frekvens, vilket resulterar i mindre loggfiler.

Loggkedjan

En kontinuerlig sekvens av loggsäkerhetskopior kallas för en loggkedja. En loggkedja börjar med en fullständig säkerhetskopia av databasen. Vanligtvis startas en ny loggkedja först när databasen säkerhetskopieras för första gången, eller när återställningsmodellen har växlats från enkel återställning till fullständig eller massloggad återställning. Om du inte väljer att skriva över befintliga säkerhetskopieringsuppsättningar när du skapar en fullständig databassäkerhetskopia förblir den befintliga loggkedjan intakt. Med loggkedjan intakt kan du återställa databasen från en fullständig databassäkerhetskopia i medieuppsättningen, följt av alla efterföljande loggsäkerhetskopior via återställningspunkten. Återställningspunkten kan vara slutet på den senaste loggsäkerhetskopian eller en specifik återställningspunkt i någon av loggsäkerhetskopiorna. Mer information finns i Säkerhetskopior av transaktionsloggar (SQL Server).

Om du vill återställa en databas till felpunkten måste loggkedjan vara intakt. En obruten sekvens av säkerhetskopior av transaktionsloggar måste alltså sträcka sig upp till felpunkten. Var den här loggsekvensen måste starta beror på vilken typ av datasäkerhetskopior du återställer: databas, partiell eller fil. För en databas eller partiell säkerhetskopiering måste sekvensen med loggsäkerhetskopior utökas från slutet av en databas eller delvis säkerhetskopiering. För en uppsättning säkerhetskopior av filer måste sekvensen med loggsäkerhetskopior sträcka sig från början av en fullständig uppsättning filsäkerhetskopior. Mer information finns i Apply Transaction Log Backups (SQL Server).

Återställa loggsäkerhetskopior

När du återställer en loggsäkerhetskopia vidarebefordras de ändringar som registrerades i transaktionsloggen för att återskapa databasens exakta tillstånd när loggsäkerhetskopian startade. När du återställer en databas måste du återställa de loggsäkerhetskopior som skapades efter den fullständiga databassäkerhetskopian som du återställer, eller från början av den första säkerhetskopian av filen som du återställer. När du har återställt de senaste data eller differentiella säkerhetskopiorna måste du vanligtvis återställa en serie loggsäkerhetskopior tills du når återställningspunkten. Sedan återställer du databasen. Detta återställer alla transaktioner som var ofullständiga när återställningen startade och gör databasen online. När databasen har återställts kan du inte återställa fler säkerhetskopior. Mer information finns i Apply Transaction Log Backups (SQL Server).

Kontrollpunkter och den aktiva delen av loggen

Kontrollpunkter tömer smutsiga datasidor från buffertcachen för den aktuella databasen till disken. Detta minimerar den aktiva delen av loggen som måste bearbetas under en fullständig återställning av en databas. Under en fullständig återställning utförs följande typer av åtgärder:

• Loggposterna för ändringar som inte tömts till disken innan systemet stoppades rullas framåt.
• Alla ändringar som är associerade med ofullständiga transaktioner, till exempel transaktioner för vilka det inte finns någon COMMIT post eller ROLLBACK loggpost, återställs.

Kontrollpunktsåtgärd

En kontrollpunkt utför följande processer i databasen:

• Registrerar en postering i loggfilen som markerar början av kontrollpunkten.

• Lagrar information som registrerats för kontrollpunkten i en kedja av kontrollpunktsloggposter.

  En information som registreras i kontrollpunkten är loggsekvensnumret (LSN) för den första loggposten som måste finnas för en lyckad databasomfattande återställning. Det här LSN:et kallas lägsta återställnings-LSN (MinLSN). MinLSN är det minsta av följande:

  • LSN i början av kontrollpunkten.
  • LSN för starten av den äldsta aktiva transaktionen.
  • LSN för starten av den äldsta replikeringstransaktionen som ännu inte har levererats till distributionsdatabasen.

  Kontrollpunktsloggarna innehåller också en lista över alla aktiva transaktioner som har modifierat databasen.

• Om databasen använder den enkla återställningsmodellen, markeras det utrymme som föregår MinLSN för återanvändning.

• Skriver alla smutsiga logg- och datasidor till disken.

• Skriver en post som markerar slutet av kontrollpunkten till loggfilen.

• Skriver LSN i början av den här kedjan till startsidan för databasen.

Aktiviteter som orsakar en kontrollpunkt

Kontrollpunkter sker i följande situationer:

• En CHECKPOINT instruktion körs uttryckligen. En kontrollpunkt inträffar i den aktuella databasen för anslutningen.

• En minimalt loggad åtgärd utförs i databasen. Till exempel utförs en masskopieringsåtgärd på en databas som använder Bulk-Logged återställningsmodell.

• Databasfiler har lagts till eller tagits bort med hjälp ALTER DATABASEav .

• En instans av SQL Server stoppas av en SHUTDOWN instruktion eller genom att tjänsten SQL Server (MSSQLSERVER) stoppas. Båda åtgärderna orsakar en kontrollpunkt i varje databas i instansen av SQL Server.

• En instans av SQL Server genererar regelbundet automatiska kontrollpunkter i varje databas för att minska tiden det tar för instansen att återställa databasen.

• En databassäkerhetskopia görs.

• En aktivitet som kräver en databasavstängning utförs. Detta kan inträffa när alternativet AUTO_CLOSE är ON och den senaste användaranslutningen till databasen stängs. Ett annat exempel är när en ändring av databasalternativet görs som kräver en omstart av databasen.

Automatiska kontrollpunkter

SQL Server Database Engine genererar automatiska kontrollpunkter. Intervallet mellan automatiska kontrollpunkter baseras på mängden loggutrymme som använts och den tid som förflutit sedan den senaste kontrollpunkten. Tidsintervallet mellan automatiska kontrollpunkter kan vara mycket varierande och långt, om några ändringar görs i databasen. Automatiska kontrollpunkter kan också inträffa ofta om många data ändras.

Använd konfigurationsalternativet för återställningsintervallservern för att beräkna intervallet mellan automatiska kontrollpunkter för alla databaser på en serverinstans. Det här alternativet anger den maximala tid som databasmotorn ska använda för att återställa en databas under en omstart av systemet. Databasmotorn uppskattar hur många loggposter den kan bearbeta i återställningsintervallet under en återställningsåtgärd.

Intervallet mellan automatiska kontrollpunkter beror också på återställningsmodellen:

• Om databasen använder antingen den fullständiga eller massloggade återställningsmodellen genereras en automatisk kontrollpunkt när antalet loggposter når det antal som databasmotorn uppskattar att den kan bearbeta under den tid som anges i återställningsintervallalternativet.

• Om databasen använder den enkla återställningsmodellen genereras en automatisk kontrollpunkt när antalet loggposter når mindre av dessa två värden:

  • Loggen blir 70 procent full.
  • Antalet loggposter når det antal som databasmotorn uppskattar att den kan bearbeta under den tid som anges i återställningsintervallalternativet.

Information om hur du anger återställningsintervall finns i Serverkonfiguration: återställningsintervall (min).

Automatiska kontrollpunkter trunkerar det oanvända avsnittet i transaktionsloggen om databasen använder den enkla återställningsmodellen. Men om databasen använder de fullständiga eller massloggade återställningsmodellerna trunkeras loggen inte av automatiska kontrollpunkter. Mer information finns i Transaktionsloggen.

Instruktionen CHECKPOINT innehåller nu ett valfritt checkpoint_duration argument som anger den begärda tidsperioden, i sekunder, för att kontrollpunkterna ska slutföras. Mer information finns i KONTROLLPUNKT.

Aktiv logg

Avsnittet i loggfilen från MinLSN till den senast skrivna loggposten kallas den aktiva delen av loggen eller den aktiva loggen. Det här är avsnittet i loggen som krävs för att göra en fullständig återställning av databasen. Ingen del av den aktiva loggen kan någonsin trunkeras. Alla loggrekord måste avkortas från delarna i loggen innan MinLSN.

Följande diagram visar en förenklad version av loggen för slutet av en transaktion med två aktiva transaktioner. Kontrollpunktsregistreringar har sammanförts till en enda registrering.

LSN 148 är den sista posten i transaktionsloggen. Vid tidpunkten då den registrerade kontrollpunkten vid LSN 147 bearbetades hade Tran 1 bekräftats och Tran 2 var den enda aktiva transaktionen. Det gör den första loggposten för Tran 2 till den äldsta loggposten för en transaktion aktiv vid tidpunkten för den senaste kontrollpunkten. Detta gör att LSN 142, som är transaktionsposten Begin för Tran 2, är det minimala LSN.

Långvariga transaktioner

Den aktiva loggen måste innehålla varje del av alla icke-obligatoriska transaktioner. Ett program som startar en transaktion och inte checkar in den eller återställer den hindrar databasmotorn från att avancera MinLSN. Den här situationen kan orsaka två typer av problem:

• Om systemet stängs av efter att transaktionen har utfört många ogenomförda ändringar kan återställningsfasen för den efterföljande omstarten ta mycket längre tid än den tid som anges i återställningsintervallalternativet .
• Loggen kan bli mycket stor eftersom loggen inte kan trunkeras förbi MinLSN. Detta inträffar även om databasen använder den enkla återställningsmodellen, där transaktionsloggen trunkeras på varje automatisk kontrollpunkt.

Återställning av långvariga transaktioner och de problem som beskrivs i den här artikeln kan undvikas med hjälp av accelererad databasåterställning, en funktion som är tillgänglig från och med SQL Server 2019 (15.x) och i Azure SQL Database.

Replikeringstransaktioner

Loggläsaragenten övervakar transaktionsloggen för varje databas som konfigurerats för transaktionsreplikering och kopierar transaktionerna som har markerats för replikering från transaktionsloggen till distributionsdatabasen. Den aktiva loggen måste innehålla alla transaktioner som har markerats för replikering, men som ännu inte har levererats till distributionsdatabasen. Om dessa transaktioner inte replikeras i tid kan de förhindra loggtrunkering. Mer information finns i Transaktionsreplikering.

Relaterat innehåll

• Transaktionsloggen
• Hantera storleken på transaktionsloggfilen
• säkerhetskopieringar av transaktionsloggar (SQL Server)
• Databaskontrollpunkter (SQL Server)
• Serverkonfiguration: återställningsintervall (min)
• Accelererad databasåterställning
• sys.dm_db_log_info (Transact-SQL)
• sys.dm_db_log_space_usage (Transact-SQL)
• Förstå loggning och återställning i SQL Server