The Transaction Log (SQL Server)

• 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.,

het transactielogboek is een essentieel onderdeel van de database. Als er een systeemfout is, hebt u dat logboek nodig om uw database terug te brengen naar een consistente status.

voor informatie over de architectuur van het transactielogboek en de interne gegevens, Zie de handleiding voor architectuur en beheer van het transactielogboek van SQL Server.

door het transactielogboek ondersteunde bewerkingen

het transactielogboek ondersteunt de volgende bewerkingen:

• herstel van individuele transacties.
• herstel van alle onvolledige transacties wanneer SQL Server wordt gestart.
• een gerestaureerde database, bestand, bestandsgroep of pagina doorrollen naar het foutpunt.
• ondersteunt transactionele replicatie.
• ondersteunt oplossingen voor hoge beschikbaarheid en disaster recovery: altijd op beschikbaarheidsgroepen, database mirroring, en log verzenden.,

individuele transactieherstel

als een toepassing een ROLLBACK statement afgeeft, of als de Database-Engine een fout detecteert, zoals het verlies van communicatie met een client, worden de logrecords gebruikt om de wijzigingen die door een onvolledige transactie zijn aangebracht, terug te draaien.,

herstel van alle onvolledige transacties wanneer SQL Server wordt gestart

als een server faalt, kunnen de databases in een toestand worden achtergelaten waarin sommige wijzigingen nooit vanuit de buffercache naar de gegevensbestanden zijn geschreven, en er kunnen enkele wijzigingen zijn door onvolledige transacties in de gegevensbestanden. Wanneer een instantie van SQL Server wordt gestart, wordt een herstel van elke database uitgevoerd. Elke wijziging die in het logboek is opgenomen en die mogelijk niet naar de gegevensbestanden is geschreven, wordt naar voren gerold., Elke onvolledige transactie die in het transactielogboek wordt gevonden, wordt vervolgens teruggedraaid om ervoor te zorgen dat de integriteit van de database behouden blijft. Zie overzicht herstellen en herstellen (SQL Server) voor meer informatie.

een herstelde database, bestand, bestandsgroep of pagina doorsturen naar het punt van mislukking

na een hardwareverlies of schijffout die de databasebestanden beïnvloedt, kunt u de database herstellen naar het punt van mislukking., U herstelt eerst de laatste volledige databaseback-up en de laatste differentiële databaseback-up en herstelt vervolgens de volgende volgorde van de back-ups van het transactielogboek tot op het punt van falen.

Als u elke log back-up terugzet, past de Database-Engine alle wijzigingen in het log opnieuw toe om alle transacties door te sturen. Wanneer de laatste log-back-up is hersteld, gebruikt de Database-Engine vervolgens de log-informatie om alle transacties terug te draaien die op dat moment niet compleet waren. Zie overzicht herstellen en herstellen (SQL Server) voor meer informatie.,

ondersteuning voor transactionele replicatie

De Log Reader Agent controleert het transactielogboek van elke database die is geconfigureerd voor transactionele replicatie en kopieert de voor replicatie gemarkeerde transacties vanuit het transactielogboek naar de distributiedatabase. Zie hoe transactionele replicatie werkt voor meer informatie.

ondersteunt oplossingen voor hoge beschikbaarheid en noodherstel

de oplossingen voor standby-servers, altijd op beschikbaarheidsgroepen, database-mirroring en logverzending, zijn sterk afhankelijk van het transactielogboek.,

in een Always On availability groups-scenario wordt elke update van een database, de primaire replica, onmiddellijk gereproduceerd in afzonderlijke, volledige kopieën van de database, de secundaire replica ‘ s. De primaire replica verzendt elke logboekrecord onmiddellijk naar de secundaire replica ‘ s, die de inkomende logboekrecords toepassen op databases van de beschikbaarheidsgroep en deze voortdurend doorrollen. Zie altijd bij Failoverclusterinstances

In een scenario voor het verzenden van logboeken verzendt de primaire server het actieve transactielogboek van de primaire database naar een of meer bestemmingen., Elke secundaire server herstelt het logboek naar zijn lokale secundaire database. Zie voor meer informatie over Logverzending.

