Je bent nu offline; er wordt gewacht tot er weer een internetverbinding is

De browser wordt niet ondersteund

Werk de browser bij als je de site wilt gebruiken.

Werk de browser bij naar de nieuwste versie van Internet Explorer

Een transactielogboek neemt onverwacht toe of raakt vol op een computer waarop SQL Server wordt uitgevoerd

Samenvatting
Als in SQL Server 7.0, SQL Server 2000 of SQL Server 2005 de optie Autogrow is ingeschakeld, kunnen transactielogboekbestanden automatisch groter worden.

De grootte van het transactielogboekbestand blijft meestal gelijk wanneer het bestand het maximum aantal transacties kan bevatten dat kan plaatsvinden tussen opschoningen van het transactielogboek als gevolg van het bereiken van herstelpunten of het maken van back-ups van transactielogboeken.

In sommige situaties kan het transactielogboek echter uitzonderlijk groot worden, waardoor er onvoldoende ruimte beschikbaar is. Het logboek kan ook helemaal vol raken. Meestal ontvangt u het volgende foutbericht wanneer een transactielogboekbestand de beschikbare schijfruimte inneemt en niet meer kan groeien:
Error: 9002, Severity: 17, State: 2
The log file for database '%.*ls' is full.
Als u werkt met SQL Server 2005, wordt er een foutbericht van de volgende strekking weergegeven:
Error: 9002, ernst: 17, status: 2
The transaction log for database '%.*ls' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases
Het is mogelijk dat naast het weergeven van dit foutbericht databases als verdacht worden aangemerkt door SQL Server omdat er geen ruimte meer is voor uitbreiding van het transactielogboek. Lees voor meer informatie over het oplossen van dit probleem het onderwerp 'Insufficient Disk Space' in SQL Server Books Online.

De groei van transactielogboeken kan de volgende gevolgen hebben:
  • Een uitzonderlijk groot transactielogboekbestand.
  • Transacties mislukken en er wordt een rollback uitgevoerd.
  • Transacties nemen erg veel tijd in beslag.
  • De systeemprestaties lopen terug.
  • Transacties worden geblokkeerd.

Oorzaken

Transactielogboeken kunnen groeien als gevolg van de volgende oorzaken of scenario's: Opmerking In SQL Server 2005 kunt u de kolommen log_reuse_wait en log_reuse_wait_desc in de catalogusweergave van sys.databases bekijken als u het volgende wilt weten:
  • Waarom de ruimte in het transactielogboek niet opnieuw wordt gebruikt.
  • Waarom het transactielogboek niet kan worden afgekapt.

Niet-doorgevoerde transacties

Expliciete transacties worden alleen doorgevoerd na een expliciete COMMIT- of ROLLBACK-opdracht. Deze situatie treedt meestal op wanneer een toepassing een opdracht CANCEL of Transact-SQL KILL uitvoert zonder een bijbehorende ROLLBACK-opdracht. De transactie wordt in dat geval geannuleerd, maar er wordt geen rollback uitgevoerd. Het gevolg is dat niet alle volgende transacties kunnen worden opgeschoond door SQL Server omdat de afgebroken transactie nog steeds geopend is. Met de Transact-SQL verwijzing DBCC OPENTRAN kunt u controleren of er op een bepaald moment een actieve transactie aanwezig is in een database. Klik op de volgende artikelnummers in de Microsoft Knowledge Base voor meer informatie over dit specifieke scenario:
295108 Onvolledige transactie houdt groot aantal vergrendelingen vast en veroorzaakt blokkering
171224 Werking van de opdracht Transact-SQL KILL
U kunt ook het onderwerp 'DBCC OPENTRAN' in SQL Server Books Online lezen.

