Het transactielogboek

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 dit logboek nodig om uw database terug te brengen naar een consistente status.

Zie de architectuur en beheerhandleiding voor SQL Server-transactielogboeken voor informatie over de fysieke en logische architectuur van het transactielogboek.

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. Zie Overzicht herstellen en herstellen (SQL Server) voor meer informatie.

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. Zie Overzicht herstellen en herstellen (SQL Server) voor meer informatie.

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 werkt voor 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 Databasespiegeling (SQL Server) 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. Deze scheiding resulteert in eenvoudige, snelle en robuuste code binnen de SQL Server Database Engine. Zie de fysieke architectuur van het transactielogboek voor 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. U kunt de bestanden zo configureren dat ze automatisch worden uitgebreid door de FILEGROWTH waarde voor het logboek in te stellen. Deze configuratie vermindert de kans op onvoldoende ruimte in het transactielogboek, en vermindert tegelijkertijd de administratieve overhead. Zie ALTER DATABASE (Transact-SQL) bestands- en bestandsgroepopties voor 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-transactielogboeken voor informatie over de fysieke en logische architectuur 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 het effect 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 die gebruikmaakt 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 verderop in dit artikel kunnen vertragen 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 er echter rekening mee dat factoren die het afkappen van logboeken kunnen vertragen. Als de opslagruimte opnieuw is vereist nadat een logboek is verkleind, wordt het transactielogboek weer groter en leidt dit tot prestatie-overhead 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 beschreven.

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.

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 bulksgewijs vastgelegde herstelmodel (en ook 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 bulk-logged herstelmodel.

• SELECT - INTO-clausule bewerkingen.

  Wanneer transactionele replicatie is ingeschakeld, SELECT INTO worden 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 statements zijn verouderd. Vermijd het gebruik ervan in nieuwe toepassingen.

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

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

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

Gerelateerde taken

Verwante inhoud

• architectuur en beheerhandleiding voor SQL Server-transactielogboeken
• Duurzaamheid van transacties beheren
• vereisten voor minimale logboekregistratie in bulkimport
• Back-ups maken en herstellen van SQL Server-databases
• Overzicht van herstel en herstel van gegevens (SQL Server)
• Databasecontrolepunten (SQL Server)
• De eigenschappen van een database weergeven of wijzigen
• Recovery-modellen (SQL Server)
• back-ups van transactielogboeken (SQL Server)
• sys.dm_db_log_info (Transact-SQL)
• sys.dm_db_log_space_usage (Transact-SQL)