Dela via

Transaktionsloggen

  • Artikel

gäller för:SQL Server

Varje SQL Server-databas har en transaktionslogg som registrerar alla transaktioner och databasändringar som görs av varje transaktion.

Transaktionsloggen är en viktig komponent i databasen. Om det uppstår ett systemfel behöver du loggen för att återställa databasen till ett konsekvent tillstånd.

Varning

Ta aldrig bort eller flytta den här loggen såvida du inte helt förstår konsekvenserna av att göra det.

Information om transaktionsloggarnas arkitektur och interna detaljer finns i SQL Server-transaktionsloggarkitektur och -hanteringsguide.

Tips

Kända bra punkter för att börja tillämpa transaktionsloggar under databasåterställning skapas av kontrollpunkter. Mer information finns i Database checkpoints (SQL Server).

Åtgärder som stöds av transaktionsloggen

Transaktionsloggen stöder följande åtgärder:

  • Enskild transaktionsåterställning.
  • Återställning av alla ofullständiga transaktioner när SQL Server startas.
  • Rulla en återställd databas, fil, filgrupp eller sida framåt till felpunkten.
  • Stöd för transaktionsreplikering.
  • Stöd för lösningar för hög tillgänglighet och katastrofåterställning: "Always On"-tillgänglighetsgrupper, databasspegling och loggöverföring.

Återställning av enskilda transaktioner

Om ett program utfärdar en ROLLBACK-instruktion, eller om databasmotorn upptäcker ett fel, till exempel kommunikationsförlust med en klient, används loggposterna för att återställa de ändringar som gjorts av en ofullständig transaktion.

Återställning av alla ofullständiga transaktioner när SQL Server startas

Om en server misslyckas kan databaserna lämnas i ett tillstånd där vissa ändringar aldrig har skrivits från buffertcachen till datafilerna, och det kan finnas vissa ändringar från ofullständiga transaktioner i datafilerna. När en instans av SQL Server startas körs en återställning av varje databas. Alla ändringar som registreras i loggen som kanske inte har skrivits till datafilerna överförs. Varje ofullständig transaktion som hittas i transaktionsloggen återställs sedan för att säkerställa att databasens integritet bevaras. Mer information finns i Översikt över återställning och återhämtning (SQL Server).

Rulla en återställd databas, fil, filgrupp eller sida framåt till felpunkten

Efter en maskinvaruförlust eller ett diskfel som påverkar databasfilerna kan du återställa databasen till felpunkten. Du återställer först den senaste fullständiga databassäkerhetskopian och den senaste differentiella databassäkerhetskopian och återställer sedan den efterföljande sekvensen av säkerhetskopiorna i transaktionsloggen till felpunkten.

När du återställer varje loggsäkerhetskopia gör databasmotorn alla ändringar som registrerats i loggen igen för att vidarebefordra alla transaktioner. När den senaste loggsäkerhetskopian återställs använder databasmotorn logginformationen för att rulla tillbaka alla transaktioner som inte var slutförda vid den tidpunkten. Mer information finns i Översikt över återställning och återhämtning (SQL Server).

Stöd för transaktionsreplikering

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. Mer information finns i How Transactional Replication Works.

Stödja lösningar för hög tillgänglighet och katastrofåterhämtning

Standby-server-lösningarna, AlwaysOn-tillgänglighetsgrupper, databasspegling och loggleverans är starkt beroende av transaktionsloggen.

I ett scenario med AlwaysOn-tillgänglighetsgrupperåterskapas varje uppdatering av en databas på den primära repliken omedelbart i separata kopior av databasen på alla sekundära repliker. Den primära repliken skickar varje loggpost omedelbart till de sekundära replikerna, som tillämpar inkommande loggposter på tillgänglighetsdatabaserna och kontinuerligt rullar vidare loggen. Mer information finns i AlwaysOn-redundansklusterinstanser (SQL Server).

I ett loggleveransscenarioskickar den primära servern säkerhetskopior av transaktionsloggen för den primära databasen till ett eller flera mål. Varje sekundär server återställer loggsäkerhetskopiorna till sin lokala sekundära databas. Mer information finns i Om loggöverföring (SQL Server).