Scenario's die tot gevolg kunnen hebben dat transacties niet worden doorgevoerd:
  • Een toepassing waarvan de ontwerper er vanuit is gegaan dat alle fouten een rollback tot gevolg hebben.
  • Een toepassing waarvan de ontwerper niet goed rekening heeft gehouden met de manier waarop in SQL Server een rollback wordt uitgevoerd naar benoemde transacties of speciaal geneste benoemde transacties. Als u probeert een rollback uit te voeren voor een inner-named transactie, wordt het volgende foutbericht weergegeven:
    Server: Msg 6401, Level 16, State 1, Line 13 Cannot roll back InnerTran. No transaction or savepoint of that name was found.
    Na het genereren van het foutbericht gaat SQL Server verder met de volgende instructie. Dit is inherent aan het ontwerp van het product. Zie voor meer informatie het onderwerp 'Nested Transactions' of 'Inside SQL Server' in SQL Server Books Online.

    Microsoft adviseert de volgende richtlijnen te hanteren bij het ontwerpen van uw toepassing:
    • Open maar één transactie-eenheid (het is namelijk mogelijk dat uw proces wordt aangeroepen door een ander proces).
    • Controleer @@TRANCOUNT voordat u COMMIT, ROLLBACK, RETURN of een vergelijkbare opdracht of instructie uitvoert.
    • Houd bij het schrijven van de code rekening met de mogelijkheid dat een andere @@TRANCOUNT 'nesting' van uw @@TRANCOUNT tot gevolg heeft en zorg ervoor dat de andere @@TRANCOUNT ongedaan wordt gemaakt wanneer er een fout optreedt.
    • Controleer savepoint- en markeeropties voor transacties. (Hiermee worden vergrendelingen niet vrijgegeven!)
    • Voer uitvoerige tests uit.
  • Een toepassing die interactie van de gebruiker binnen transacties toestaat. Hierdoor blijft de transactie lang geopend, waardoor andere transacties worden geblokkeerd en het transactielogboek groeit omdat de geopende transactie niet kan worden verwijderd en nieuwe transacties aan het logboek worden toegevoegd na de geopende transactie.
  • Een toepassing waarin @@TRANCOUNT niet wordt gecontroleerd om er zeker van te zijn dat er geen geopende transacties zijn.
  • Netwerkfouten of andere fouten waardoor de verbinding van de clienttoepassing met SQL Server wordt verbroken zonder dat dit wordt doorgegeven aan SQL Server.
  • Groepsgewijze verbindingen. Nadat worker-threads zijn gemaakt, worden deze opnieuw gebruikt door SQL Server wanneer ze niet in gebruik zijn voor een verbinding. Als via een verbinding van een gebruiker een transactie wordt gestart en de verbinding wordt verbroken voordat de transactie is doorgevoerd of ongedaan gemaakt, blijft de voorgaande transactie geopend wanneer dezelfde thread opnieuw wordt gebruikt door een verbinding. Deze situatie veroorzaakt vergrendelingen die worden overgenomen van de vorige transactie en voorkomt dat de doorgevoerde transacties kunnen worden verwijderd uit het logboek. Het gevolg is dat het logboek bijzonder groot wordt.Als u meer informatie wilt over groepsgewijze verbindingen, klikt u op het volgende artikelnummer in de Microsoft Knowledge Base:
    164221 Groepsgewijze verbindingen inschakelen in een ODBC-toepassing
Terug naar begin

Uitzonderlijk grote transacties

Records in de transactielogboekbestanden worden verwijderd op transactiebasis. Ook als het transactiebereik erg groot is, wordt een transactie (en alle transacties die daarna zijn gestart) pas uit het logboek verwijderd wanneer de transactie is voltooid. Hierdoor kunnen grote logboekbestanden ontstaan. In het geval van een erg grote transactie kan het logboekbestand alle beschikbare schijfruimte in beslag nemen, waardoor een foutbericht wordt gegenereerd met de mededeling dat het transactielogboek vol is (bijvoorbeeld fout 9002). In de sectie 'Meer informatie' van dit artikel vindt u meer informatie over de actie die u moet uitvoeren wanneer u een dergelijk foutbericht ontvangt. Daarnaast neemt de rollback van grote transacties veel tijd in beslag en zijn er veel resources van SQL Server voor nodig.

Terug naar begin

Bewerkingen: DBCC DBREINDEX en CREATE INDEX

De aanpassingen in het herstelmodel van SQL Server 2000 hebben tot gevolg dat bij gebruik van de modus Full recovery en DBCC DBREINDEX het transactielogboek aanzienlijk sneller kan groeien dan bij een vergelijkbare herstelmodus van SQL Server 7.0 met gebruik van SELECT INTO of BULK COPY en met de optie 'Trunc. Log on chkpt.' uitgeschakeld.

Hoewel de omvang van het transactielogboek na de bewerking DBREINDEX een probleem kan zijn, kunnen transacties in het logboek op deze manier beter worden hersteld.

Terug naar begin

Tijdens het terugzetten van gegevens uit back-ups van transactielogboeken

Dit scenario wordt beschreven in het volgende Microsoft Knowledge Base-artikel:
232196 Gebruikte logboekruimte lijkt toe te nemen na herstel uit back-up

Als u SQL Server 2000 instelt voor gebruik van de modus Bulk-Log en u een instructie BULK COPY of SELECT INTO uitvoert, wordt elke gewijzigd gebied gemarkeerd en worden deze gebieden opgenomen in de back-up van het transactielogboek. Hoewel dit de mogelijkheid biedt om zelfs na het uitvoeren van bulkbewerkingen een back-up van transactielogboeken te maken en het systeem te herstellen, heeft deze benadering wel tot gevolg dat de transactielogboeken groter worden. Deze functionaliteit is niet beschikbaar in SQL Server 7.0. In SQL Server 7.0 wordt alleen vastgelegd welke gebieden zijn gewijzigd, maar de gebieden zelf worden niet opgenomen in het logboek. Logboekregistratie in de modus Bulk-Log vereist dus veel meer schijfruimte in SQL Server 2000 dan in SQL Server 7.0, maar nog niet zo veel als in de modus Full.

