INF: Redenen waarom SQL-transactielogboek volraakt

BELANGRIJK: Dit artikel is vertaald door middel van automatische vertalingssoftware van Microsoft en is mogelijk nabewerkt door de Microsoft Community via CTF-technologie (Community Translation Framework) of door een menselijke vertaler. Microsoft biedt zowel automatisch vertaalde, door mensen vertaalde en door de community nabewerkte artikelen aan, zodat er in meerdere talen toegang is tot alle artikelen in onze Knowledge Base. Een vertaald of bewerkt artikel kan fouten bevatten in vocabulaire, syntaxis of grammatica.. Microsoft is niet verantwoordelijk voor eventuele onjuistheden, fouten of schade ten gevolge van een foute vertaling van de inhoud van een bericht of het gebruik van deze vertaalde berichten door onze klanten.

De Engelstalige versie van dit artikel is de volgende: 110139
Vrijwaring inhoud KB-artikelen over niet langer ondersteunde producten
Dit artikel heeft betrekking op producten waarvoor Microsoft geen ondersteuning meer biedt. Daarom wordt dit artikel alleen in de huidige vorm aangeboden en wordt het niet meer bijgewerkt.
Samenvatting
Het transactielogboek van SQL Server kan vol geraken, waarmee verdere activiteiten met bijwerken, verwijderenof Invoegen in de database, inclusief CONTROLEPUNT wordt voorkomen. Dit wordt meestal gezien als fout 1105:
Kan geen ruimte voor object syslogs in database dbname toewijzen omdat de logsegment vol is. Als er onvoldoende ruimte in syslogs, dump van het transactielogboek. Anders ALTER DATABASE- of sp_extendsegment gebruiken om de grootte van het segment.
Dit kan gebeuren op een database, met inbegrip van master of tempdb. Dit artikel worden mogelijke oorzaken en oplossingen voor de problemen die hebben geleid tot de fout 1105. Als het transactielogboek vol is en u momenteel 1105 fout ontvangt, moet u het logboek leegmaken met behulp van de DUMP transactie -instructie. Zie de documentatie bij SQL Server voor meer informatie over het gebruik van DUMP transactie.
Meer informatie
Een fundamenteel kenmerk van true relationele databases, zoals Microsoft SQL Server, is die van transactionele integriteit. Elke transactie moet volledig atomaire (dat wil zeggen, functioneel ondeelbare) in dat alle wijzigingen moeten worden toegepast of niet, zelfs bij een systeemstoring toegepast. In een transactie door de gebruiker gedefinieerde worden alle instructies tussen haakjes de transactie BEGINT en doorvoeren transactie-instructie toegepast of niet toegepast. Elke één SQL-instructie wordt beschouwd als een atomaire eenheid in een impliciete transacties.

Deze mogelijkheid biedt SQL Server zich een stroomstoring, besturingssysteem vastloopt, enzovoort in de productie en na het opnieuw opstarten, dus automatisch herstellen de database naar een consistente status, zonder menselijke interactie vereist is. Dit contrasteert met de niet-relationele systemen waarvoor vaak lange handmatige procedures voor het controleren van de database op consistentieproblemen na een systeemfout.

Het transactie-log mechanisme is wat voorziet in deze mogelijkheid. Logboekregistratie kan niet worden uitgeschakeld omdat transactionele integriteit wordt beschouwd als een fundamentele, intrinsieke eigenschap van SQL Server. Bepaalde hulpprogramma of onderhoudsbewerkingen, zoals het snelle BCP en een SELECT INTO doen minimale logboekregistratie, maar zelfs deze toewijzingen logboek mate zodat terugdraaien mogelijk is.

De benodigde schijfruimte voor logboekregistratie kunnen zeer aanzienlijk zijn. Bijvoorbeeld, in de meeste gevallen de voor en na de afbeelding van elk bijgewerkt gegevensrij moet worden vastgelegd, plus die van een index rijen beïnvloed. Aangezien een bepaalde transactie record overhead vast bedrag moet worden opgenomen voor elke geregistreerde rij, zijn de verhouding van de bijgewerkte gegevens te melden ruimte verbruik afhankelijk van de breedte van de rij. Voor een smalle rij kan logboek ruimte verbruikt voor een bepaalde UPDATE, verwijderen of Invoegen worden tien keer de ruimte verbruikt. Voor bredere rijen, de hoeveelheid ruimte verbruikt worden verhoudingsgewijs minder. Logboek ruimte verbruik is een onvermijdelijk resultaat is van de transactionele integriteit. De beheerder van de Database moet voldoende ruimte bieden voor zijn of haar specifieke installatie.