I ett databasspeglingsscenarioåterskapas varje uppdatering av en databas, huvuddatabasen, omedelbart i en separat, fullständig kopia av databasen, speglingsdatabasen. Huvudserverinstansen skickar varje loggpost omedelbart till speglingsserverinstansen, som tillämpar inkommande loggposter på speglingsdatabasen och kontinuerligt rullar den framåt. Mer information finns i Database Mirroring (SQL Server).

Egenskaper för transaktionslogg

Egenskaper för SQL Server Database Engine-transaktionsloggen:

  • Transaktionsloggen implementeras som en separat fil eller uppsättning filer i databasen. Loggcachen hanteras separat från buffertcachen för datasidor, vilket resulterar i enkel, snabb och robust kod i SQL Server Database Engine. Mer information finns i fysisk arkitektur för transaktionsloggar.

  • Formatet för loggposter och sidor är inte begränsat för att följa formatet för datasidor.

  • Transaktionsloggen kan implementeras i flera filer. Filerna kan definieras för att expandera automatiskt genom att ange FILEGROWTH värdet för loggen. Detta minskar risken för att utrymmet i transaktionsloggen börjar ta slut, samtidigt som det minskar de administrativa kostnaderna. Mer information finns i ALTER DATABASE (Transact-SQL) Fil- och filgruppsalternativ.

  • Mekanismen för att återanvända utrymmet i loggfilerna är snabb och har minimal effekt på transaktionsdataflödet.

Information om transaktionsloggarkitekturens och interna detaljer finns i SQL Server-transaktionsloggarnas arkitektur och hantering guide.

Trunkering av transaktionslogg

Loggtrunkering frigör utrymme i loggfilen för återanvändning av transaktionsloggen. Du måste regelbundet begränsa storleken på transaktionsloggen för att förhindra att den fyller det tilldelade utrymmet. Flera faktorer kan fördröja loggtrunkeringen, så övervakning av loggstorleken är viktig. Vissa åtgärder kan loggas minimalt för att minska deras inverkan på transaktionsloggens storlek.

Loggtrunkering tar bort inaktiva virtuella loggfiler (VLFs) 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 fyller den så småningom allt diskutrymme som allokerats till fysiska loggfiler.

För att undvika att utrymmet börjar ta slut, såvida inte loggtrunkeringen fördröjs av någon anledning, sker trunkeringen automatiskt efter följande händelser:

  • Under den enkla återställningsmodellen, efter en kontrollpunkt.

  • Under den fullständiga återställningsmodellen eller den massloggade återställningsmodellen, om en kontrollpunkt har inträffat sedan den föregående säkerhetskopieringen, sker trunkering efter en loggsäkerhetskopia (såvida det inte är en loggsäkerhetskopia med endast kopiering).

  • När du först skapar en databas med hjälp av den fullständiga återställningsmodellen återanvänds transaktionsloggen efter behov (liknar en databas med hjälp av den enkla återställningsmodellen) fram tills du skapar en fullständig säkerhetskopia av databasen.

Mer information hittar du i Faktorer som kan fördröja loggtrunkeringsenare i den här artikeln.

Loggtrunkering minskar inte storleken på den fysiska loggfilen. Om du vill minska den fysiska storleken på en fysisk loggfil måste du krympa loggfilen. Information om hur du minskar storleken på den fysiska loggfilen finns i Hantera storleken på transaktionsloggfilen. Tänk dock på Faktorer som kan fördröja loggtrunkering. Om lagringsutrymmet krävs igen efter att en logg krympt växer transaktionsloggen igen och genom att göra det inför du prestandaomkostnader under loggens tillväxtåtgärder.

Faktorer som kan fördröja loggtrunkering

När loggposter förblir aktiva under en längre tid fördröjs trunkeringen av transaktionsloggen och transaktionsloggen kan bli full, som vi tidigare nämnt i denna artikel.

Viktig

Information om hur du svarar på en fullständig transaktionslogg finns i Felsöka en fullständig transaktionslogg (SQL Server-fel 9002).

Loggtrunkering kan fördröjas av olika orsaker. Om du vill veta vad som hindrar loggtrunkeringen frågar du kolumnerna log_reuse_wait och log_reuse_wait_desc i sys.databases katalogvy. I följande tabell beskrivs värdena för dessa kolumner.

