The Transaction Log (SQL Server) (Svenska)

  • 10/23/2019
  • 11 minutes to read
    • M
    • D
    • f
    • M
    • s
    • +8

Applies to: SQL Server (all supported versions)

Every SQL Server database has a transaction log that records all transactions and the database modifications made by each transaction.,

transaktionsloggen är en kritisk komponent i databasen. Om det finns ett systemfel behöver du den loggen för att få din databas tillbaka till ett konsekvent tillstånd.

Mer information om transaktionsloggarkitekturen och internal finns i SQL Server Transaction Log Architecture and Management Guide.

Varning

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

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).

operationer som stöds av transaktionsloggen

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

  • individuell 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öder transaktionsreplikering.
  • stödja hög tillgänglighet och katastrofåterställningslösningar: alltid på tillgänglighetsgrupper, databasspegling och loggfrakt.,

individuell transaktionsåterställning

om ett program utfärdar ettROLLBACK uttalande, eller om databasmotorn upptäcker ett fel som förlust av kommunikation med en klient, loggposterna används för att rulla tillbaka 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 skrevs 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. Varje ändring som registreras i loggen som kanske inte har skrivits till datafilerna rullas framåt., Varje ofullständig transaktion som finns i transaktionsloggen rullas sedan tillbaka för att se till att databasens integritet bevaras. Mer information finns i återställnings-och Återställningsöversikt (SQL Server).

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

efter en maskinvaruförlust eller diskfel som påverkar databasfilerna kan du återställa databasen till felpunkten., Du återställer först den sista fullständiga databasbackup och den sista differentialdatabasbackup och återställer sedan den efterföljande sekvensen av transaktionsloggens säkerhetskopieringar till felpunkten.

När du återställer varje loggbackup, använder databasmotorn alla ändringar som spelats in i loggen för att rulla fram alla transaktioner. När den senaste loggbackup återställs använder databasmotorn sedan logginformationen för att rulla tillbaka alla transaktioner som inte var fullständiga vid den tiden. Mer information finns i återställnings-och Återställningsöversikt (SQL Server).,

stöd för transaktionsreplikering

Log Reader-agenten övervakar transaktionsloggen för varje databas som konfigurerats för transaktionsreplikering och kopierar de transaktioner som markerats för replikering från transaktionsloggen till distributionsdatabasen. Mer information finns i hur Transaktionsreplikering fungerar.

stöd för lösningar för hög tillgänglighet och katastrofåterställning

standby-server-lösningarna, alltid på tillgänglighetsgrupper, databasspegling och loggleverans, är starkt beroende av transaktionsloggen.,

i ett scenario med alltid tillgängliga grupper återges varje uppdatering till en databas, Den primära repliken, omedelbart i separata, fullständiga kopior av databasen, de sekundära replikerna. Den primära repliken skickar varje loggpost direkt till de sekundära replikerna, som gäller inkommande loggposter till tillgänglighet gruppdatabaser, kontinuerligt rulla den framåt. För mer information, se alltid på Failoverkluster instanser

i ett loggsändningsscenario skickar den primära servern den aktiva transaktionsloggen för den primära databasen till en eller flera destinationer., Varje sekundär server återställer loggen till sin lokala sekundära databas. Mer information finns i Om Log Shipping.

i ett databasspeglingsscenario reproduceras varje uppdatering till en databas, huvuddatabasen, omedelbart i en separat, fullständig kopia av databasen, spegeldatabasen. Den huvudsakliga serverinstansen skickar varje loggpost omedelbart till spegelserverinstansen, som tillämpar inkommande loggposter till spegeldatabasen och rullar den kontinuerligt framåt. Mer information finns i databasspegling.,

transaktionsloggegenskaper

egenskaper hos transaktionsloggen för SQL Server-databasmotorn:

  • 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-databasmotorn. Mer information finns i transaktionslogg fysisk arkitektur.

  • formatet för loggposter och sidor är inte begränsat till att följa datasidans format.,

  • transaktionsloggen kan implementeras i flera filer. Filerna kan definieras för att expandera automatiskt genom att ställa in värdetFILEGROWTH för loggen. Detta minskar potentialen att få slut på utrymme i transaktionsloggen, samtidigt som man minskar administrativa omkostnader. För mer information, se ALTER DATABASE (Transact-SQL) fil och filgrupp alternativ.

  • mekanismen för att återanvända utrymmet i loggfilerna är snabb och har minimal effekt på transaktionens genomströmning.,

information om transaktionsloggarkitekturen och internal finns i SQL Server Transaction Log Architecture and Management Guide.

transaktionslogg trunkering

Log trunkering frigör utrymme i loggfilen för återanvändning av transaktionsloggen. Du måste regelbundet trunkera din transaktionslogg för att hålla den från att fylla det tilldelade utrymmet. Flera faktorer kan fördröja log trunkering, så övervakning log storlek frågor. Vissa operationer kan loggas minimalt för att minska deras inverkan på transaktionsloggens storlek.,

