Transaktionsloggen

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 den här loggen för att återställa databasen till ett konsekvent tillstånd.

Information om transaktionsloggens fysiska och logiska arkitektur finns i arkitekturen och hanteringsguiden för SQL Server-transaktionsloggar.

Å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 återställning (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 återställning (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 Så här fungerar transaktionsreplikering.

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 Databasspegling (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. Den här separationen 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. Du kan konfigurera filerna så att de expanderas automatiskt genom att ange FILEGROWTH värdet för loggen. Den här konfigurationen 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 transaktionsloggens fysiska och logiska arkitektur finns i arkitekturen och hanteringsguiden för SQL Server-transaktionsloggar.

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 effekt 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 som använder den fullständiga återställningsmodellen återanvänds transaktionsloggen efter behov (ungefär som en databas med hjälp av den enkla återställningsmodellen) fram tills du skapar en fullständig säkerhetskopia av databasen.

Mer information finns i Faktorer som kan fördröja loggtrunkeringen senare 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 loggtrunkeringen. Om lagringsutrymmet krävs igen efter att en logg krympt växer transaktionsloggen igen och medför därmed 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 fyllas i enligt beskrivningen tidigare i den här artikeln.

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.

Åtgärder som kan loggas minimalt

Minimal loggning omfattar endast loggning av den information som krävs för att återställa transaktionen utan stöd för återställning till tidpunkt. Den här artikeln identifierar de åtgärder som är minimalt loggade under den massloggade återställningsmodellen (och även 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 BULK INSERT loggas åtgärderna fullständigt även under den massloggade återställningsmodellen.

• SELECT – INTO-sats åtgärder.

  När transaktionsreplikering är aktiverat SELECT INTO loggas åtgärderna 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

  - WRITETEXT instruktionerna 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:

  • 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 det finns en säkerhetskopiering som 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

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

  • DROP INDEX ny hemskapsåterskapning (om tillämpligt). Indexsidans frigöring under en DROP INDEX åtgärd loggas alltid helt.

Relaterade uppgifter

Relaterat innehåll

• arkitektur och hanteringsguide för SQL Server-transaktionsloggar
• Kontrollera transaktionshållbarhet
• Förutsättningar för Minimal Loggning i Massimport
• Säkerhetskopiera och återställa SQL Server-databaser
• Översikt över återställning och återställning (SQL Server)
• Databaskontrollpunkter (SQL Server)
• Visa eller ändra egenskaperna för en databas
• Recovery-modeller (SQL Server)
• säkerhetskopieringar av transaktionsloggar (SQL Server)
• sys.dm_db_log_info (Transact-SQL)
• sys.dm_db_log_space_usage (Transact-SQL)