in een database-mirroring-scenario wordt elke update van een database, de hoofddatabase, onmiddellijk gereproduceerd in een aparte, volledige kopie van de database, de mirrordatabase. De hoofdserverinstantie verzendt elke logboekrecord onmiddellijk naar de mirrorserverinstantie, die de inkomende logboekrecords toepast op de mirrordatabase en deze voortdurend doorrolt. Zie Database-Mirroring voor meer informatie.,

Transactielogboekkenmerken

kenmerken van de SQL Server-Databasemotor transactielogboek:

• het transactielogboek wordt geïmplementeerd als een afzonderlijk bestand of een reeks bestanden in de database. De log cache wordt afzonderlijk beheerd van de buffer cache voor data pagina ‘ s, wat resulteert in eenvoudige, snelle en robuuste code binnen de SQL Server Database Engine. Zie fysieke architectuur van het transactielogboek voor meer informatie.

• het formaat van logrecords en pagina ’s is niet beperkt tot het formaat van gegevenspagina’ s.,

• het transactielogboek kan in meerdere bestanden worden geïmplementeerd. De bestanden kunnen worden gedefinieerd om automatisch uit te breiden door het instellen van de FILEGROWTH waarde voor de log. Dit vermindert de kans op een tekort aan ruimte in het transactielogboek, terwijl tegelijkertijd de administratieve overhead wordt verminderd. Zie ALTER DATABASE (Transact-SQL) file and Filegroup Options voor meer informatie.

• het mechanisme om de ruimte in de logbestanden te hergebruiken is snel en heeft een minimaal effect op de transactiedoorvoer.,

voor informatie over de architectuur van het transactielogboek en de interne gegevens, Zie de handleiding voor architectuur en beheer van het transactielogboek van SQL Server.

afkappen van het transactielogboek

afkappen van het logboek maakt ruimte vrij in het logbestand voor hergebruik door het transactielogboek. U moet uw transactielogboek regelmatig afkappen om te voorkomen dat het de toegewezen ruimte vult. Verschillende factoren kunnen het afkappen van logs vertragen, dus het monitoren van de loggrootte is belangrijk. Sommige bewerkingen kunnen minimaal worden gelogd om hun impact op de grootte van het transactielogboek te verminderen.,

log truncation verwijdert inactieve virtuele logbestanden (VLFs) uit het logische transactielogboek van een SQL Server-database, waardoor ruimte in het logische logboek vrijkomt voor hergebruik door het fysieke transactielogboek. Als een transactielogboek nooit wordt afgekapt, vult het uiteindelijk alle schijfruimte die is toegewezen aan fysieke logbestanden.

om te voorkomen dat er te weinig ruimte is, tenzij de log-afkaping om een of andere reden wordt vertraagd, vindt de afkaping automatisch plaats na de volgende gebeurtenissen:

• Onder het simple recovery model, na een controlepunt.,
• Onder het full recovery model of bulk-logged recovery model, als er een controlepunt is opgetreden sinds de vorige back-up, vindt afkaping plaats na een log-back-up (tenzij het een log-back-up is met alleen kopiëren).

voor meer informatie, zie factoren die het afkappen van logs kunnen vertragen, later in dit onderwerp.

factoren die het afkappen van logboeken kunnen vertragen

wanneer logrecords lang actief blijven, wordt het afkappen van transactielogboeken vertraagd en kan het transactielogboek worden opgevuld, zoals we eerder in dit lange onderwerp hebben vermeld.,

echt, Log afkappen kan worden vertraagd door een aantal redenen. Leer wat, als er iets is, het voorkomen van uw log afkappen door het opvragen van de log_reuse_wait en log_reuse_wait_desc kolommen van de sys.databases catalogusweergave. De volgende tabel beschrijft de waarden van deze kolommen.,

