Delen via

Het transactielogboek

  • Artikel

van toepassing op:SQL Server-

Elke SQL Server-database heeft een transactielogboek dat alle transacties en de databasewijzigingen registreert die door elke transactie zijn aangebracht.

Het transactielogboek is een essentieel onderdeel van de database. Als er een systeemfout opgetreden is, hebt u dat logboek nodig om uw database weer in een consistente status te brengen.

Waarschuwing

Verwijder of verplaats dit logboek nooit, tenzij u de gevolgen hiervan volledig begrijpt.

Zie de architectuur en beheerhandleiding voor SQL Server-transactielogboekenvoor informatie over de architectuur en interne gegevens van het transactielogboek.

Tip

Controlepunten creëren bekende referentiepunten om transactielogboeken toe te passen tijdens databaseherstel. Zie Database-controlepunten (SQL Server)voor meer informatie.

Bewerkingen die worden ondersteund door het transactielogboek

Het transactielogboek ondersteunt de volgende bewerkingen:

  • Herstel van afzonderlijke transacties.
  • Herstel van alle onvolledige transacties wanneer SQL Server wordt gestart.
  • Een herstelde database, bestand, bestandsgroep of pagina doorsturen naar het foutpunt.
  • Ondersteuning voor transactionele replicatie.
  • Ondersteuning voor oplossingen voor hoge beschikbaarheid en herstel na noodgevallen: AlwaysOn-beschikbaarheidsgroepen, databasespiegeling en logboekverzending.

Herstel van afzonderlijke transacties

Als een toepassing een ROLLBACK instructie uitgeeft of als de database-engine een fout detecteert, zoals het verlies van communicatie met een client, worden de logboekrecords gebruikt om de wijzigingen die zijn aangebracht door een onvolledige transactie terug te draaien.

Herstel van alle onvolledige transacties wanneer SQL Server wordt gestart

Als een server uitvalt, blijven de databases mogelijk in een toestand waarin sommige wijzigingen nooit uit de buffercache naar de gegevensbestanden zijn geschreven en er mogelijk enkele wijzigingen zijn ten opzichte van onvolledige transacties in de gegevensbestanden. Wanneer een exemplaar van SQL Server wordt gestart, wordt er een herstel van elke database uitgevoerd. Elke wijziging die is vastgelegd in het logboek dat mogelijk niet naar de gegevensbestanden is geschreven, wordt doorgestuurd. Elke onvolledige transactie in het transactielogboek wordt vervolgens teruggedraaid om ervoor te zorgen dat de integriteit van de database behouden blijft. Voor meer informatie, zie Overzicht van herstellen en herstel (SQL Server).

Een herstelde database, bestand, bestandsgroep of pagina doorsturen naar het foutpunt

Na een hardwareverlies of schijfstoring die van invloed is op de databasebestanden, kunt u de database herstellen naar het foutpunt. 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 naar het foutpunt.

Wanneer u elke logboekback-up herstelt, past de database-engine alle wijzigingen die in het logboek zijn vastgelegd opnieuw toe om alle transacties door te sturen. Wanneer de laatste logboekback-up is hersteld, gebruikt de database-engine vervolgens de logboekgegevens om alle transacties terug te draaien die op dat moment niet zijn voltooid. Voor meer informatie, zie Overzicht van herstel en herstelprocedures (SQL Server).

Ondersteuning voor transactionele replicatie

De logboeklezeragent bewaakt het transactielogboek van elke database die is geconfigureerd voor transactionele replicatie en kopieert de transacties die zijn gemarkeerd voor replicatie vanuit het transactielogboek naar de distributiedatabase. Zie Hoe transactionele replicatie werktvoor meer informatie.

Ondersteuning voor oplossingen voor hoge beschikbaarheid en herstel na noodgevallen

De stand-byserveroplossingen, AlwaysOn-beschikbaarheidsgroepen, databasespiegeling en logboekverzending zijn sterk afhankelijk van het transactielogboek.

In een scenario AlwaysOn-beschikbaarheidsgroepen, wordt elke update van een database op de primaire replica onmiddellijk gereproduceerd in de afzonderlijke kopieën van de database op alle secundaire replica's. De primaire replica verzendt elke logboekrecord onmiddellijk naar de secundaire replica's, die de binnenkomende logboekrecords toepassen op de beschikbaarheidsdatabases, waardoor het logboek voortdurend wordt doorgestuurd. Zie AlwaysOn-failoverclusterexemplaren (SQL Server)voor meer informatie.

In een scenario voor het verzenden van logboeken, verzendt de primaire server de back-ups van het transactielogboek van de primaire database naar een of meer bestemmingen. Elke secundaire server herstelt de logboekback-ups naar de lokale secundaire database. Zie Over logboekverzending (SQL Server)voor meer informatie.