Terug naar begin

Clienttoepassingen verwerken niet alle resultaten

Als u een query verstuurt naar SQL Server en de resultaten niet direct afhandelt, blijven er misschien vergrendelingen actief en kunnen er tegelijkertijd minder aanvragen worden verwerkt door de server.

Stel dat u een query verstuurt waarvan de resultaatset bestaat uit rijen op basis van twee pagina's. De query wordt geparseerd, gecompileerd en uitgevoerd door SQL Server. Dit betekent dat gedeelde vergrendelingen worden geplaatst op de twee pagina's die de rijen bevatten die nodig zijn voor uw query. Stel nu ook dat niet alle rijen in één TDS-pakket van SQL Server passen (de server gebruikt dit type pakketten om te communiceren met de client). TDS-pakketten worden gevuld en naar de client verzonden. Als alle rijen van de eerste pagina in het TDS-pakket passen, wordt de gedeelde vergrendeling voor die pagina vrijgegeven door SQL Server. De vergrendeling voor de tweede pagina blijft echter gehandhaafd. SQL Server wacht tot de client meer gegevens opvraagt (bijvoorbeeld via DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults of FetchLast/FetchFirst).

Dit betekent dat de pagina vergrendeld blijft totdat de client de overige gegevens opvraagt. Dit kan tot gevolg hebben dat andere processen die gegevens van de tweede pagina opvragen, worden geblokkeerd.

Terug naar begin

Query's worden afgesloten met een time-out voordat een transactielogboek is gegroeid en het foutbericht 'Log Full' wordt onterecht weergegeven

In deze situatie wordt er, ondanks dat er voldoende schijfruimte is, een bericht weergegeven dat er geen ruimte meer is.

Deze situatie verschilt voor SQL Server 7.0 en SQL Server 2000.

Een query kan tot gevolg hebben dat het transactielogboek automatisch groeit als het logboek bijna vol is. Hierdoor kan de query langer duren en kan een query zelfs worden gestopt of worden afgesloten met een time-out. SQL Server 7.0 retourneert fout 9002 in deze situatie. Dit probleem geldt niet voor SQL Server 2000.

Als in SQL Server 2000 de optie auto-shrink is ingeschakeld voor een database, wordt slechts gedurende een zeer korte periode geprobeerd het transactielogboek automatisch uit te breiden. Dit lukt echter niet omdat de functie auto-shrink is ingeschakeld. Dit kan ook tot gevolg hebben dat fout 9002 onterecht wordt weergegeven.

De automatische uitbreiding van transactielogboekbestanden kost meestal weinig tijd. In de volgende situaties kan deze actie echter meer tijd in beslag nemen:
  • De groeitoenamen zijn te klein.
  • De server reageert om verschillende redenen langzaam.
  • De schijven zijn niet snel genoeg.
Terug naar begin

Niet-gerepliceerde transacties

De transactielogboekgrootte van de publicatieserverdatabase kan toenemen als u replicatie gebruikt. Transacties die van invloed zijn op de objecten die worden gerepliceerd, worden gemarkeerd als 'Voor replicatie'. Dergelijke transacties, zoals niet-doorgevoerde transacties, worden niet verwijderd na het bereiken van een herstelpunt of na het maken van een back-up van het transactielogboek, maar pas nadat de transacties met de taak voor het lezen van het logboek naar de distributiedatabase zijn gekopieerd en de markering is verwijderd. Als deze transacties door een bepaald probleem niet kunnen worden opgehaald uit de publicatieserverdatabase, kan het transactielogboek blijven groeien naarmate het aantal niet-gerepliceerde transacties toeneemt. Met de Transact-SQL verwijzing DBCC OPENTRAN kunt u vaststellen wat de oudste, niet-gerepliceerde transactie is.

Lees voor meer informatie over het oplossen van problemen met niet-gerepliceerde transacties de onderwerpen 'sp_replcounters' en 'sp_repldone' in SQL Server Books Online.