log_reuse_wait värde värdet på log_reuse_wait_desc Beskrivning
0 NOTHING För närvarande finns det en eller flera återanvändbara virtuella loggfiler (VLFs).
1 CHECKPOINT Ingen kontrollpunkt har inträffat sedan den senaste loggtrunkeringen, eller så har logghuvudet ännu inte flyttats bortom en virtuell loggfil (VLF) (Alla återställningsmodeller).

Det här är en rutinmässig orsak till att fördröja loggtrunkering. Mer information finns i Database checkpoints (SQL Server).
2 LOG_BACKUP En säkerhetskopia av loggen krävs innan transaktionsloggen kan kortas ned. (Endast fullständig eller massloggad återställningsmodell)

När nästa loggsäkerhetskopiering är klar kan en del loggutrymme återanvändas.
3 ACTIVE_BACKUP_OR_RESTORE En datasäkerhetskopia eller en återställning pågår (Alla återställningsmodeller).

Om en säkerhetskopiering förhindrar loggtrunkering kan det omedelbara problemet lösas genom att avbryta säkerhetskopieringen.
4 ACTIVE_TRANSACTION En transaktion är aktiv (alla återställningsmodeller):

Det kan finnas en långvarig transaktion i början av loggbackupen. I det här fallet kan det krävas ytterligare en loggbackup för att frigöra utrymmet. Långvariga transaktioner förhindrar loggtrunkering under alla återställningsmodeller, inklusive den enkla återställningsmodellen, enligt vilken transaktionsloggen vanligtvis trunkeras på varje automatisk kontrollpunkt.

En transaktion skjuts upp. En uppskjuten transaktion är i själva verket en aktiv transaktion vars återställning blockeras på grund av en resurs som inte är tillgänglig. Information om orsakerna till uppskjutna transaktioner och hur du flyttar dem från uppskjutet tillstånd finns i Uppskjutna transaktioner (SQL Server).

Långvariga transaktioner kan också fylla tempdb:s transaktionslogg. tempdb används implicit av användartransaktioner för interna objekt, till exempel arbetstabeller för sortering, arbetsfiler för hashning, arbetstabeller för markörer och radversioner. Även om användartransaktionen endast innehåller läsning av data (SELECT frågor) kan interna objekt skapas och användas under användartransaktioner. Sedan kan tempdb transaktionsloggen fyllas i.
5 DATABASE_MIRRORING Databasspeglingen pausas eller under högpresterande läge ligger speglingsdatabasen betydligt bakom huvuddatabasen. (Endast fullständig återställningsmodell).

Mer information finns i Database Mirroring (SQL Server).
6 REPLICATION Under transaktionsreplikeringar tas transaktioner som är relevanta för publikationerna fortfarande bort från distributionsdatabasen. (Endast fullständig återställningsmodell)

Information om transaktionsreplikering finns i SQL Server Replication.
7 DATABASE_SNAPSHOT_CREATION En ögonblicksbild av databasen skapas (alla återställningsmodeller).

Detta är en rutinmässig, vanligtvis kort, orsak till att loggtrunkering fördröjs.
8 LOG_SCAN En logggenomsökning sker (alla återställningsmodeller).

Detta är en rutinmässig och vanligtvis kort orsak till fördröjd loggtrunkering.
9 AVAILABILITY_REPLICA En sekundär replik av en tillgänglighetsgrupp tillämpar transaktionsloggposter för den här databasen på en motsvarande sekundär databas. (Endast fullständig återställningsmodell).

Mer information finns i Vad är en AlwaysOn-tillgänglighetsgrupp?.
10 - Endast för internt bruk
11 - Endast för internt bruk
12 - Endast för internt bruk
13 OLDEST_PAGE Om en databas är konfigurerad för att använda indirekta kontrollpunkter kan den äldsta sidan i databasen vara äldre än kontrollpunkten loggsekvensnummer (LSN). I det här fallet kan den äldsta sidan fördröja trunkeringen av loggen (alla återställningsmodeller).