In een databasespiegelingsscenario, wordt elke update van een database, de principal-database, onmiddellijk gereproduceerd in een afzonderlijke, volledige kopie van de database, de gespiegelde database. De hoofdserverinstantie verzendt elke logboekrecord onmiddellijk naar de instantie van de mirror-server, die de binnenkomende logboekrecords toepast op de gespiegelde database, waardoor deze voortdurend verder wordt verwerkt. Zie SQL Server-(Database Mirroring) voor meer informatie.

Kenmerken van transactielogboeken

Kenmerken van het transactielogboek van de SQL Server Database Engine:

  • Het transactielogboek wordt geïmplementeerd als een afzonderlijk bestand of een set bestanden in de database. De logboekcache wordt afzonderlijk beheerd van de buffercache voor gegevenspagina's, wat resulteert in eenvoudige, snelle en robuuste code binnen de SQL Server Database Engine. Zie fysieke architectuur van het transactielogboekvoor meer informatie.

  • De indeling van logboekrecords en -pagina's is niet beperkt om de indeling van gegevenspagina's te volgen.

  • Het transactielogboek kan in verschillende bestanden worden geïmplementeerd. De bestanden kunnen worden gedefinieerd om automatisch uit te vouwen door de FILEGROWTH waarde voor het logboek in te stellen. Dit vermindert het potentieel van onvoldoende ruimte in het transactielogboek, terwijl tegelijkertijd administratieve overhead wordt verminderd. Zie ALTER DATABASE (Transact-SQL) File and Filegroup Optionsvoor meer informatie.

  • Het mechanisme voor het hergebruik van de ruimte in de logboekbestanden is snel en heeft een minimale invloed op de transactiedoorvoer.

Zie de architectuur en beheerhandleiding voor SQL Server-transactielogboekenvoor informatie over de architectuur en interne gegevens van het transactielogboek.

Inkorting van transactielogboek

Met afkapping van logboeken wordt ruimte vrijgemaakt in het logboekbestand voor hergebruik door het transactielogboek. U moet uw transactielogboek regelmatig trunceren om te voorkomen dat het de beschikbare ruimte volledig vult. Verschillende factoren kunnen de truncatie van logs vertragen, dus het bewaken van de loggrootte is belangrijk. Sommige bewerkingen kunnen minimaal worden geregistreerd om de impact op de grootte van transactielogboeken te verminderen.

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

Om te voorkomen dat er een ruimtetekort ontstaat, wordt de truncatie automatisch uitgevoerd na de volgende gebeurtenissen, tenzij de logboektruncatie om een of andere reden wordt vertraagd.

  • In het eenvoudige herstelmodel, na een controlepunt.

  • Als onder het volledige herstelmodel of het bulksgewijs vastgelegde herstelmodel een controlepunt is opgetreden sinds de vorige back-up, wordt afkap uitgevoerd na een logboekback-up (tenzij het een back-up voor alleen-kopiëren is).

  • Wanneer u voor het eerst een database maakt met behulp van het volledige herstelmodel, wordt het transactielogboek indien nodig opnieuw gebruikt (vergelijkbaar met een database met behulp van het eenvoudige herstelmodel), totdat u een volledige databaseback-up maakt.

Zie Factoren die het afkappen van logboeken kunnen vertragenverderop in dit artikel voor meer informatie.

Door het afkappen van logboeken wordt de grootte van het fysieke logboekbestand niet verkleind. Als u de fysieke grootte van een fysiek logboekbestand wilt verkleinen, moet u het logboekbestand verkleinen. Zie De grootte van het transactielogboekbestand beherenvoor meer informatie over het verkleinen van de grootte van het fysieke logboekbestand. Houd echter rekening met Factoren die het afkappen van logboeken kunnen vertragen. Als de opslagruimte opnieuw nodig is nadat een logboek is verkleind, zal het transactielogboek opnieuw groeien en daardoor de prestatie-overhead veroorzaken tijdens het vergroten van logboekbewerkingen.

Factoren die het inkorten van logboeken kunnen vertragen

Wanneer logboekrecords lang actief blijven, wordt het afkappen van het transactielogboek vertraagd en kan het transactielogboek worden opgevuld, zoals eerder in dit artikel is vermeld.

Belangrijk

Zie Problemen met een volledig transactielogboek (SQL Server-fout 9002) oplossenvoor informatie over het reageren op een volledig transactielogboek.

Truncatie van logbestanden kan om verschillende redenen worden vertraagd. Als u wilt weten wat het afkappen van logboeken verhindert, voert u een query uit op de kolommen log_reuse_wait en log_reuse_wait_desc van de sys.databases catalogusweergave. In de volgende tabel worden de waarden van deze kolommen beschreven.