Klik voor meer informatie op de volgende artikelnummers in de Microsoft Knowledge Base:
306769 FIX: Transactielogboek van momentopname gepubliceerde database kan niet worden afgekapt
240039 FIX: DBCC OPENTRAN rapporteert geen replicatiegegevens
198514 FIX: Herstel naar nieuwe server heeft tot gevolg dat transacties in logboek blijven
Terug naar begin
Meer informatie
Het transactielogboek voor een database wordt beheerd als een set virtuele logboekbestanden (VLF's) waarvan de grootte intern wordt bepaald door SQL Server op basis van de totale grootte van het logboekbestand en de groeitoename die is ingesteld voor het logboek. Een logboek groeit altijd in stappen van hele VLF's en kan niet verder groeien dan de grens van een VLF. Een VLF kan de volgende statuswaarden hebben: ACTIVE, RECOVERABLE en REUSABLE.
  • ACTIVE: het actieve gedeelte van het logboek begint bij het laagste logboekvolgnummer (LSN) dat een actieve (niet-doorgevoerde) transactie aangeeft. Het actieve gedeelte van het logboek eindigt bij het laatst toegevoegde LSN. VLF's die een deel van het actieve logboek bevatten, worden beschouwd als actieve VLF's. (Niet-gebruikte ruimte in het fysieke logboek maakt geen deel uit van een VLF.)
  • RECOVERABLE: het gedeelte van het logboek dat voorafgaat aan de oudste actieve transactie is alleen nodig om voor hersteldoeleinden een reeks back-ups van logboeken te onderhouden.
  • REUSABLE: als u niet werkt met back-ups van transactielogboeken, of als u al een back-up van het logboek hebt gemaakt, worden VLF's vóór de oudste actieve transactie hergebruikt door SQL Server.
Wanneer het einde van het fysieke logboekbestand wordt bereikt door SQL Server, wordt die ruimte in het fysieke bestand opnieuw gebruikt door een CIRCLING BACK-bewerking uit te voeren naar het begin van de bestanden. In feite wordt de ruimte in het logboekbestand die niet meer nodig is voor herstel- of back-updoeleinden gerecycled door SQL Server. Als een reeks back-ups van een logboek wordt onderhouden, kan het gedeelte van het logboek vóór het laagste LSN pas worden overschreven wanneer u een back-up maakt van die records of de records verwijdert. Na het maken van de back-up kan SQL Server met CIRCLING BACK teruggaan naar het begin van het bestand. Op het moment dat SQL Server records weer aan het begin van het logboekbestand toevoegt, is het gedeelte tussen het einde van het logische logboek en het actieve gedeelte van het logboek het deel dat opnieuw kan worden gebruikt.

Lees voor meer informatie het onderwerp 'Transaction Log Physical Architecture' in SQL Server Books Online. Op pagina 190 van 'Inside SQL Server 7.0' (Soukup, Ron. Inside Microsoft SQL Server 7.0, Microsoft Press, 1999), evenals op pagina's 182-186 van 'Inside SQL Server 2000' (Delaney, Kalen. Inside Microsoft SQL Server 2000, Microsoft Press, 2000) vindt u een overzichtelijk schema en een heldere bespreking van deze materie. U kunt opties instellen waarmee databases van SQL Server 7.0 en SQL Server 2000 automatisch groter (autogrow) en kleiner (autoshrink) kunnen worden. Deze opties kunt u gebruiken om een transactielogboek te comprimeren of juist groter te maken.

Klik op het volgende artikelnummer in de Microsoft Knowledge Base voor meer informatie over hoe deze opties uw server kunnen beïnvloeden:
315512 Overwegingen bij de autogrow- en autoshrink-configuratie in SQL Server
Er is een verschil tussen opschoning en compressie van het transactielogboekbestand. Wanneer een transactielogboekbestand wordt opgeschoond door SQL Server, betekent dit dat de inhoud van dat bestand (bijvoorbeeld de doorgevoerde transacties) wordt verwijderd. Wanneer u echter kijkt naar de invloed van de bestandsgrootte op de schijfruimte (bijvoorbeeld in Windows Verkenner of met de opdracht dir), is de grootte ongewijzigd. De ruimte binnen het LDF-bestand is nu echter beschikbaar voor nieuwe transacties. Alleen wanneer het transactielogboekbestand wordt verkleind door SQL Server, kunt u een wijziging zien in de fysieke grootte van het logboekbestand.

Als u meer informatie wilt over het verkleinen van transactielogboeken, klikt u op de volgende artikelnummers in de Microsoft Knowledge Base:
256650 Het transactielogboek van SQL Server 7.0 verkleinen
272318 Het transactielogboek in SQL Server 2000 verkleinen met DBCC SHRINKFILE
Als u meer informatie wilt over het gebruik van transactielogboeken in SQL Server 6.5, klikt u op het volgende artikelnummer in de Microsoft Knowledge Base:
110139 Redenen waarom SQL-transactielogboek volraakt
Eigenschappen

Artikel-id: 317375 - Laatst bijgewerkt: 07/16/2013 03:59:00 - Revisie: 6.4

  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Workgroup Edition
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • kbsqlmanagementtools kbinfo KB317375
Feedback