I min tidligere artikel om SQL Server-systemdatabaser lærte vi om hver systemdatabase, der kommer som en del af SQL Server-installationen. Den aktuelle artikel vil fokusere på ofte opståede problemer omkring tempdb-databasen og hvordan man løser dem korrekt.
SQL Server TempDB
Som navnet på denne systemdatabase indikerer, tempdb rummer midlertidige objekter oprettet af SQL Server. De vedrører flere operationer og fungerer som et globalt arbejdsområde for alle brugere, der forbinder til SQL Server-instanser.
Tempdb-databasen vil indeholde nedenstående objekttyper, mens brugerne udfører deres handlinger:
- Midlertidige objekter oprettes eksplicit af brugere. De kan enten være lokale eller globale midlertidige tabeller og indekser, tabelvariabler, tabeller brugt i tabelværdierede funktioner og markører.
- Interne objekter oprettet af databasemotoren som
- Arbejdstabeller, der gemmer mellemresultater for spoler, markører, sorteringer og midlertidige store objekter (LOB).
- Arbejdsfiler, mens du udfører Hash Join- eller Hash-aggregatoperationer.
- Mellem sorteringsresultater under oprettelse eller genopbygning af indekser, hvis SORT_IN_TEMPDB er indstillet til TIL, og andre operationer såsom GROUP BY, ORDER BY eller SQL UNION-forespørgsler.
- Version Stores, der understøtter Row versioning-funktionen, enten Common version Store eller Online Index build version Store bruger tempdb-databasefilerne.
Tempdb-databasen oprettes hver gang SQL Server Service starter. Derfor kan tidspunktet for oprettelse af tempdb-databasen betragtes som en omtrentlig opstartstid for SQL Server Service. Vi kan identificere det fra sys.databases DMV ved at bruge forespørgslen vist nedenfor:
SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'
Selve opstarten af SQL Server Service involverer dog opstart af alle systemdatabaser i en bestemt rækkefølge. Det kan ske lidt tidligere end tempdb-oprettelsestidspunktet. Vi kan få værdien ved at bruge sys.databases DMV ved at udføre nedenstående forespørgsel på sys.dm_os_sys_info DMV .
SELECT ms_ticks, sqlserver_start_time_ms_ticks, sqlserver_start_time
FROM sys.dm_os_sys_info
ms_ticks kolonne angiver antallet af millisekunder, siden computeren eller serveren startede. sqlserver_start_time_ms_ticks kolonne angiver antallet af millisekunder siden ms_ticks nummer, da SQL Server Service startede.
Vi kan finde mere information om rækkefølgen af databaser, der startede op, mens SQL Server-tjenesterne blev startet, i SQL Server-fejlloggen.
Udvid Management i SSMS > SQL-serverfejllogfiler > åbne den aktuelle fejllog. Anvend Start op database filtrer og klik på Dato for at sortere det i stigende rækkefølge:
Vi kan se, at masterdatabasen er startet først, mens SQL Server-tjenesten blev startet. Derefter fulgte alle brugerdatabaser og alle andre systemdatabaser. Endelig startede tempdb'en. Du kan også hente disse oplysninger programmatisk ved at udføre xp_readerrorlog systemprocedure:
Bemærk :Begge ovenstående tilgange viser muligvis ikke de nødvendige oplysninger, hvis SQL Server Service ikke blev genstartet for nylig, og SQL Server Error Log blev genbrugt, hvilket kunne have skubbet ældre fejllogfiler til ældre filer. I så fald skal vi muligvis scanne data på tværs af de arkiverede SQL Server-fejllogfiler.
Ofte opståede problemer i SQL TempDB-database
Da tempdb giver et globalt arbejdsområde for alle brugersessioner eller aktiviteter, kan det blive en ydeevne flaskehals for brugeroperationer, hvis det ikke konfigureres omhyggeligt. I min tidligere artikel har vi diskuteret de anbefalede bedste praksisser til at implementere i tempdb-databasen. Men selv efter at have implementeret dem, kan vi ofte støde på problemer:
- Ujævn filvækst på tværs af tempdb-datafiler.
- Tempdb-datafiler vokser til en enorm værdi og skal formindske Tempdb.
Ujævn filvækst på tværs af TempDB-datafiler
Fra SQL Server 2000 er standardanbefalingen at have flere datafiler baseret på antallet af logiske kerner, der er tilgængelige på serveren.
Når vi har flere datafiler, for eksempel 4 tempdb-datafiler som på billedet nedenfor, vil autovækst af tempdb-datafiler ske med 64 MB på en round-robin måde startende fra tempdev> temp2> temp3> temp4> tempdev> og så videre.
Hvis en af filstørrelserne af en eller anden grund ikke automatisk kan vokse, vil det resultere i visse filers enorme størrelser sammenlignet med andre filer. Det fører til yderligere overbelastning på store filer og en negativ indvirkning på ydeevnen på tempdb-databasen.
Vi er nødt til manuelt at sikre, at alle tempdb-datafiler er ensartede på et hvilket som helst tidspunkt manuelt for at undgå uenighed eller ydeevneproblemer indtil SQL Server 2014. Microsoft ændrede denne adfærd fra SQL Server 2016 og senere versioner ved at implementere få funktioner, som vil blive diskuteret senere i denne artikel.
For at overvinde ovenstående præstationsproblemer har SQL Server introduceret 2 sporingsflag navngivet 1117 og 1118 for at undgå stridsproblemerne omkring tempdb.
- Sporflag 1117 – muliggør automatisk vækst af alle filer inden for en enkelt filgruppe
- Sporflag 1118 – aktiverer UNIFORM FULL EXTENTS for tempdb
Sporflag 1117
Uden Trace Flag 1117 aktiveret, hver gang tempdb er konfigureret med flere datafiler, der er lige store, og datafiler skal vokse automatisk, vil SQL Server som standard forsøge at øge filstørrelserne på en round-robin måde, hvis alle filer. Hvis datafilerne ikke har ens størrelse, så vil SQL Server forsøge at øge størrelsen af den største datafil af tempdb og vil bruge denne større fil til de fleste af brugeroperationerne, hvilket resulterer i tempdb-stridsproblemer.
For at løse dette problem introducerede SQL Server Trace Flag 1117. Når først den er aktiveret, hvis én fil i en filgruppe skal vokse automatisk, vil den automatisk vokse alle filer i den filgruppe. Det løser tempdb-stridsproblemerne. Men fangsten er, at når Trace flag 1117 er aktiveret, konfigureres auto-growth også for alle brugerdatabaser.
Sporingsflag 1118
Trace Flag 1118 bruges til at aktivere UNIFORM FULL UDVIDELSE. Lad os tage et skridt tilbage for at forstå, hvordan SQL Server gemmer data fra basic.
Side er den grundlæggende lagerenhed i SQL Server med en størrelse på 8 kilobytes (KB).
Omfang er et sæt på 8 fysisk sammenhængende sider med størrelsen 64KB(8*8KB). Baseret på hvor mange objekter eller ejere, der gemmer data i et omfang, kan omfang klassificeres i:
- Uniforme omfang er 8 sammenhængende sider, der bruges eller tilgås af et enkelt objekt eller ejer;
- Blandet Omfang – er 8 sammenhængende sider brugt eller tilgået af minimum 2 og højst 8 objekter eller ejere
Aktivering af Trace Flag 1118 vil tillade tempdb at have ensartede udstrækninger, hvilket resulterer i bedre ydeevne.
Sådan aktiverer du sporingsflag 1117 og 1118
Trace Flags kan aktiveres via flere tilgange. Du kan definere den passende måde fra nedenstående muligheder:
SQL Server Service Startup Parameters
Permanent tilgængelig, selv efter genstart af SQL Service. Den anbefalede måde er at aktivere Trace Flags 1117 og 1118 via SQL Server Service-startparametrene .
Åbn SQL Server Configuration Manager og klik på SQL Server Services for at liste de tilgængelige tjenester på den server:
- Højreklik på SQL Server (MSSQLSERVER) > Egenskaber > Opstartsparametre .
- Typ –T ind i det tomme felt for at angive sporingsflaget .
- Angiv værdierne 1117 og 1118 som vist nedenfor.
- Klik på Tilføj at få tilføjet sporingsflag som opstartsparametre.
Klik derefter på OK at få tilføjet sporingsflag permanent for denne forekomst af SQL Server. Genstart SQL Server Service, for at ændringerne bliver afspejlet.
DBCC TRACEON (, -1)
Aktiver et sporingsflag globalt. SQL Server-tjenesten vil miste sporingsflag ved genstart af tjenesten. For at aktivere et sporingsflag globalt skal du udføre nedenstående script i et nyt forespørgselsvindue:
DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);
DBCC TRACEON ()
Aktiver sporingsflaget på sessionsniveau. Det gælder kun for den aktuelle session oprettet af brugeren. For at aktivere et sporingsflag på sessionsniveau skal du udføre nedenstående script i et nyt forespørgselsvindue:
DBCC TRACEON(1117);
DBCC TRACEON(1118);
For at se listen over sporingsflag, der er aktiveret i en forekomst af SQL Server, kan vi bruge DBCC TRACESTATUS kommando:
DBCC TRACESTATUS();
Som vi kan se, er Trace Flag 1117 og 1118 aktiveret globalt i mit tilfælde sammen med Session .
For at deaktivere et sporingsflag kan vi bruge DBCC TRACEOFF kommando som:
DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);
SQL Server 2016 TempDB-forbedringer
På tværs af SQL Server-versioner SQL Server 2000 til SQL Server 2014 skal vi aktivere Trace Flags 1117 og 1118 sammen med komplet overvågning af tempdb for at undgå problemer med tempdb-stridigheder. Fra SQL Server 2016 og nyere versioner er sporingsflag 1117 og 1118 implementeret som standard.
Men baseret på min personlige erfaring er det bedre at forvokse tempdb til en enorm størrelse for at undgå behovet for autovækst flere gange og for at eliminere ujævne filstørrelser eller enkelte filer, der bruges i vid udstrækning af SQL Server .
Vi kan verificere, hvordan Trace Flag 1117 og 1118 er implementeret i SQL Server 2016:
Sporflag 1117 som indstiller autovæksten af alle filer i en filgruppe er nu en egenskab for filgruppen . Vi kan konfigurere den, mens vi opretter en ny filgruppe eller ændrer en eksisterende.
For at bekræfte filgruppens auto-grow-egenskab , kør nedenstående script fra sys.filegroups DMV :
SELECT name Filegroup_Name, is_autogrow_all_files
FROM sys.filegroups
For at ændre egenskaben for auto-growth for den primære filgruppe i AdventureWorks-databasen , udfører vi nedenstående script med enten AUTOGROW_ALL_FILES for automatisk at vokse alle filer ligeligt eller AUTOGROW_SINGLE_FILE for at tillade autovækst af kun en enkelt datafil.
ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE
-- AUTOGROW_ALL_FILES is the default behavior
GO
Sporflag 1118 som indstiller egenskaben Uniform Extent for datafiler er som standard aktiveret for tempdb og alle brugerdatabaser fra SQL Server 2016 . Vi kan ikke ændre egenskaberne for tempdb, da den nu kun understøtter muligheden Uniform Extent.
For brugerdatabaser kan vi ændre denne parameter. Systemdatabaserne master, model og msdb understøtter blandet omfang som standard og kan heller ikke ændres.
Brug nedenstående script for at ændre egenskabsværdierne for blandet sideallokering for brugerdatabaser:
ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON
-- OFF is the default behavior
GO
For at bekræfte egenskaben Mixed page allocation kan vi forespørge på is_mixed_page_allocation_on kolonne fra sys.databases DMV med værdien 0, hvilket angiver sideallokering med ensartet omfang, og 1 for at angive sideallokering med blandet omfang.
SELECT name, is_mixed_page_allocation_on
FROM sys.databases
TempDB-datafiler vokser til en enorm værdi, der kræver formindskelse af TempDB
I SQL Server 2014 eller tidligere versioner, hvis Trace-flag 1117 og 1118 ikke er konfigureret korrekt sammen med flere datafiler oprettet til tempdb-databasen, vil nogle af disse filer uundgåeligt vokse sig enorme. Hvis det sker, forsøger en DBA normalt at formindske tempdb-datafilerne. Men det er en upassende tilgang til at håndtere dette scenarie.
Der er andre muligheder for at formindske tempdb.
Lad os overveje de DBCC-kommandoer, der er tilgængelige for Shrink tempdb, og virkningerne af at udføre disse operationer.
DBCC SHRINKDATABASE
DBCC SHRINKDATABASE console-kommandoen virker ved at krympe slutningen af Data\Log-filerne .
For at formindske en database skal kommandoen have ledig plads i slutningen af filen. Hvis der er nogen aktive transaktioner i slutningen af filen, kan databasefilerne ikke krympes.
virkningen af at udføre DBCC SHRINKDATABASE er, at den vil forsøge at rydde ledig plads i slutningen af hver datafil eller logfil, som kunne have været reserveret til fremtidig vækst af tabeldata. Derfor kan kørsel af denne kommando resultere i ujævne filstørrelser, der kan føre til problemer med tempdb-stridigheder.
Syntaks til at formindske en brugerdatabase, f.eks. Adventureworks-database, ville være
DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);DBCC SHRINKFILE
DBCC SHRINKFILE console-kommandoen fungerer på samme måde som DBCC SHRINKDATABASE, men den formindsker de angivne databasedata eller logfiler .
Hvis du identificerer, at en bestemt tempdb-datafil er enorm, kan vi prøve at formindske det pågældende element ved hjælp af DBCC SHRINKFILE som vist nedenfor.
Vær forsigtig, mens du bruger denne kommando på tempdb, fordi hvis en fil krympes til en værdi, der er lavere eller højere end andre datafiler, vil den pågældende datafil ikke blive brugt effektivt. Eller det vil blive brugt oftere, hvilket fører til tempdb-stridsproblemer.
Syntaks til at udføre DBCC SHRINKFILE operation på AdventureWorks datafil til 1 GB (1024 MB) ville være:
DBCC SHRINKFILE (AdventureWorks, 1024);
GO
DBCC DROPCLEANBUFFERE
DBCC DROPCLEANBUFFERS console-kommandoen bruges til at rydde alle rene buffere fra bufferpuljen og columnstore-objekter fra columnstore-objektpuljen .
Udfør blot nedenstående kommando:
DBCC DROPCLEANBUFFERSDBCC FREEPROCCACHE
DBCC FREEPROCCACHE kommandoen rydder al den lagrede procedureudførelsesplans cache .
Procedure Execution Plan Cache bruges af SQL Server til at udføre de samme procedurekald hurtigere. Efter udførelse af DBCC FREEPROCCACHE ryddes plancachen. SQL Server skal således oprette denne cache igen, når den lagrede procedure udføres i instansen. Det efterlader en alvorlig negativ indvirkning, når det udføres i Production DB-forekomsterne.
Det anbefales ikke at udføre DBCC FREEPROCCACHE på produktionsdatabaseinstansen!
Syntaksen til at udføre DBCC FREEPROCCACHE er nedenfor:
DBCC FREEPROCCACHEDBCC FREESESSIONCACHE
DBCC FREESESSIONCACHE kommandoen rydder distributionsforespørgselsforbindelsescachen fra SQL Server-forekomsten . Det vil være nyttigt, når der er mange distribuerede forespørgsler, der udføres på en bestemt SQL Server-instans.
Syntaksen til at udføre DBCC FREESESSIONCACHE ville være:
DBCC FREESESSIONCACHEDBCC FREESYSTEMCACHE
DBCC FREESYSTEMCACHE kommandoen rydder alle ubrugte cacheposter fra al cache . SQL Server gør dette som standard for at gøre mere hukommelse tilgængelig for nye operationer. Vi kan dog udføre det manuelt ved at bruge nedenstående kommando:
DBCC FREESYSTEMCACHESom vi ved, gemmer tempdb alle midlertidige brugerobjekter eller interne objekter, inklusive Execution Plan Cache, Buffer pool data, Session Caches og System Caches. Derfor vil udførelse af ovenstående 6 DBCC-kommandoer hjælpe med at rydde ud af tempdb-datafilerne, der forhindrer den normale krympningsproces.
Selvom vi har gennemgået trin til, hvordan man formindsker tempdb via forskellige tilgange, er de anbefalede bedste praksisser til at håndtere tempdb-databasen anført nedenfor:
a. Genstart SQL Server Services, hvis det er muligt for at genskabe tempdb-datafiler jævnt. En potentiel indvirkning ville være, at vi mister alle eksekveringsplaner og andre cacheoplysninger, der er diskuteret ovenfor.
b. Forvoks tempdb-datafiler til en enorm filstørrelse, der er tilgængelig i drevet med tempdb-datafiler. Dette forhindrer SQL Server i at øge filstørrelserne ujævnt i SQL Server-versioner 2014 og tidligere.
c. Hvis SQL Server Services ikke kan genstartes på grund af RTO eller RPO, så prøv ovenstående DBCC-kommandoer efter at have forstået virkningerne klart.
d. Formindskelse af tempdb-database eller datafiler er ikke en anbefalet tilgang, og gør det derfor aldrig i dit produktionsmiljø, medmindre der ellers ikke er andre muligheder.
Konklusion
Vi har lært mere om det indre af, hvordan tempdb fungerer, så vi kan konfigurere tempdb til bedre ydeevne og undgå konfliktproblemer på tempdb. Vi har også gennemgået de ofte opståede problemer i tempdb, foranstaltninger tilgængelige i SQL Server på tværs af forskellige versioner og hvordan man håndterer det effektivt. Ud over det har vi undersøgt, hvorfor krympning af tempdb-database eller datafiler ikke er en anbefalet tilgang, mens vi håndterer tempdb-database.