In de laatste twee berichten heb ik manieren besproken om het aantal gegenereerde transactielogboeken te verminderen en hoe ervoor te zorgen dat het transactielogboek altijd correct kan worden gewist. In dit bericht wil ik doorgaan met het prestatiethema van transactielogboeken en enkele problemen met de configuratie van transactielogboeken bespreken die problemen kunnen veroorzaken.
Te veel VLF's
Het transactielogboek is opgesplitst in stukken die virtuele logbestanden (VLF's) worden genoemd, zodat het logbeheersysteem gemakkelijk kan bijhouden welke delen van het transactielogboek beschikbaar zijn voor hergebruik. Er is een formule voor het aantal VLF's dat u krijgt wanneer u uw transactielogboek maakt, het handmatig laat groeien of het automatisch groeit:
| Tot 1 MB | 2 VLF's, elk ongeveer de helft van de totale grootte |
|---|---|
| 1 MB tot 64 MB | 4 VLF's, elk ongeveer 1/4 van de totale grootte |
| 64 MB tot 1 GB | 8 VLF's, elk ongeveer 1/8 van de totale grootte |
| Meer dan 1 GB | 16 VLF's, elk ongeveer 1/16 van de totale grootte |
Als u bijvoorbeeld een transactielogboek van 8 GB maakt, krijgt u 16 VLF's waarvan elk ongeveer 512 MB is. Als je het logboek vervolgens met nog eens 4 GB vergroot, krijg je nog eens 16 VLF's met elk ongeveer 256 MB, voor een totaal van 32 VLF's.
Opmerking:dit algoritme is enigszins gewijzigd voor SQL Server 2014 om de VLF-fragmentatieproblemen te verminderen - zie deze blogpost voor details
Een algemene best practice is om de automatische groei van het logboek in te stellen op iets anders dan de standaard 10%, zodat u de pauze kunt regelen die nodig is wanneer u nieuwe transactielogboekruimte op nul initialiseert. Stel dat u een transactielogboek van 256 MB maakt en de automatische groei instelt op 32 MB, en dan groeit het logboek tot een stabiele grootte van 16 GB. Gezien de bovenstaande formule, zal dit ertoe leiden dat uw transactielogboek meer dan 2.000 VLF's heeft.
Dit aantal VLF's zal waarschijnlijk leiden tot prestatieproblemen voor bewerkingen die het transactielogboek verwerken (bijv. crashherstel, logboek wissen, logboekback-ups, transactiereplicatie, databaseherstel). Deze situatie wordt het hebben van VLF-fragmentatie genoemd. Over het algemeen zal een willekeurig aantal VLF's van meer dan duizend problematisch zijn en moet worden aangepakt (het meeste waar ik ooit van heb gehoord is 1,54 miljoen VLF's in een transactielogboek dat meer dan 1 TB groot was!).
De manier om te zien hoeveel VLF's u heeft, is door de ongedocumenteerde (en volledig veilige) DBCC LOGINFO te gebruiken. opdracht. Het aantal uitvoerrijen is het aantal VLF's in uw transactielogboek. Als u denkt dat u er te veel heeft, kunt u ze als volgt verminderen:
- Laat het logboek wissen
- Het logboek handmatig verkleinen
- Herhaal stap 1 en 2 totdat het logboek een klein formaat bereikt (wat lastig kan zijn op een druk productiesysteem)
- Laat het logboek handmatig groeien tot de gewenste grootte, in stappen van maximaal 8 GB, zodat elke VLF niet groter is dan ongeveer 0,5 GB
U kunt meer lezen over VLF-fragmentatieproblemen en het proces om ze op te lossen op:
- Microsoft KB-artikel dat adviseert om VLF-nummers te verminderen
- Kan groei van logbestanden invloed hebben op DML?
- 8 stappen voor een betere verwerking van transactielogboeken
Tempdb
Tempdb moet zijn transactielogboek hebben geconfigureerd, net als elke andere database, en het kan net als elke andere database groeien. Maar het vertoont ook verraderlijk gedrag dat problemen kan veroorzaken.
Als een SQL Server-instantie om welke reden dan ook opnieuw wordt opgestart, zullen de gegevens en logbestanden van tempdb terugkeren naar de grootte waarop ze het laatst waren ingesteld. Dit is anders dan alle andere databases, die hun huidige grootte behouden nadat een instantie opnieuw is opgestart.
Dit gedrag betekent dat als het transactielogboek van tempdb is gegroeid om de normale werklast aan te kunnen, u een ALTER DATABASE moet uitvoeren om de grootte van het logbestand in te stellen, anders zal de grootte ervan afnemen nadat een instantie opnieuw is opgestart en moet deze opnieuw groeien. Elke keer dat een logbestand groeit of automatisch groeit, moet de nieuwe ruimte op nul worden geïnitialiseerd en wordt de logactiviteit onderbroken terwijl dat wordt gedaan. Dus als u de grootte van uw tempdb-logbestand niet correct beheert, betaalt u een prestatiestraf als deze groeit na elke herstart van de instantie.
Regelmatig krimpen van logbestanden
Heel vaak hoor ik mensen zeggen dat ze het transactielogboek van een database meestal verkleinen nadat het is gegroeid door een normale bewerking (bijvoorbeeld een wekelijkse gegevensimport). Dit is niet goed om te doen.
Zoals ik hierboven heb uitgelegd, telkens wanneer het transactielogboek groeit of automatisch groeit, is er een pauze terwijl het nieuwe gedeelte van het logbestand op nul wordt geïnitialiseerd. Als u het transactielogboek regelmatig verkleint omdat het naar maat X groeit, betekent dit dat u regelmatig prestatieproblemen ondervindt omdat het transactielogboek automatisch weer naar maat X groeit.
Als uw transactielogboek blijft groeien naar maat X, laat het dan met rust! Stel het proactief in op maat X, beheer uw VLF's zoals ik hierboven heb uitgelegd, en accepteer maat X als de maat die nodig is voor uw normale werklast. Een groter transactielogboek is geen probleem.
Meerdere logbestanden
Het maken van meerdere logbestanden voor een database levert geen prestatiewinst op. Het toevoegen van een tweede logbestand kan echter nodig zijn als het bestaande logbestand onvoldoende ruimte heeft en u niet bereid bent om het transactielogboek te wissen door over te schakelen naar het eenvoudige herstelmodel en een controlepunt uit te voeren (omdat dit de logback-up verbreekt ketting).
Ik krijg vaak de vraag of er een dringende reden is om het tweede logbestand te verwijderen of dat het oké is om het te laten staan. Het antwoord is dat je het zo snel mogelijk moet verwijderen.
Hoewel het tweede logbestand geen prestatieproblemen voor uw werkbelasting veroorzaakt, heeft het wel invloed op herstel na noodgevallen. Als uw database om de een of andere reden is vernietigd, moet u deze helemaal opnieuw herstellen. De eerste fase van een herstelprocedure is het maken van de gegevens en logbestanden als ze nog niet bestaan.
U kunt het maken van gegevensbestanden bijna onmiddellijk maken door directe bestandsinitialisatie in te schakelen, waarbij de nul-initialisatie wordt overgeslagen, maar dat is niet van toepassing op logbestanden. Dit betekent dat bij het terugzetten alle logbestanden moeten worden aangemaakt die bestonden toen de volledige back-up werd gemaakt (of zijn gemaakt gedurende de periode die wordt gedekt door een transactielogback-up) en deze op nul moet initialiseren. Als je een tweede logbestand hebt gemaakt en bent vergeten het weer te laten vallen, zal het nul-initialiseren ervan tijdens een noodhersteloperatie bijdragen aan de totale uitvaltijd. Dit is geen prestatieprobleem van de werkbelasting, maar het beïnvloedt de beschikbaarheid van de server als geheel.
Terugkeren van een database-snapshot
Het laatste probleem in mijn lijst is eigenlijk een bug in SQL Server. Als u een database-snapshot gebruikt als een manier om snel terug te gaan naar een bekend tijdstip zonder dat u back-ups hoeft te herstellen (bekend als het herstellen van de snapshot), dan kunt u veel tijd besparen. Er is echter een groot nadeel.
Wanneer de database terugkeert van de database-snapshot, wordt het transactielogboek opnieuw gemaakt met twee 0,25 MB VLF's. Dit betekent dat u uw transactielogboek weer moet laten groeien tot de optimale grootte en het optimale aantal VLF's (anders groeit het automatisch), met alle nul-initialisatie en werkbelastingspauzes die ik eerder heb besproken. Duidelijk niet het gewenste gedrag.
Samenvatting
Zoals je kunt zien in dit bericht en mijn vorige twee berichten, zijn er veel dingen die kunnen leiden tot slechte transactielogboekprestaties, wat vervolgens een domino-effect heeft op de prestaties van je algehele werklast.
Als je voor al deze dingen kunt zorgen, heb je gezonde transactielogboeken. Maar daar houdt het niet op, want u moet ervoor zorgen dat u uw transactielogboeken in de gaten houdt, zodat u wordt gewaarschuwd voor zaken als automatische groei en overmatige I/O-latenties bij lezen en schrijven. Hoe je dat doet, zal ik in een volgend bericht bespreken.