Het bedrag van de vereiste ruimte kan variëren afhankelijk van vele factoren en is zeer moeilijk te voorspellen nauwkeurig vooraf. Als algemene regel van de duim cijfers, bijvoorbeeld 15 tot 30 procent van de grootte van de database worden soms vermeld als een beginpunt voor het aanpassen van het logboek, in werkelijkheid varieert dit. Geslaagde installaties van SQL Server vaak doen sommige eenvoudige empirische tests voor de beoordeling van min of meer vereisten voor de logboekbestanden voor hun gegevens en toepassingen en vervolgens hun logboek op basis van deze grootte. U probeert de grootte van het logboek op basis van louter op grond van berekeningen en zonder tests is moeilijk en vaak onnauwkeurig.

Variatie in het logboek ruimte verbruik kunnen rekening met verschillende factoren die moeilijk te voorspellen. Een van de factoren is de queryoptimalisatie. Het plan toegang kan voor een bepaalde SQL gegevens wijziging instructie, na verloop van tijd, afhankelijk van de statistische verdeling van de gegevens variëren. Plannen voor verschillende toegang kunnen verschillende bedragen logboekruimte verbruiken. Een andere factor is de interne database van onvermijdelijke fragmentatie waardoor het aantal pagina-splitsingen uitgevoerd. Er is niets dat kan worden uitgevoerd of moet worden uitgevoerd om te controleren of de invloed op dit proces, zoals SQL Server automatisch gegevens van de gebruiker wordt beheerd.

Een voorbeeld van een eenvoudige test is DBCC CHECKTABLE(syslogs), die resulteert in het aantal pagina's van 2048 bytes gegevens in het logboek, zowel vóór als na het uitvoeren van een representatieve steekproef van de wijziging gegevensquery uitvoeren. Dit kan een idee bij benadering van het logboek schijfruimte vrij te maken voor dit soort query's geven. Het is doorgaans het beste aan de zijkant van de overmaat err bij het logboek of gegevens schijfruimte voor relationele databases zoals SQL Server opgeven.

Voor SQL Server 7.0 en 2000 klasse-servers is het transactie-log de mogelijkheid om uit te breiden indien nodig. Het bedrag van de groei kan worden beheerst door de gebruiker of gebruikmaken van de capaciteit van alle beschikbare schijfruimte is toegestaan. Een logboekbestand bestaat uit een aantal virtuele logboekbestanden. Het aantal en de grootte van deze virtuele logboekbestanden worden bepaald door SQL Server en kunnen niet worden geconfigureerd. Wanneer een database wordt gemaakt, heeft elke fysieke logboekbestand een minimum van 2 virtuele logboekbestanden. De beheerder kan soms de optie 'afbreken log on checkpoint' van een database in een poging om te voorkomen dat logboek vollopen. De bedoeling van deze optie is bedoeld als een automatische methode voornamelijk voor ontwikkeling of test databases die niet zijn gebaseerd op logboek dumpen voor back-up van het logboek worden afgekapt. Deze optie wordt niet registreren of transactionele integriteit uitgeschakeld. Slechts worden de checkpoint-handler probeert een logboek afkapping ongeveer elke 60 seconden. Houd er rekening mee dat het logboek niet worden afgekapt bij het verlenen van een opdracht handmatige checkpoint in een database met 'afbreken log on checkpoint' op. Deze optie is altijd ingeschakeld voor de database tempdb, hoewel dit niet wordt vermeld in de statuskolom van de uitvoer van de sp_help opgeslagen procedure.

