- 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ärdet
FILEGROWTH
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 en
DROP 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) -