Information om indirekta kontrollpunkter finns i Database checkpoints (SQL Server).
14 OTHER_TRANSIENT Det här värdet används för närvarande inte.
16 XTP_CHECKPOINT En In-Memory OLTP-kontrollpunkt måste utföras. För minnesoptimerade tabeller tas en automatisk kontrollpunkt när transaktionsloggfilen blir större än 1,5 GB sedan den senaste kontrollpunkten (innehåller både diskbaserade och minnesoptimerade tabeller).

Mer information finns i Kontrollpunktoperation för Memory-Optimized Tabeller och Loggnings- och Kontrollpunktsprocessen för In-Memory Optimerade tabeller.

Åtgärder som kan loggas minimalt

Minimal loggning innebär att endast logga den information som krävs för att återställa transaktionen, utan stöd för återställning till en specifik tidpunkt. Den här artikeln identifierar de åtgärder som är minimalt loggade under den massloggade återställningsmodellen (samt under den enkla återställningsmodellen, förutom när en säkerhetskopia körs).

Minimal loggning stöds inte för minnesoptimerade tabeller.

Under den fullständiga återställningsmodellenloggas alla massåtgärder fullständigt. Du kan dock minimera loggningen för en uppsättning massåtgärder genom att tillfälligt växla databasen till den massloggade återställningsmodellen för massåtgärder. Minimal loggning är effektivare än fullständig loggning, och det minskar risken för en storskalig massåtgärd som fyller det tillgängliga transaktionsloggutrymmet under en masstransaktion. Men om databasen skadas eller går förlorad när minimal loggning är i kraft kan du inte återställa databasen till felpunkten.

Följande åtgärder, som är helt loggade under den fullständiga återställningsmodellen, loggas minimalt under den enkla och massloggade återställningsmodellen:

  • Massimportåtgärder (bcp, BULK INSERToch INSERT). Mer information om när massimport till en tabell är minimalt loggad finns i Krav för minimal loggning i massimport.

    När transaktionsreplikering är aktiverat loggas BULK INSERT åtgärder fullständigt även under den massloggade återställningsmodellen.

  • SELECT – INTO-sats åtgärder.

    När transaktionsreplikering är aktiverat loggas SELECT INTO åtgärder fullständigt även under den massloggade återställningsmodellen.

  • Partiella uppdateringar av datatyper med stort värde med hjälp av .WRITE-satsen i instruktionen UPDATE när du infogar eller lägger till nya data. Minimal loggning används inte när befintliga värden uppdateras. Mer information om datatyper med stora värden finns i Datatyper.

  • WRITETEXT-- och UPDATETEXT--instruktioner när du infogar eller lägger till nya data i text, ntextoch bild datatypkolumner. Minimal loggning används inte när befintliga värden uppdateras.

    Varning

    Satserna WRITETEXT och UPDATETEXT är inaktuella; undvik att använda dem i nya program.

  • Om databasen är inställd på den enkla eller massloggade återställningsmodellen loggas vissa index-DDL-åtgärder minimalt oavsett om åtgärden körs offline eller online. De minimalt loggade indexåtgärderna är följande:

    • CREATE INDEX åtgärder (inklusive indexerade vyer).

    • ALTER INDEX REBUILD eller DBCC DBREINDEX åtgärd.

      Index build-åtgärder använder minimal loggning, men kan fördröjas när en säkerhetskopiering körs samtidigt. Den här fördröjningen orsakas av synkroniseringskraven för minimalt loggade buffertpoolsidor när du använder den enkla eller massloggade återställningsmodellen.

      Varning

      DBCC DBREINDEX-instruktionen är inaktuell; undvika att använda den i nya program.

    • DROP INDEX ny hemskapsåterskapning (om tillämpligt). Avallokering av indexsidan sker alltid fullständigt loggad under en DROP INDEX-operation .

Uppgift Artikel
Hantera transaktionsloggen - Hantera storleken på transaktionsloggfilen

- Felsöka en fullständig transaktionslogg (SQL Server-fel 9002)
Säkerhetskopiera transaktionsloggen (endast fullständig återställningsmodell) - Säkerhetskopiera en transaktionslogg

- Säkerhetskopiera transaktionsloggen när databasen är skadad (SQL Server)
Återställa transaktionsloggen (endast fullständig återställningsmodell) - Återställa en säkerhetskopiering av transaktionsloggar (SQL Server)

Relaterat innehåll