Zelfs met de optie 'afbreken log on checkpoint' is ingeschakeld, kan een aantal factoren log vollopen veroorzaken. Deze worden hieronder weergegeven:
  1. Een grote atomische transacties met name een bulk UPDATE, INSERT of DELETE: elke één SQL-instructie wordt beschouwd als een atomaire eenheid thatmust worden toegepast of niet volledig zijn toegepast. Alle rowalterations moet zijn aangemeld om deze reden, en de transactie kan niet worden afgekapt op itsduration. Bijvoorbeeld, als een grote bulk INSERT is afgegeven en die had een uitvoertijd van vijf minuten, het logboek worden gebruikt door deze transactie kan niet worden truncatedfor deze periode. De beheerder van de database moet bieden voldoende logboek spacefor de grootste bulkbewerking verwacht of de groepen bulk bewerking insmaller moet uitvoeren.
  2. Een niet-vastgelegde transactie: het logboek kan alleen worden truncatedprior aan de oudste niet-vastgelegde transactie. Er zijn verschillende mogelijke causesof van een niet-doorgevoerde transacties, waarvan de meeste fouten zijn. Theseinclude:
    1. Een transactie bulk: geacht boven, voor de duur van een transactie met grote bulk het logboek gegenereerd door deze records kunnen niet worden afgekapt. Echter, een dergelijke transactie is derhalve ook onmogelijk logboek PST-bestanden van andere kortere transacties die over dezelfde periode Commit.

      Stel dat de beheerder van de database heeft het logboek formaat, dat voldoende voor de grootste ontwikkelaars van bulk-transactie is. Nog tijdens deze transactie wordt uitgevoerd, kunnen andere instructies kortere data wijziging ook worden verbruikt logboekruimte. Deze ruimte kan niet worden afgekapt, omdat de transactie van grote bulkimportbewerkingen eerst gestart en daarom het oudste niet-doorgevoerde transacties wordt. De beheerder moet zich bewust zijn van de gelijktijdigheid en de gevolgen van een grote bulk transactie log en het formaat van het logboek aan.
    2. Een slecht ontworpen toepassing waarmee gebruikersinvoer of andere langdurige activiteit binnen een door de gebruiker gedefinieerde transactie. Bijvoorbeeld na het verzenden van een transactie beginnen door een toepassing gevraagd de gebruiker om invoer die lang, afhankelijk van het gebruikersgedrag duren kan. Totdat de gebruiker reageert en de toepassing een COMMIT geeft, is logboek PST-bestanden niet mogelijk.
    3. Een fout waarbij een transactie niet doorgevoerd wordt: een veelvoorkomende oorzaak van deze onjuiste afhandeling van de DB-Library-aanroep dbcancel() binnen een door de gebruiker gedefinieerde transactie is. Wanneer een query wordt geannuleerd met dbcancel(), de momenteel uitgevoerde SQL-instructie is afgebroken en teruggedraaid, maar de buitenste transactie is niet. De toepassing moet worden op de hoogte en de nodige ROLLBACK TRANSACTION of doorvoeren transactie-instructie om te sluiten van de transactie. Niet doet kan vaak leiden tot fout 3902:
      De commit-transactie heeft geen corresponderende BEGIN TRANSACTION.
      Kan het nuttig zijn voor de toepassing voor het verzenden van een @@TRANCOUNT selecteren om te bepalen welk niveau van nesten transactie bestaat. Echter de toepassing niet in de meeste moet dit doen en verlenen COMMIT/ROLLBACK te bereiken @@TRANCOUNT = 0. Dit komt omdat als @@TRANCOUNT ooit verschillend is van wat de verwachte, betekent dit dat de toepassing heeft verloren spoor van het geneste niveau van transactie, wordt een fout in de ontwerpweergave. Op dit moment COMMIT/ROLLBACK afgifte kan leiden tot toepassen of onbedoelde transacties, wordt afgebroken omdat de toepassing niet weet welke transacties heeft geresulteerd in de onbedoelde transactieniveau. In plaats daarvan moet de programmeur fouten in de toepassing en opgeslagen procedures om de oorzaak van het transactieniveau van de onbedoelde betrokken.
    4. Een fout die niet in kennis is met SQL Server van een verbroken netwerkverbinding: als het clientwerkstation vastloopt, opnieuw wordt opgestart of binnen een transactie door de gebruiker gedefinieerde afgesloten, de netwerklaag kennis dient te stellen van de SQL-Server. Als het netwerk niet goed doet is, vanuit het perspectief van SQL Server weergegeven voor de client aanwezig is en de geopende transactie die zal client worden gehandhaafd. Dit is een probleem met het netwerk en als zodanig moet worden nagestreefd. Als tijdelijke oplossing de beheerder mogelijk bepalen echter met sp_who, sp_lock of een netwerkhulpprogramma welke clientsessie nog steeds bestaat en handmatig doden.
    5. Transactie niet doorgevoerd door het blokkeren van: In een omgeving met meerdere gebruikers is het mogelijk een open transactie op vergrendelingen door een ander proces wordt geblokkeerd. In dit geval wordt blijven de transactie niettemin geopende logboek PST-bestanden te blokkeren. Dit detecteren, moet de programmeur of databasebeheerder sp_who, sp_lock of andere hulpprogramma's gebruiken voor het analyseren van de omgeving van gelijktijdigheid. In de meeste gevallen kunnen problemen met blokkering worden verminderd of opgeheven door goede query, index en ontwerpen van databases.
    6. Mislukte poging om een query op een wijziging te annuleren: als de toepassing een dbcancel() geeft de query niet wordt geannuleerd als gevolg van een netwerk of een SQL-probleem, de query worden uitgevoerd en de transactie geopend blijven. Als u vermoedt dat een probleem hier, gebruik sp_who te zien als de query wordt geannuleerd. Als u probeert te annuleren van een client TCP/IP-sockets, voer de test van een named pipe-client of de clienttoepassing uitvoert op de server met behulp van lokale pijpen. Hierdoor onderscheiden of een netwerk of een SQL-probleem verhindert de annuleren dat.
  3. CheckPoint-handler afkapping bandbreedte overschreden: Althoughthe logboek elke 60 seconden, de snelheid waarmee de takesplace van deze PST-bestanden is eindig is afgebroken. In dit scenario gebeurt en de mogelijke oorzaken van de logoverflow moeten worden gezien en eerste uitgesloten voordat de inspectie van thispossibility. Het is echter mogelijk groter zijn dan de maximale afkapping tarief ifmany clients tegelijkertijd grote updates uitvoert. Dit is vergelijkbaar met afunnel die alleen vloeistof met een bepaalde snelheid laten en kan worden overvolle evenwhile weglopen. In dit scenario die kan de toepassing worden geherstructureerd met het aantal rijen wordt bijgewerkt, en dit moet altijd een primaire reducethe ontwerp goalfor een relationele database toch.

    Als dit niet haalbaar is, kunnen thesystem worden geconfigureerd voor grotere schijf i/o-bandbreedte echter striping en extra domeincontrollers. Is het gebruikelijk om te zien thecheckpoint handler proces in dit geval besteden steeds grotere hoeveelheden in de staat DUMPTRANSACTION tijd als u probeert deze log afkapping houden. Als thetruncation drempel is overschreden (Zie hieronder) ziet u niet de checkpointhandler ooit geprobeerd PST-bestanden in de database totdat het logboekbestand iscleared.
  4. Afkapping drempel overschreden: de handleressentially van het controlepunt wordt een DUMP transactie met TRUNCATE_ONLY. Net als dit wasissued handmatig, het zal niet altijd mogelijk als het logboek al volledig aan punt acertain. Een package-burst update activiteit kan bijvoorbeeld het logboek to95% tussen bezoeken door de handler checkpoint vullen. Wanneer het controlepunt handlerattempts PST-bestanden, terwijl het logboek niet helemaal vol is, is het mogelijk te fullto PST-bestanden toestaan. Dit komt doordat het afkappen van het logboek zichzelf belogged moet. In dit geval is de enige oplossing DUMP transactie met NO_LOGto handmatig afbreken dit logboek gebruiken. Met de optie NO_LOG wordt niet aanbevolen exceptwhen absoluut noodzakelijk, omdat het een niet-geregistreerde bewerking tijdens welke systemfailure kan fouten in de database invoeren.
  5. Interacties tussen een van de bovenstaande: bijvoorbeeld undernormal voorwaarden in een omgeving met veel update het controlepunt handlertruncation tarief kan het logboek wordt bijgehouden in terechtkomen. Als er een tijdelijk opentransaction veroorzaakt door een van de bovenstaande voorwaarden (zoals een vergrendelingsconflict), wordt het logboek in te vullen om te zeggen, 50%, zal er veel minder ruimte forhandling andere situaties bijwerken, zodat u waarschijnlijk veel meer bereiken drempel voor thetruncation, waardoor automatische afbreking is niet mogelijk. Transacties in tempdb worden net als elke andere database geregistreerd. Aangezien Op het CONTROLEPUNT AFGEKAPT op in tempdb, in de meeste gevallen die het logboek wordt afgebroken en notoverflow. Een van de bovenstaande omstandigheden veroorzaakt echter het logboek tempdb tofill up. Tempdb is meestal geconfigureerd voor gemengde logboek- en data(sysusages.segmap=7) zodat de gegevens- en logboekbestanden bewerkingen wordt standaardtoepassing voor de ruimte sameavailable. Sommige Transact-SQL wordt, zoals GROUP BY, ORDER door DESC, enzovoort, automatisch moet tempdb voor de werkruimte. Ook Hierdoor wordt een impliciete BEGIN TRANSACTION record in tempdb voor de werkomgeving. Deze tempdb transactie willcontinue voor de duur van de transactie in de db gebruiker kunt defertempdb log PST-bestanden voor deze periode. Als de transactie in de ishalted van de db gebruiker om welke reden, met inbegrip van een blokkerende vergrendeling of de toepassing notprocessing dbnextrow() aan de voltooiing van de transactie in tempdb likewisebe links zal melden open, voorkomen tempdb PST-bestanden. De programmeur moet theapplication voor foutopsporing en/of de gelijktijdigheid van problemen die ertoe leiden dit dat oplossen.
  6. PST-bestanden van het transactielogboek in SQL Server 7.0 and2000 klasseservers wordt gedaan door virtuele logboekbestanden worden afgekapt. Als anyportion van het actieve logboek op een bepaalde VLF, virtuele logboek Filecannot afgekapt. Als het actieve logboek op alle virtuele logboekbestanden aanwezig is, kan het logboek kan niet worden afgekapt. Als toename is ingeschakeld en er is ruimte op thevolume als het transactielogboek als de maximale bestandsgrootte is niet beenreached, wordt het transactielogboek door het bedrag in het logboek fileproperties vergroot.
