I mine sidste to indlæg diskuterede jeg måder at reducere mængden af transaktionslog, der genereres, og hvordan man sikrer, at transaktionsloggen altid kan ryddes korrekt. I dette indlæg vil jeg fortsætte med transaktionsloggens ydeevnetema og diskutere nogle transaktionslogkonfigurationsproblemer, der kan forårsage problemer.
For mange VLF'er
Transaktionsloggen er delt op i bidder kaldet virtuelle logfiler (VLF'er), så logstyringssystemet nemt kan holde styr på, hvilke dele af transaktionsloggen, der er tilgængelige til genbrug. Der er en formel for, hvor mange VLF'er du får, når du opretter din transaktionslog, vokser den manuelt, eller den vokser automatisk:
| Op til 1 MB | 2 VLF'er, hver omkring 1/2 af den samlede størrelse |
|---|---|
| 1 MB til 64 MB | 4 VLF'er, hver omkring 1/4 af den samlede størrelse |
| 64 MB til 1 GB | 8 VLF'er, hver omkring 1/8 af den samlede størrelse |
| Mere end 1 GB | 16 VLF'er, hver omkring 1/16 af den samlede størrelse |
For eksempel, hvis du opretter en transaktionslog til 8 GB, får du 16 VLF'er, hvor hver er omkring 512 MB. Hvis du derefter udvider loggen med yderligere 4 GB, vil du få yderligere 16 VLF'er, som hver er omkring 256 MB, til i alt 32 VLF'er.
Bemærk:denne algoritme er ændret en smule for SQL Server 2014 for at afhjælpe VLF-fragmenteringsproblemerne – se dette blogindlæg for detaljer
En generel bedste praksis er at indstille log-autovæksten til noget andet end standardværdien på 10 %, så du kan kontrollere den pause, der kræves ved nul-initialisering af nyt transaktionslogrum. Lad os sige, at du opretter en 256 MB transaktionslog og indstiller autovæksten til 32 MB, og derefter vokser loggen til en steady-state størrelse på 16 GB. Givet formlen ovenfor vil dette resultere i, at din transaktionslog har mere end 2.000 VLF'er.
Så mange VLF'er vil sandsynligvis resultere i nogle præstationsproblemer for operationer, der behandler transaktionsloggen (f.eks. gendannelse af nedbrud, rydning af log, sikkerhedskopiering af logfiler, transaktionsreplikering, databasegendannelse). Denne situation kaldes at have VLF-fragmentering. Generelt vil ethvert antal VLF'er mere end tusinde eller deromkring være problematiske og skal løses (det meste, jeg nogensinde har hørt om, er 1,54 millioner VLF'er i en transaktionslog, der var mere end 1 TB i størrelse!).
Måden at fortælle, hvor mange VLF'er du har, er at bruge den udokumenterede (og fuldstændig sikre) DBCC LOGINFO kommando. Antallet af outputrækker er antallet af VLF'er i din transaktionslog. Hvis du tror, du har for mange, er måden at reducere dem på:
- Tillad loggen at rydde
- Formindsk loggen manuelt
- Gentag trin 1 og 2, indtil loggen når en lille størrelse (hvilket kan være vanskeligt i et travlt produktionssystem)
- Udvid loggen manuelt til den størrelse, den skal have, i op til 8 GB trin, så hver VLF ikke er større end ca. 0,5 GB
Du kan læse mere om VLF-fragmenteringsproblemer og processen til at løse dem på:
- Microsoft KB-artikel, der anbefaler at reducere VLF-tal
- Kan vækst af logfiler påvirke DML?
- 8 trin til bedre transaktionsloggennemstrømning
Tempdb
Tempdb skal have sin transaktionslog konfigureret ligesom enhver anden database, og den kan vokse ligesom enhver anden database. Men den har også noget snigende adfærd, der kan give dig problemer.
Når en SQL Server-instans genstarter af en eller anden grund, vil tempdbs data og logfiler vende tilbage til den størrelse, de senest blev indstillet til. Dette er forskelligt fra alle andre databaser, som forbliver i deres nuværende størrelse efter en genstart af forekomsten.
Denne adfærd betyder, at hvis tempdb-transaktionsloggen er vokset til at rumme den normale arbejdsbyrde, skal du udføre en ALTER DATABASE for at indstille logfilens størrelse, ellers vil dens størrelse falde efter en genstart af forekomsten, og den bliver nødt til at vokse igen. Hver gang en logfil vokser eller automatisk vokser, skal den nye plads nulinitialiseres, og logningsaktiviteten stopper, mens det er gjort. Så hvis du ikke administrerer din tempdb-logfilstørrelse korrekt, betaler du en præstationsbod, efterhånden som den vokser efter hver genstart af forekomsten.
Almindelig logfil formindskelse
Ganske ofte hører jeg folk sige, hvordan de normalt formindsker en databases transaktionslog, efter at den vokser fra en almindelig operation (f.eks. en ugentlig dataimport). Dette er ikke en god ting at gøre.
Ligesom jeg forklarede ovenfor, når transaktionsloggen vokser eller automatisk vokser, er der en pause, mens den nye del af logfilen nul-initialiseres. Hvis du regelmæssigt formindsker transaktionsloggen, fordi den vokser til størrelse X, betyder det, at du regelmæssigt lider af ydeevneproblemer, da transaktionsloggen automatisk vokser tilbage til størrelse X igen.
Hvis din transaktionslog bliver ved med at vokse til størrelse X, så lad den være! Indstil den proaktivt til størrelse X, administrer dine VLF'er, som jeg forklarede ovenfor, og accepter størrelse X som den størrelse, der kræves til din normale arbejdsbyrde. En større transaktionslog er ikke et problem.
Flere logfiler
Der er ingen ydeevnegevinst ved at oprette flere logfiler til en database. Det kan dog være nødvendigt at tilføje en anden logfil, hvis den eksisterende logfil løber tør for plads, og du ikke er villig til at tvinge transaktionsloggen til at rydde ved at skifte til den simple gendannelsesmodel og udføre et kontrolpunkt (da dette bryder log-backupen kæde).
Jeg bliver ofte spurgt, om der er nogen presserende grund til at fjerne den anden logfil, eller om det er ok at lade den være på plads. Svaret er, at du skal fjerne det så hurtigt som muligt.
Selvom den anden logfil ikke forårsager ydeevneproblemer for din arbejdsbyrde, påvirker den katastrofegendannelse. Hvis din database er ødelagt af en eller anden grund, skal du gendanne den fra bunden. Den første fase af enhver gendannelsessekvens er at oprette dataene og logfilerne, hvis de ikke eksisterer.
Du kan gøre oprettelsen af datafilen næsten øjeblikkelig ved at aktivere øjeblikkelig filinitialisering, som springer nulinitialiseringen over, men det gælder ikke for logfiler. Dette betyder, at gendannelsen skal oprette alle logfiler, der eksisterede, da den fulde backup blev taget (eller oprettes i den periode, der dækkes af en transaktionslog-backup) og nul-initialisere dem. Hvis du har oprettet en anden logfil og glemt at slippe den igen, vil nul-initialisering af den under en katastrofegenetablering føje til den samlede nedetid. Dette er ikke et problem med arbejdsbelastningens ydeevne, men det påvirker tilgængeligheden af serveren som helhed.
Vendelse af et øjebliksbillede fra en database
Det sidste problem på min liste er faktisk en fejl i SQL Server. Hvis du bruger et database-øjebliksbillede som en måde til hurtigt at gendanne tilbage til et kendt tidspunkt uden at skulle gendanne sikkerhedskopier (kendt som at vende tilbage fra øjebliksbilledet), så kan du spare en masse tid. Der er dog en stor ulempe.
Når databasen vender tilbage fra database-øjebliksbilledet, genskabes transaktionsloggen med to 0,25 MB VLF'er. Dette betyder, at du bliver nødt til at vokse din transaktionslog tilbage til dens optimale størrelse og antal VLF'er (ellers vil den automatisk vokse sig selv), med alle de nul-initialisering og arbejdsbelastningspauser, jeg har diskuteret tidligere. Klart ikke den ønskede adfærd.
Oversigt
Som du kan se fra dette indlæg og mine to foregående indlæg, er der mange ting, der kan føre til dårlig transaktionslog-ydeevne, som så har en afsmittende effekt på ydeevnen af din samlede arbejdsbyrde.
Hvis du kan tage dig af alle disse ting, har du sunde transaktionslogfiler. Men det slutter ikke der, da du skal sikre dig, at du overvåger dine transaktionslogfiler, så du bliver advaret om ting som automatisk vækst og overdreven læse- og skrive-I/O-forsinkelser. Jeg vil dække, hvordan man gør det i et fremtidigt indlæg.