log trunkering raderar inaktiva virtuella loggfiler (VLF) från den logiska transaktionsloggen i 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 tilldelas fysiska loggfiler.

för att undvika att utrymmet rinner ut, om inte log trunkering försenas av någon anledning, sker trunkering automatiskt efter följande händelser:

  • under den enkla återställningsmodellen, efter en kontrollpunkt.,
  • under fullständig återställningsmodell eller massloggad återställningsmodell, om en kontrollpunkt har inträffat sedan föregående säkerhetskopiering, inträffar trunkering efter en loggbackup (om det inte är en säkerhetskopia av kopieringsskyddad loggbackup).

För mer information, se faktorer som kan fördröja logg trunkering, senare i detta ämne.

Obs

Log trunkering minskar inte storleken på den fysiska loggfilen. För att minska den fysiska storleken på en fysisk loggfil måste du krympa loggfilen. Information om hur du krymper storleken på den fysiska loggfilen finns i hantera storleken på Transaktionsloggfilen.,
tänk dock på faktorer som kan fördröja log trunkering. Om lagringsutrymme krävs igen efter en logg krympa, transaktionsloggen kommer att växa igen och genom att göra det, införa prestanda overhead under log växa verksamhet.

faktorer som kan fördröja logg trunkering

När loggposter förblir aktiva under en lång tid, är transaktionslogg trunkering försenad, och transaktionsloggen kan fylla upp, som vi nämnde tidigare i detta långa ämne.,

viktigt

information om hur du svarar på en fullständig transaktionslogg finns i felsöka en fullständig transaktionslogg (SQL Server Error 9002).

egentligen kan Log trunkering försenas av en mängd olika skäl. Lär dig vad, om något, förhindrar din logg trunkering genom att fråga log_reuse_wait och log_reuse_wait_desc kolumner i sys.databaser katalog. Följande tabell beskriver värdena för dessa kolumner.,