Het volgende wordt beschreven logboek afkapping gedrag bij het opstarten van SQL op basis van of Op het CONTROLEPUNT AFGEKAPT is ingesteld.
  • Als u Op het CONTROLEPUNT AFGEKAPT is ingesteld en het logboek moet volledig worden tijdens het opstarten wordt gevonden, wordt het automatisch met no_log gedumpt.
  • Op het CONTROLEPUNT AFGEKAPT is standaard in model omdat het logboek kan niet worden geplaatst op aseparate apparaat, zodat deze niet meer kan worden geladen. De enige realistische optie is todiscard het logboek wanneer deze vol raakt.
  • Als Op het CONTROLEPUNT AFGEKAPT is niet ingesteld, en het logboek wordt geconstateerd tijdens het opstarten volledig, herstel is voltooid, maar het laatste controlepunt is niet geschreven. Een administratorcan krijgen in de database en het logboek met no_truncate gegevens opslaan en vervolgens met no_log het verwijderen (of het gewoon verwijderen) dump dump.

VERWIJZINGEN


Raadpleeg de volgende Microsoft Training & Certification cursus voor meer informatie: Voor problemen die specifiek zijn voor SQL Server 7l 0 en hoger, raadpleegt u het volgende artikel in de Microsoft Knowledge Base:
317375 INF: Transactielogboek wordt erg groot of raakt vol op SQL Server
4.20 sql6 transactielogboek 1105 Windows NT sqlfaqtop

Waarschuwing: dit artikel is automatisch vertaald

Eigenschappen

Artikel-id: 110139 - Laatst bijgewerkt: 09/27/2015 12:54:00 - Revisie: 5.0

Microsoft SQL Server 6.5 Standard Edition, Microsoft SQL Server 6.0 Standard Edition, Microsoft SQL Server 4.21a Standard Edition

  • kbsqlsetup kbinfo kbother kbmt KB110139 KbMtnl
Feedback