log_reuse_wait value	log_reuse_wait_desc value	Description
0	niets	momenteel zijn er een of meer herbruikbare virtuele logbestanden (vlfs).
1	controlepunt	sinds de laatste afkaping van het logbestand is geen controlepunt opgetreden, of de head van het logbestand is nog niet voorbij een virtueel logbestand (VLF) verplaatst. (All recovery models) Dit is een routinematige reden om het afkappen van logs uit te stellen., Zie Databasecontrolepunten (SQL Server) voor meer informatie.
2	LOG_BACKUP	een logback-up is vereist voordat het transactielogboek kan worden afgekapt. (Alleen volledige of bulk-gelogde herstelmodellen) Wanneer de volgende log-back-up is voltooid, kan enige logruimte herbruikbaar worden.
3	ACTIVE_BACKUP_OR_RESTORE	er wordt een back-up of herstel gemaakt (alle herstelmodellen). als een gegevensback-up het afkappen van log voorkomt, kan het annuleren van de back-upbewerking het onmiddellijke probleem helpen.,
4	ACTIVE_TRANSACTION	een transactie is actief (alle herstelmodellen): een langlopende transactie kan bestaan aan het begin van de logback-up. In dit geval kan het nodig zijn om de ruimte vrij te maken om nog een logback-up te maken. Houd er rekening mee dat langlopende transacties voorkomen dat logbestanden worden afgekapt onder alle herstelmodellen, inclusief het simple recovery-model, waarbij het transactielogboek over het algemeen wordt afgekapt op elk automatisch controlepunt. Een transactie wordt uitgesteld., Een uitgestelde transactie is in feite een actieve transactie waarvan de terugdraaiing wordt geblokkeerd vanwege een niet-beschikbare bron. Zie uitgestelde transacties (SQL Server) voor informatie over de oorzaken van uitgestelde transacties en hoe ze uit de uitgestelde status kunnen worden verplaatst. langlopende transacties kunnen ook het transactielogboek van tempdb vullen. Tempdb wordt impliciet gebruikt door gebruikerstransacties voor interne objecten zoals werktabellen voor sorteren, werkbestanden voor hashing, cursor werktabellen en rijversiebeheer., Zelfs als de gebruikerstransactie alleen leesgegevens bevat (SELECT queries), kunnen interne objecten worden gemaakt en gebruikt onder gebruikerstransacties. Dan kan het tempdb transactielogboek worden ingevuld.
5	DATABASE_MIRRORING	Database mirroring is gepauzeerd, of in high-performance mode bevindt de mirror database zich aanzienlijk achter de hoofddatabase. (Alleen Full recovery model) voor meer informatie, zie Database Mirroring (SQL Server).,
6	replicatie	tijdens replicaties van transacties worden transacties die relevant zijn voor de publicaties nog steeds niet aan de distributiedatabank geleverd. (Alleen volledig herstelmodel) Zie SQL Server-replicatie voor informatie over transactionele replicatie.
7	DATABASE_SNAPSHOT_CREATION	er wordt een database-snapshot aangemaakt. (All recovery models) Dit is een routine, en meestal kort, oorzaak van vertraagde log afkappen.
8	LOG_SCAN	er vindt een logscan plaats., (All recovery models) Dit is een routine, en meestal kort, oorzaak van vertraagde log afkappen.
9	BESCHIKBAARHEID_REPLICA	een secundaire replica van een beschikbaarheidsgroep past transactielogboekrecords van deze database toe op een overeenkomstige secundaire database. (Full recovery model) voor meer informatie, zie overzicht van Always On Availability Groups (SQL Server).,
10	–	voor intern gebruik	11	–	voor intern gebruik	12	–	voor intern gebruik	13	oldest_page	als een database is geconfigureerd om indirecte controlepunten te gebruiken, kan de oudste pagina in de database ouder zijn dan het ControlPoint log sequence number (LSN). In dit geval kan de oudste pagina het afkappen van logs vertragen. (All recovery models) voor informatie over indirecte checkpoints, zie Database Checkpoints (SQL Server).,
14	OTHER_TRANSIENT	deze waarde wordt momenteel niet gebruikt.
16	XTP_CHECKPOINT	er moet een OLTP-controlepunt in het geheugen worden uitgevoerd.Voor geheugen-geoptimaliseerde tabellen wordt een automatisch controlepunt genomen wanneer het transactielogboekbestand groter wordt dan 1.,5 GB sinds het laatste controlepunt (inclusief zowel disk-based als geheugen-geoptimaliseerde tabellen) voor meer informatie zie Controlepuntbewerking voor geheugen-geoptimaliseerde tabellen en (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

operaties die minimaal gelogd kunnen worden

minimale logging houdt in dat alleen de informatie wordt geregistreerd die nodig is om de transactie te herstellen zonder ondersteuning van Point-In-Time herstel., Dit onderwerp identificeert de bewerkingen die minimaal worden gelogd onder het bulk-logged herstelmodel (evenals onder het simple recovery model, behalve wanneer een back-up wordt uitgevoerd).

de volgende bewerkingen, die volledig zijn gelogd onder het full recovery model, worden minimaal gelogd onder het simple and bulk-logged recovery model:

• Bulk import operaties (BCP, BULK INSERT, en INSERT… SELECTEREN)., Zie vereisten voor minimale registratie bij bulkimport voor meer informatie over wanneer bulkimport in een tabel minimaal wordt geregistreerd.

wanneer transactionele replicatie is ingeschakeld, wordenBULK INSERT bewerkingen volledig gelogd, zelfs onder het Bulk gelogde herstelmodel.

• selecteer in operaties.

wanneer transactionele replicatie is ingeschakeld, wordenSELECT INTO bewerkingen volledig gelogd, zelfs onder het bulk gelogde herstelmodel.,

• gedeeltelijke updates voor gegevenstypen met grote waarde, met behulp van de.WRITE clausule in de UPDATE statement bij het invoegen of toevoegen van nieuwe gegevens. Merk op dat minimale logging niet wordt gebruikt wanneer bestaande waarden worden bijgewerkt. Zie gegevenstypen (Transact-SQL) voor meer informatie over gegevenstypen met grote waarde.

• writetext en UPDATETEXT statements bij het invoegen of toevoegen van nieuwe gegevens in de kolommen tekst, ntext en afbeeldingstype. Merk op dat minimale logging niet wordt gebruikt wanneer bestaande waarden worden bijgewerkt.,

  waarschuwing

  deWRITETEXT enUPDATETEXT statements zijn verouderd; vermijd het gebruik ervan in nieuwe toepassingen.

• als de database is ingesteld op het eenvoudige of bulk-gelogde herstelmodel, worden sommige index-DDL-bewerkingen minimaal gelogd, ongeacht of de bewerking offline of online wordt uitgevoerd. De minimaal gelogde indexbewerkingen zijn als volgt:

  • creëer INDEXBEWERKINGEN (inclusief geïndexeerde weergaven).

  • alter INDEX REBUILD of DBCC DBREINDEX operaties.,

    waarschuwing

    HetDBCC DBREINDEX statement is verouderd; gebruik het niet in nieuwe toepassingen.

    Note

    Index build-bewerkingen maken gebruik van minimale logging, maar kunnen vertraagd worden als er tegelijkertijd een back-up wordt uitgevoerd. Deze vertraging wordt veroorzaakt door de synchronisatievereisten van minimaal gelogde bufferpool-pagina ‘ s bij het gebruik van het eenvoudige of bulk-gelogde herstelmodel.

  • DROP INDEX nieuwe hoop opnieuw opbouwen (indien van toepassing). Index pagina deallocatie tijdens eenDROP INDEX operatie wordt altijd volledig gelogd.,n de Database is beschadigd (SQL Server)

  het transactielogboek herstellen (Full Recovery Model)

  • een transactielogboek back-uppen (SQL Server)

  zie ook

  SQL Server Transactielogboekarchitectuur en Beheergids
  controle transactielogboek duurzaamheid
  vereisten voor minimale registratie bij bulkimport
  Back-Up en herstel van SQL Server-Databases
  herstellen en herstellen overzicht (SQL Server)
  database checkpoints (SQL Server)
  De Eigenschappen van een database weergeven of wijzigen
  Herstelmodellen (SQL Server)
  back-ups van transactielogbestanden (SQL Server)
  sys.,dm_db_log_info (Transact-SQL)
  sys. dm_db_log_space_usage (Transact-SQL)