Gedurende mijn hele carrière als dataprofessional, zowel binnen Microsoft als als consultant, heb ik ontdekt dat een van de meest onbegrepen onderdelen van een SQL Server-database het transactielogboek is. Gebrek aan kennis over hoe het transactielogboek werkt en moet worden beheerd, of eenvoudige misvattingen, kan leiden tot allerlei productieproblemen, waaronder:
- Het transactielogboek loopt uit de hand en heeft mogelijk onvoldoende ruimte
- Prestatieproblemen door herhaaldelijk verkleinen van het transactielogboek
- Prestatieproblemen door een probleem dat bekend staat als VLF-fragmentatie , die ik in dit bericht heb besproken
- Het onvermogen om te herstellen naar een gewenst tijdstip met behulp van back-ups van transactielogboeken
- Het onvermogen om een tail-log-back-up uit te voeren tijdens noodherstel (zie hier voor een uitleg van tail-log-back-ups)
- Verschillende problemen rond failovers en herstelprestaties
Met dit bericht begin ik af en toe een serie over het transactielogboek en hoe het werkt en moet worden beheerd, en ik zal in de loop van de tijd alle bovenstaande problemen bespreken. In dit bericht leg ik uit wat logboekregistratie is en waarom het nodig is.
Basisterminologie rond loggen
Als ik het heb over een mechanisme in SQL Server, merk ik dat er een kip-en-ei-probleem is waarbij ik een woord of zin moet gebruiken voordat ik het heb uitgelegd. Om dat probleem in deze serie te vermijden, zal ik beginnen met het uitleggen van enkele terminologie die moet worden gebruikt bij het bespreken van logboekregistratie, en ik zal veel van deze termen uitbreiden naarmate de serie vordert.
Transactie, toezegging en terugdraaiing
Een transactie omvat een wijziging of een reeks wijzigingen in een database. Het heeft een gedefinieerd begin en een gedefinieerd einde. Het begin is wanneer een BEGIN TRANSACTION-instructie wordt gebruikt, of wanneer SQL Server automatisch een transactie voor u begint. Het einde kan een van de volgende vier dingen zijn:
- De transactie wordt vastgelegd wanneer een COMMIT TRANSACTION-instructie wordt uitgevoerd
- De transactie wordt vastgelegd wanneer SQL Server de transactie automatisch vastlegt in het geval van een automatische transactie
- De transactie wordt teruggedraaid nadat een ROLLBACK TRANSACTION-instructie is uitgevoerd
- De transactie wordt teruggedraaid nadat er een probleem is opgetreden, en SQL Server heeft de transactie automatisch teruggedraaid
Wanneer een transactie wordt doorgevoerd, worden de wijzigingen die de transactie heeft aangebracht definitief gemaakt in de database en zijn ze duurzaam in het SQL Server-transactielogboek op schijf. Merk op dat ik zei:"in het transactielogboek." De daadwerkelijke wijzigingen aan de gegevensbestandpagina's in het geheugen worden *niet* naar de schijf geschreven wanneer de transactie wordt vastgelegd. Ze hoeven niet duurzaam te worden gemaakt in de gegevensbestanden omdat de wijzigingen al duurzaam zijn in het transactielogboek. Uiteindelijk zullen de pagina's van het gegevensbestand naar de schijf worden geschreven door een controlepuntbewerking.
Omgekeerd, wanneer een transactie terugdraait, zijn de gegevenswijzigingen van de gemaakte transactie niet langer aanwezig in de database. Er zullen nog steeds enkele fysieke wijzigingen in de database plaatsvinden, aangezien het terugdraaien van een transactie betekent dat er meer wijzigingen moeten worden aangebracht, maar u kunt een teruggedraaide transactie beschouwen als een niet-invloed op de gegevens in de database.
Controlepunten en terugdraaioperaties zijn onderwerpen die hun eigen berichten waard zijn, dus ik zal ze later in de serie uitleggen.
Ik bespreek deze drie termen veel dieper in de tutorial Inleiding tot SQL Server-transacties op de SentryOne-blog.
Logboekregistratie, logboekrecords en het SQL Server-transactielogboek
Loggen betekent simpelweg het creëren van een duurzame beschrijving van een wijziging in een database, bijna altijd in de context van een transactie. Wanneer er een wijziging wordt aangebracht, wordt de wijziging beschreven in een logboekrecord. Een logboekrecord bevat meestal voldoende informatie om de wijziging in de database opnieuw af te spelen of indien nodig terug te draaien in de database.
Dit logrecord bevindt zich aanvankelijk in het geheugen en kan naar schijf worden geschreven voordat de transactie wordt vastgelegd, maar moet zeker voor naar schijf worden geschreven de transactie kan worden voltooid, anders zou de transactie niet duurzaam zijn. Een uitzondering op deze regel is wanneer de vertraagde houdbaarheid functie is ingeschakeld, die Aaron Bertrand in dit bericht bespreekt.
Logboekrecords worden opgeslagen in het transactielogboek (een of meer logbestanden op schijf), dat een ietwat complexe interne architectuur heeft, en ik zal dat en nog veel meer over logrecords bespreken in de volgende post in de serie.
Crashherstel
Bij een crash werd SQL Server onverwacht afgesloten en konden de verschillende gewijzigde databases niet correct worden afgesloten (ervoor zorgen dat alle pagina's met gewijzigde gegevensbestanden naar schijf worden geschreven en dat de database wordt gemarkeerd als netjes afgesloten).
Wanneer SQL Server opstart, controleert het alle databases om te zien of er geen zijn gemarkeerd als netjes afgesloten. Als het er een vindt, moet die database crashherstel ondergaan. Dit zorgt voor het volgende:
- Voor elke transactie die vóór de crash is uitgevoerd, moet u ervoor zorgen dat alle wijzigingen in de transactie worden weergegeven in de database (d.w.z. de transactie opnieuw afspelen)
- Zorg ervoor dat voor elke transactie die niet is uitgevoerd vóór de crash geen van de wijzigingen in de transactie worden weerspiegeld in de database (d.w.z. de transactie terugdraaien)
Met andere woorden, crashherstel maakt een database transactioneel consistent vanaf het moment dat de crash plaatsvond. Crashherstel wordt gebruikt:
- Als SQL Server start en een database vindt die hersteld moet worden
- Tijdens een failover naar een secundaire kopie van een database
- Aan het einde van een herstelprocedure met back-ups (zie hier)
Crashherstel is een complex proces en er zijn nog een paar berichten in de serie nodig voordat ik het diepgaand kan uitleggen.
Waarom is loggen vereist?
De meest elementaire reden voor logboekregistratie is om de SQL Server-database in staat te stellen transacties duurzaam te maken, zodat ze kunnen worden hersteld tijdens crashherstel of indien nodig kunnen worden teruggedraaid tijdens normale databasebewerkingen. Als er geen logboekregistratie was, zou een database na een crash niet transactie-inconsequent zijn en mogelijk structureel beschadigd.
Zonder logboekregistratie zouden een groot aantal andere functies in SQL Server niet mogelijk zijn, waaronder:
- Gegevensback-ups die consistent kunnen worden hersteld
- Back-ups van SQL Server-transactielogboeken die kunnen worden gebruikt tijdens een herstelbewerking en om verzending van logbestanden te implementeren
- Replicatie, die afhankelijk is van het kunnen oogsten van transacties uit het transactielogboek
- Change Data Capture, die de transactie-replicatie Log Reader Agent gebruikt om wijzigingen uit het transactielogboek te halen
- Databasespiegeling en beschikbaarheidsgroepen, die afhankelijk zijn van het verzenden van logrecords naar secundaire kopieën van de database om ze opnieuw af te spelen
SQL Server (en alle vergelijkbare databaseservers) maakt gebruik van wat write-ahead logging wordt genoemd . Dit betekent dat de beschrijvingen van wijzigingen naar de schijf moeten worden geschreven voordat de wijzigingen zelf worden aangebracht om de mogelijkheid te garanderen dat een database op de juiste manier crasht. Als een wijziging naar een gegevensbestand is geschreven voordat de logboekrecords deze beschrijven, en SQL Server crasht, zou er geen manier zijn om te weten wat er teruggedraaid moet worden en zou de database inconsistent zijn. Deze volgorde is een invariant, ongeacht het isolatieniveau, het type transactie of het gebruik van de vertraagde houdbaarheidsfunctie. Log eerst records, later gegevenspagina's.
Slechts het topje van de ijsberg
Zoals je in deze inleidende post kunt zien, gaat er een enorm bedrag naar het transactielogboek en het inloggen in een SQL Server-database, en het enige dat ik tot nu toe heb gedaan, is wat terminologie op hoog niveau definiëren en uitleggen waarom logboekregistratie vereist is. Ik hoop dat je met me meedoet terwijl ik me vertak en dieper ga naarmate de serie vordert!