log_reuse_wait värde log_reuse_wait_desc värde beskrivning
0 ingenting för närvarande finns det en eller flera återanvändbara virtuella loggfiler (vlfs).
1 CHECKPOINT ingen checkpoint har inträffat sedan den senaste log trunkering, eller chefen för loggen har ännu inte flyttat bortom en virtuell loggfil (VLF). (Alla återställningsmodeller)
Detta är en rutinmässig anledning till att fördröja log trunkering., Mer information finns i Database Checkpoints (SQL Server).
2 LOG_BACKUP en loggbackup krävs innan transaktionsloggen kan trunkeras. (Endast fullständiga eller massloggade återställningsmodeller)
när nästa loggbackup är klar kan vissa loggutrymme bli återanvändbara.
3 ACTIVE_BACKUP_OR_RESTORE en säkerhetskopia av data eller en återställning pågår (alla återställningsmodeller).
om en databackup förhindrar logg trunkering, kan avbryta säkerhetskopieringen hjälpa det omedelbara problemet.,
4 ACTIVE_TRANSACTION en transaktion är aktiv (alla återställningsmodeller):
en långvarig transaktion kan finnas i början av log-säkerhetskopian. I det här fallet kan frigörandet av utrymmet kräva en annan loggbackup. Observera att långvariga transaktioner förhindrar loggkorrigering under alla återställningsmodeller, inklusive den enkla återställningsmodellen, enligt vilken transaktionsloggen i allmänhet trunkeras på varje automatisk kontrollpunkt.
en transaktion skjuts upp., En uppskjuten transaktion är effektivt en aktiv transaktion vars återgång blockeras på grund av någon otillgänglig resurs. Information om orsakerna till uppskjutna transaktioner och hur du flyttar dem ur uppskjutet tillstånd finns i uppskjutna transaktioner (SQL Server).
långvariga transaktioner kan också fylla i tempdb: s transaktionslogg. Tempdb används implicit av användartransaktioner för interna objekt som arbetstabeller för sortering, arbetsfiler för hashing, markörarbetstabeller och radversionering., Även om användartransaktionen endast innehåller läsdata (SELECT – frågor) kan interna objekt skapas och användas under användartransaktioner. Då kan tempdb-transaktionsloggen fyllas i.
5 DATABASE_MIRRORING databasspegling pausas, eller under högpresterande läge ligger spegeldatabasen betydligt bakom huvuddatabasen. (Endast fullständig återställningsmodell)
mer information finns i databasspegling (SQL Server).,
6 replikering under transaktionsreplikeringar är transaktioner som är relevanta för publikationerna fortfarande inte levererade till distributionsdatabasen. (Endast fullständig återställningsmodell)
information om transaktionsreplikering finns i SQL Server-replikering.
7 DATABASE_SNAPSHOT_CREATION en databasbild skapas. (Alla återställningsmodeller)
Detta är en rutin, och vanligtvis kort, orsak till fördröjd log trunkering.
8 LOG_SCAN en log scan sker., (Alla återställningsmodeller)
Detta är en rutin, och vanligtvis kort, orsak till fördröjd log trunkering.
9 AVAILABILITY_REPLICA en sekundär replik av en tillgänglighetsgrupp tillämpar transaktionsloggposter i denna databas till en motsvarande sekundär databas. (Fullständig återställningsmodell)
mer information finns i översikt över Alltid på Tillgänglighetsgrupper (SQL Server).,
10 för internt bruk endast
11 för internt bruk endast
12 för internt bruk endast
13 för internt bruk
oldest_page om en databas är konfigurerad för att använda indirekta kontrollpunkter kan den äldsta sidan i databasen vara äldre än checkpoint log sequence number (lsn). I det här fallet kan den äldsta sidan fördröja log trunkering. (Alla återställningsmodeller)
för information om indirekta kontrollpunkter, se Database Checkpoints (SQL Server).,
14 OTHER_TRANSIENT detta värde används för närvarande inte.
16 XTP_CHECKPOINT en in-Memory OLTP checkpoint måste utföras.För minnesoptimerade tabeller tas en automatisk kontrollpunkt när transaktionsloggfilen blir större än 1.,5 SE sedan den senaste kontrollpunkten (inkluderar både diskbaserade och minnesoptimerade tabeller)
För mer information, se Kontrollpunktsoperation för Minnesoptimerade tabeller och (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

operationer som kan loggas minimalt

Minimal loggning innebär att endast den information som krävs för att logga in är återvinna transaktionen utan att stödja punkt-i-tid återhämtning., Detta ämne identifierar de operationer som loggas minimalt under massloggad återställningsmodell (såväl som under den enkla återställningsmodellen, utom när en säkerhetskopia körs).

Obs

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

Obs

under hela återställningsmodellen loggas alla bulkoperationer helt. Du kan dock minimera loggning för en uppsättning bulkoperationer genom att byta databasen till den massloggade återställningsmodellen tillfälligt för bulkoperationer.,Minimal loggning är effektivare än full loggning, och det minskar möjligheten till en storskalig bulkoperation som fyller det tillgängliga transaktionsloggutrymmet under en bulktransaktion. Om databasen är skadad eller förlorad när minimal loggning är i kraft kan du dock inte återställa databasen till felpunkten.

följande operationer, som är helt loggade under full recovery-modellen, loggas minimalt under den enkla och massloggade återställningsmodellen:

  • Bulk import operations (bcp, BULK INSERT, och infoga… VÄLJA)., Mer information om när massimport till en tabell är minimalt inloggad finns i förutsättningar för Minimal inloggning i bulkimport.

När transaktionsreplikering är aktiverad loggasBULK INSERT operationer helt även under Massloggad återställningsmodell.

  • välj i operationer.

När transaktionsreplikering är aktiverad loggasSELECT INTO – operationer helt även under massloggad återställningsmodell.,

  • partiella uppdateringar av datatyper med stort värde, med hjälp av.WRITE – klausulen i uppdateringsdeklarationen när du infogar eller lägger till nya data. Observera att minimal loggning inte används när befintliga värden uppdateras. Mer information om datatyper med stort värde finns i datatyper (Transact-SQL).

  • writetext och UPDATETEXT-satser när du infogar eller lägger till nya data i kolumnerna text, ntext och bilddatatyp. Observera att minimal loggning inte används när befintliga värden uppdateras.,

    Varning

    WRITETEXT ochUPDATETEXT – satserna är föråldrade; undvik att använda dem i nya program.

  • om databasen är inställd på den enkla eller massloggade återställningsmodellen loggas vissa index DDL-operationer minimalt om operationen utförs offline eller online. De minimalt loggade indexoperationerna är följande:

    • skapa INDEXOPERATIONER (inklusive indexerade vyer).

    • ändra INDEX REBUILD eller DBCC DBREINDEX operationer.,

      Varning

      DBCC DBREINDEX – satsen är föråldrad; använd den inte i nya applikationer.

      Obs

      Indexbyggnadsoperationer använder minimalloggning men kan försenas när det samtidigt utförs säkerhetskopiering. Denna fördröjning orsakas av synkroniseringskraven för minimalt loggade buffertpoolsidor när du använder den enkla eller massloggade återställningsmodellen.

    • DROP INDEX new heap rebuild (om tillämpligt). Indexsida deallocation under enDROP INDEX operation är alltid helt inloggad.,N databasen är skadad (SQL Server)

    återställa transaktionsloggen (Full Återställningsmodell)

    • Återställ en transaktionslogg Backup (SQL Server)

    Se även

    SQL Server transaktionslogg arkitektur och Hanteringsguide
    kontroll Transaktions hållbarhet
    förutsättningar för Minimal loggning i Bulk Import
    säkerhetskopiera och återställa SQL Server-databaser
    Återställ och Återställningsöversikt (SQL Server)
    databas checkpoints (SQL Server)
    visa eller ändra egenskaperna hos en databas
    återställningsmodeller (SQL Server)
    transaktionslogg säkerhetskopior (SQL Server)
    sys.,dm_db_log_info (Transact-SQL)
    sys.dm_db_log_space_usage (Transact-SQL)

Leave a Comment