log_reuse_wait waarde waarde log_reuse_wait_desc Beschrijving
0 NOTHING Er zijn momenteel een of meer herbruikbare virtuele logboekbestanden (VLF's).
1 CHECKPOINT Er is geen controlepunt opgetreden sinds de laatste afkapping van het logboek, of het hoofd van het logboek is nog niet verplaatst buiten een virtueel logboekbestand (VLF) (Alle herstelmodellen).

Dit is een routinematige reden voor het vertragen van logboektruncatie. Zie Database-controlepunten (SQL Server)voor meer informatie.
2 LOG_BACKUP Een logboekback-up is vereist voordat het transactielogboek kan worden afgekapt. (Alleen volledig of bulksgewijs vastgelegde herstelmodellen)

Wanneer de volgende logboekback-up is voltooid, kan sommige logboekruimte opnieuw worden gebruikt.
3 ACTIVE_BACKUP_OR_RESTORE Er wordt een back-up van gegevens of een herstelbewerking uitgevoerd (alle herstelmodellen).

Als een databack-up het bijwerken van logboeken verhindert, kan het annuleren van de back-upbewerking het onmiddellijke probleem helpen oplossen.
4 ACTIVE_TRANSACTION Een transactie is actief (alle herstelmodellen):

Aan het begin van de logboekback-up kan een langlopende transactie bestaan. In dit geval kan het vrijmaken van de ruimte een andere logboekback-up vereisen. Langlopende transacties voorkomen dat logboeken worden afgekapt onder alle herstelmodellen, waaronder het eenvoudige herstelmodel, waaronder het transactielogboek over het algemeen wordt afgekapt op elk automatisch controlepunt.

Een transactie wordt uitgesteld. Een uitgestelde transactie is effectief een actieve transactie waarvan het terugdraaien wordt geblokkeerd vanwege een bepaalde niet-beschikbare resource. Zie Deferred Transactions (SQL Server)voor informatie over de oorzaken van uitgestelde transacties en hoe u ze uit de uitgestelde status verplaatst.

Langlopende transacties kunnen ook het transactielogboek van tempdbvullen. tempdb wordt impliciet gebruikt door gebruikerstransacties voor interne objecten, zoals werktabellen voor sorteren, werkbestanden voor hashing, cursorwerktabellen en rijversiebeheer. Zelfs als de gebruikerstransactie alleen het lezen van gegevens (SELECT query's) bevat, kunnen interne objecten worden gemaakt en gebruikt onder gebruikerstransacties. Vervolgens kan het tempdb transactielogboek worden gevuld.
5 DATABASE_MIRRORING Databasespiegeling is gepauzeerd, of in de hoge-prestatiemodus staat de gespiegelde database aanzienlijk achter de hoofd-database. (Alleen volledig herstelmodel).

Zie SQL Server-(Database Mirroring) voor meer informatie.
6 REPLICATION Tijdens transactionele replicaties worden transacties die relevant zijn voor de publicaties nog steeds niet geleverd aan de distributiedatabase. (Alleen volledig herstelmodel)

Zie SQL Server-replicatievoor informatie over transactionele replicatie.
7 DATABASE_SNAPSHOT_CREATION Er wordt een momentopname van een database gemaakt (alle herstelmodellen).

Dit is een routinematige en meestal korte reden voor vertraging bij het inkorten van logs.
8 LOG_SCAN Er wordt een logboekscan uitgevoerd (alle herstelmodellen).

Dit is een routinematige en meestal korte oorzaak voor het vertraagd afkappen van logboeken.
9 AVAILABILITY_REPLICA Een secundaire replica van een beschikbaarheidsgroep is het toepassen van transactielogboekrecords van deze database op een bijbehorende secundaire database. (Alleen het volledige herstelmodel).

Voor meer informatie, zie Wat is een Always On-beschikbaarheidsgroep?.
10 - Alleen voor intern gebruik
11 - Alleen voor intern gebruik
12 - Alleen voor intern gebruik
13 OLDEST_PAGE Als een database is geconfigureerd voor het gebruik van indirecte controlepunten, is de oudste pagina in de database mogelijk ouder dan het controlepunt LSN-. In dit geval kan de oudste pagina de afkapping van logboeken vertragen (alle herstelmodellen).

Zie Database-controlepunten (SQL Server)voor informatie over indirecte controlepunten.
14 OTHER_TRANSIENT Deze waarde wordt momenteel niet gebruikt.
16 XTP_CHECKPOINT Er moet een In-Memory OLTP-checkpoint worden uitgevoerd. Voor tabellen die zijn geoptimaliseerd voor geheugen, wordt een automatisch controlepunt gebruikt wanneer het transactielogboekbestand groter wordt dan 1,5 GB sinds het laatste controlepunt (inclusief tabellen op basis van schijf en geoptimaliseerd voor geheugen).

Voor meer informatie, zie Controlepuntbewerking voor tabellen Memory-Optimized en het logboek- en controlepuntproces voor geoptimaliseerde tabellen In-Memory.

Bewerkingen die minimaal kunnen worden geregistreerd

Minimale logboekregistratie omvat het vastleggen van alleen de gegevens die nodig zijn om de transactie te herstellen zonder ondersteuning voor herstel naar een bepaald tijdstip. In dit artikel worden de bewerkingen geïdentificeerd die minimaal zijn vastgelegd onder het bulkgewijs vastgelegde herstelmodel (en onder het eenvoudige herstelmodel, behalve wanneer een back-up wordt uitgevoerd).

Minimale logboekregistratie wordt niet ondersteund voor tabellen die zijn geoptimaliseerd voor geheugen.

Onder het volledige herstelmodelworden alle bulkbewerkingen volledig geregistreerd. U kunt logboekregistratie voor een set bulkbewerkingen echter minimaliseren door de database tijdelijk over te schakelen naar het bulksgewijs vastgelegde herstelmodel voor bulkbewerkingen. Minimale logboekregistratie is efficiënter dan volledige logboekregistratie en vermindert de kans dat een grootschalige bulkbewerking de beschikbare transactielogboekruimte tijdens een bulktransactie vult. Als de database echter beschadigd is of verloren gaat wanneer minimale logboekregistratie van kracht is, kunt u de database niet herstellen naar het storingspunt.

De volgende bewerkingen, die volledig zijn vastgelegd onder het volledige herstelmodel, worden minimaal vastgelegd onder het eenvoudige en bulksgewijs vastgelegde herstelmodel:

  • Bulkimportbewerkingen (bcp, BULK INSERTen INSERT). Zie Vereisten voor minimale logging bij bulkimportvoor meer informatie over wanneer het bulksgewijs importeren in een tabel minimaal wordt gelogd.

    Wanneer transactionele replicatie is ingeschakeld, worden BULK INSERT bewerkingen volledig geregistreerd, zelfs onder het bulksgewijs vastgelegde herstelmodel.

  • SELECT - INTO-clausule bewerkingen.

    Wanneer transactionele replicatie is ingeschakeld, worden SELECT INTO bewerkingen volledig geregistreerd, zelfs onder het bulksgewijs vastgelegde herstelmodel.

  • Gedeeltelijke updates voor gegevenstypen met een grote waarde, met behulp van de .WRITE component in de instructie UPDATE bij het invoegen of toevoegen van nieuwe gegevens. Minimale logboekregistratie wordt niet gebruikt wanneer bestaande waarden worden bijgewerkt. Zie Gegevenstypenvoor meer informatie over gegevenstypen met een grote waarde.

  • WRITETEXT en UPDATETEXT instructies voor het invoegen of toevoegen van nieuwe gegevens aan de tekst, ntexten afbeelding gegevenstype-kolommen. Minimale logboekregistratie wordt niet gebruikt wanneer bestaande waarden worden bijgewerkt.

    Waarschuwing

    De WRITETEXT- en UPDATETEXT-instructies zijn verouderd verklaard; vermijd het gebruik ervan in nieuwe toepassingen.

  • Als de database is ingesteld op het eenvoudige of bulksgewijs vastgelegde herstelmodel, worden sommige DDL-indexbewerkingen minimaal geregistreerd, ongeacht of de bewerking offline of online wordt uitgevoerd. De minimaal vastgelegde indexbewerkingen zijn als volgt:

    • CREATE INDEX bewerkingen (inclusief geïndexeerde weergaven).

    • ALTER INDEX REBUILD of DBCC DBREINDEX de bewerking.

      Indexbuildbewerkingen maken gebruik van minimale logboekregistratie, maar kunnen worden vertraagd wanneer er gelijktijdig een back-up wordt uitgevoerd. Deze vertraging wordt veroorzaakt door de synchronisatievereisten van minimaal vastgelegde buffergroeppagina's wanneer u het eenvoudige of bulksgewijs vastgelegde herstelmodel gebruikt.

      Waarschuwing

      De DBCC DBREINDEX-instructie is verouderd; vermijd het gebruik ervan in nieuwe applicaties.

    • DROP INDEX nieuwe heap-herbouw (indien van toepassing). De deallocatie van de indexpagina tijdens een DROP INDEX bewerking wordt altijd volledig geregistreerd.

Taak Artikel
Het transactielogboek beheren - De grootte van het transactielogboekbestand beheren

- Problemen met een volledig transactielogboek (SQL Server-fout 9002) oplossen
Een back-up maken van het transactielogboek (alleen volledig herstelmodel) - een back-up maken van een transactielogboek

- een back-up maken van het transactielogboek wanneer de database is beschadigd (SQL Server)
Het transactielogboek herstellen (alleen volledig herstelmodel) - een back-up van een transactielogboek (SQL Server) herstellen

Verwante inhoud