SQL Server-systemdatabaser – Tempdb-underhållet

I min tidigare artikel om SQL Server-systemdatabaser lärde vi oss om varje systemdatabas som kommer som en del av SQL Server-installationen. Den aktuella artikeln kommer att fokusera på vanliga problem kring tempdb-databasen och hur man löser dem korrekt.

SQL Server TempDB

Som namnet på denna systemdatabas indikerar, tempdb innehåller tillfälliga objekt skapad av SQL Server. De relaterar till flera operationer och fungerar som ett globalt arbetsområde för alla användare som ansluter till SQL Server-instanser.

Tempdb-databasen kommer att innehålla nedanstående objekttyper medan användare utför sina operationer:

Tillfälliga objekt skapas uttryckligen av användare. De kan vara antingen lokala eller globala temporära tabeller och index, tabellvariabler, tabeller som används i tabellvärderade funktioner och markörer.
Interna objekt skapade av databasmotorn som
- Arbetstabeller som lagrar mellanliggande resultat för spolar, markörer, sorteringar och temporära stora objekt (LOB).
- Arbetsfiler medan du utför Hash Join eller Hash-aggregation.
- Mellanliggande sorteringsresultat vid skapande eller ombyggnad av index om SORT_IN_TEMPDB är inställt på PÅ, och andra operationer som GROUP BY-, ORDER BY- eller SQL UNION-frågor.
Versionsbutiker som stöder radversionsfunktion, antingen Common version Store eller Online Index build versionsbutik använder tempdb-databasfilerna.

Tempdb-databas skapas varje gång SQL Server Service startar. Därför kan tidpunkten för tempdb-databasens skapande betraktas som en ungefärlig starttid för SQL Server Service. Vi kan identifiera det från sys.databases DMV med hjälp av frågan som visas nedan:

SELECT name, database_id, create_date
FROM sys.databases
WHERE name = 'tempdb'

Den faktiska uppstarten av SQL Server Service innebär dock att alla systemdatabaser startas i en specifik sekvens. Det kan hända lite tidigare än tempdb-skapandet. Vi kan få värdet med sys.databases DMV genom att köra frågan nedan 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 kolumnen anger antalet millisekunder sedan datorn eller servern startade. sqlserver_start_time_ms_ticks kolumnen anger antalet millisekunder sedan ms_ticks nummer när SQL Server Service startade.

Vi kan hitta mer information om ordningen på databaser som startade när SQL Server-tjänsterna startas i SQL Server Error Log.

Expandera Management i SSMS > SQL-serverfelloggar > öppna den aktuella felloggen. Använd Start upp databas filtrera och klicka på Datum för att sortera det i stigande ordning:

Vi kan se att huvuddatabasen har startat först när SQL Server-tjänsten startas. Sedan följde alla användardatabaser och alla andra systemdatabaser. Äntligen startade tempdb. Du kan också hämta denna information programmatiskt genom att köra xp_readerrorlog systemprocedur:

Obs :Båda metoderna ovan kanske inte visar den nödvändiga informationen om SQL Server-tjänsten inte startades om nyligen och SQL Server Error Log återvinns vilket kan ha skickat äldre felloggar till äldre filer. I så fall kan vi behöva skanna data över de arkiverade SQL Server-felloggfilerna.

Vanliga problem i SQL TempDB-databasen

Eftersom tempdb tillhandahåller ett globalt arbetsområde för alla användarsessioner eller aktiviteter, kan det bli en prestandaflaskhals för användaroperationer om det inte konfigureras noggrant. I min tidigare artikel har vi diskuterat de rekommenderade bästa metoderna att implementera i tempdb-databasen. Men även efter att ha implementerat dem kan vi stöta på problem ofta:

Ojämn filtillväxt över tempdb-datafiler.
Tempdb-datafiler växer till ett enormt värde och måste krympa Tempdb.

Ojämn filtillväxt över TempDB-datafiler

Från och med SQL Server 2000 är standardrekommendationen att ha flera datafiler baserat på antalet logiska kärnor som är tillgängliga på servern.

När vi har flera datafiler, till exempel 4 tempdb-datafiler som i bilden nedan, kommer autotillväxt av tempdb-datafiler att ske med 64 MB på ett round-robin-sätt med start från tempdev> temp2> temp3> temp4> tempdev> och så vidare.

Om en av filstorlekarna inte kan växa automatiskt av någon anledning kommer det att resultera i vissa filers enorma storlekar jämfört med andra filer. Det leder till ytterligare överbelastning på enorma filer och en negativ prestandapåverkan på tempdb-databasen.

Vi måste manuellt se till att alla tempdb-datafiler är jämnstora när som helst manuellt för att undvika konflikter eller prestandaproblem fram till SQL Server 2014. Microsoft ändrade detta beteende från och med SQL Server 2016 och senare versioner genom att implementera några funktioner som kommer att vara diskuteras senare i den här artikeln.

För att övervinna ovanstående prestandaproblem har SQL Server introducerat 2 spårningsflaggor heter 1117 och 1118 för att undvika tvister kring tempdb.

Spårningsflagga 1117 – möjliggör automatisk tillväxt av alla filer inom en enda filgrupp
Spårningsflagga 1118 – aktiverar UNIFORM FULL EXTENTS för tempdb

Spårningsflagga 1117

Utan Trace Flag 1117 aktiverad, närhelst tempdb är konfigurerad med flera datafiler som är jämnt stora och datafiler behöver växa automatiskt, kommer SQL Server som standard att försöka öka filstorlekarna på ett round-robin-sätt om alla filer. Om datafilerna inte har en jämn storlek, kommer SQL Server att försöka öka storleken på den största datafilen i tempdb och kommer att använda denna större fil för de flesta användaroperationer, vilket leder till tempdb-konfliktproblem.

För att lösa detta problem introducerade SQL Server Trace Flag 1117. När den väl har aktiverats, om en fil i en filgrupp behöver växa automatiskt, kommer den att växa automatiskt för alla filer i den filgruppen. Det löser tempdb-stridsproblemen. Haken är dock att när spårningsflaggan 1117 är aktiverad, konfigureras automatisk tillväxt också för alla användardatabaser.

Spårningsflagga 1118

Trace Flag 1118 används för att möjliggöra UNIFORM FULL EXTENTS. Låt oss ta ett steg tillbaka för att förstå hur SQL Server lagrar data från basic.

Sida är den grundläggande enheten för lagring i SQL Server med en storlek på 8 kilobyte (KB).

Omfattning är en uppsättning av 8 fysiskt sammanhängande sidor med storleken 64KB(8*8KB). Baserat på hur många objekt eller ägare som lagrar data inom en Extent, kan Extent klassificeras i:

Uniforma omfattningar är 8 sammanhängande sidor som används eller nås av ett enda objekt eller ägare;
Blandat Omfång – är 8 sammanhängande sidor som används eller nås av minst 2 och högst 8 objekt eller ägare

Aktivering av Trace Flag 1118 kommer att tillåta tempdb att ha enhetlig utsträckning vilket resulterar i bättre prestanda.

Hur man aktiverar spårningsflaggor 1117 och 1118

Spårningsflaggor kan aktiveras via flera metoder. Du kan definiera det lämpliga sättet från alternativen nedan:

SQL Server Service Startup Parametrar

Permanent tillgänglig även efter omstart av SQL Service. Det rekommenderade sättet är att aktivera spårningsflaggor 1117 och 1118 via startparametrarna för SQL Server Service .

Öppna SQL Server Configuration Manager och klicka på SQL Server Services för att lista de tillgängliga tjänsterna på den servern:

Högerklicka på SQL Server (MSSQLSERVER) > Egenskaper > Startparametrar .
Typ –T i det tomma fältet för att ange Spårningsflaggan .
Ange värden 1117 och 1118 som visas nedan.
Klicka på Lägg till för att lägga till spårningsflaggor som startparametrar.

Klicka sedan på OK att låta spårningsflaggorna läggas till permanent för den här instansen av SQL Server. Starta om SQL Server Service för att ändringarna ska återspeglas.

DBCC TRACEON (, -1)

Aktivera en spårningsflagga globalt. SQL Server-tjänsten kommer att förlora spårningsflaggorna vid omstart av tjänsten. För att aktivera en spårningsflagga globalt, kör följande skript i ett nytt frågefönster:

DBCC TRACEON(1117,-1);
DBCC TRACEON(1118,-1);

DBCC TRACEON ()

Aktivera spårningsflaggan på sessionsnivå. Det gäller endast den aktuella sessionen som skapats av användaren. För att aktivera en spårningsflagga på sessionsnivå, kör följande skript i ett nytt frågefönster:

DBCC TRACEON(1117);
DBCC TRACEON(1118);

För att se listan över spårningsflaggor som är aktiverade i en instans av SQL Server kan vi använda DBCC TRACESTATUS kommando:

DBCC TRACESTATUS();

Som vi kan se är Spårningsflaggor 1117 och 1118 aktiverade globalt i mitt fall tillsammans med Session .

För att stänga av en spårningsflagga kan vi använda kommandot DBCC TRACEOFF som:

DBCC TRACEOFF(1117,-1);
DBCC TRACEOFF(1118,-1);

SQL Server 2016 TempDB-förbättringar

I alla SQL Server-versioner SQL Server 2000 till SQL Server 2014 måste vi aktivera Trace Flags 1117 och 1118 tillsammans med fullständig övervakning av tempdb för att undvika problem med tempdb-konflikter. Från och med SQL Server 2016 och senare versioner implementeras spårningsflaggor 1117 och 1118 som standard.

Men baserat på min personliga erfarenhet är det bättre att förväxa tempdb till en enorm storlek för att undvika behovet av autotillväxt flera gånger och för att eliminera ojämna filstorlekar eller enstaka filer som används i stor utsträckning av SQL Server .

Vi kan verifiera hur Trace Flag 1117 och 1118 implementeras i SQL Server 2016:

Spårningsflagga 1117 som anger autotillväxten för alla filer i en filgrupp är nu en egenskap för filgruppen . Vi kan konfigurera det samtidigt som vi skapar en ny filgrupp eller modifierar en befintlig.

För att verifiera egenskapen auto-grow för filgruppen , kör nedanstående skript från sys.filegroups DMV :

SELECT name Filegroup_Name, is_autogrow_all_files 
FROM sys.filegroups

För att ändra egenskapen auto-growth för databasen Primary Filegroup of AdventureWorks , kör vi skriptet nedan med antingen AUTOGROW_ALL_FILES för att automatiskt växa alla filer lika eller AUTOGROW_SINGLE_FILE för att tillåta autotillväxt av endast en enskild datafil.

ALTER DATABASE Adventureworks MODIFY FILEGROUP [PRIMARY]
AUTOGROW_SINGLE_FILE 
-- AUTOGROW_ALL_FILES is the default behavior
GO

Spårningsflagga 1118 som anger egenskapen Uniform Extent för datafiler är aktiverat som standard för tempdb och alla användardatabaser från och med SQL Server 2016 . Vi kan inte ändra egenskaperna för tempdb, eftersom det nu bara stöder alternativet Uniform Extent.

För användardatabaser kan vi ändra denna parameter. Systemdatabaserna master, model och msdb stöder blandade omfattningar som standard och kan inte ändras heller.

För att ändra egenskapsvärdena för tilldelning av blandade sidor för användardatabaser, använd skriptet nedan:

ALTER DATABASE Adventureworks SET MIXED_PAGE_ALLOCATION ON 
-- OFF is the default behavior
GO

För att verifiera egenskapen Mixed page allocation kan vi fråga is_mixed_page_allocation_on kolumn från sys.databases DMV med värdet 0, vilket indikerar enhetlig sidtilldelning, och 1 för att indikera den blandade sidtilldelningen.

SELECT name, is_mixed_page_allocation_on
FROM sys.databases

TempDB-datafiler växer till ett enormt värde som kräver krympa TempDB

I SQL Server 2014 eller tidigare versioner, om Trace-flaggor 1117 och 1118 inte är korrekt konfigurerade tillsammans med flera datafiler skapade för tempdb-databasen, kommer vissa av dessa filer oundvikligen att växa sig enorma. Om det händer försöker en DBA vanligtvis att krympa tempdb-datafilerna. Men det är en olämplig strategi för att hantera detta scenario.

Det finns andra tillgängliga alternativ för att krympa tempdb.

Låt oss överväga DBCC-kommandon som är tillgängliga för Shrink tempdb och effekterna av att utföra dessa operationer.

DBCC SHRINKDATABASE

DBCC SHRINKDATABASE console-kommandot fungerar genom att krympa slutet av Data\Log Files .

För att lyckas krympa en databas behöver kommandot ledigt utrymme i slutet av filen. Om det finns några aktiva transaktioner i slutet av filen kan databasfilerna inte krympas.

effekten av att köra DBCC SHRINKDATABASE är att den kommer att försöka rensa tillgängligt ledigt utrymme i slutet av varje datafil eller loggfil som kan ha reserverats för framtida tillväxt av tabelldata. Att köra det här kommandot kan därför resultera i ojämna filstorlekar som leder till tempdb-konflikter.

Syntax för att krympa en användardatabas till exempel Adventureworks databas skulle vara

DBCC SHRINKDATABASE (AdventureWorks, TRUNCATEONLY);

DBCC SHRINKFILE

DBCC SHRINKFILE console-kommandot fungerar på samma sätt som DBCC SHRINKDATABASE, men det krymper de angivna databasdata- eller loggfilerna .

Om du identifierar att en viss tempdb-datafil är enorm kan vi försöka krympa just den posten med DBCC SHRINKFILE som visas nedan.

Var försiktig när du använder det här kommandot på tempdb eftersom om en fil krymps till ett värde som är lägre eller högre än andra datafiler, kommer den specifika datafilen inte att användas effektivt. Eller så kommer den att användas oftare, vilket leder till tempdb-stridsproblem.

Syntax för att köra DBCC SHRINKFILE operation på AdventureWorks datafil till 1GB (1024 MB) skulle vara:

DBCC SHRINKFILE (AdventureWorks, 1024);  
GO

DBCC DROPCLEAN BUFFERS

DBCC DROPCLEANBUFFERS console-kommandot används för att rensa alla rena buffertar från buffertpoolen och columnstore-objekt från columnstore-objektpoolen .

Utför helt enkelt kommandot nedan:

DBCC DROPCLEANBUFFERS

DBCC FREEPROCCACHE

DBCC FREEPROCCACHE kommandot rensar all cache för exekveringsplan för lagrad procedur .

Procedure Execution Plan Cache används av SQL Server för att utföra samma proceduranrop snabbare. Efter att ha kört DBCC FREEPROCCACHE rensas plancachen. Därför måste SQL Server skapa den cachen igen när den lagrade proceduren exekveras i instansen. Det lämnar en allvarlig negativ inverkan när den körs i Production DB-instanserna.

Det rekommenderas inte att köra DBCC FREEPROCCACHE på produktionsdatabasinstansen!

Syntaxen för att köra DBCC FREEPROCCACHE är nedan:

DBCC FREEPROCCACHE

DBCC FREESESSIONCACHE

DBCC FREESESSIONCACHE kommandot rensar distributionsfrågans anslutningscache från SQL Server-instansen . Det kommer att vara användbart när det finns många distribuerade frågor som körs på en viss SQL Server-instans.

Syntaxen för att köra DBCC FREESESSIONCACHE skulle vara:

DBCC FREESESSIONCACHE

DBCC FREESYSTEMCACHE

DBCC FREESYSTEMCACHE kommandot rensar alla oanvända cacheposter från all cache . SQL Server gör detta som standard för att göra mer minne tillgängligt för nya operationer. Vi kan dock köra det manuellt med kommandot nedan:

DBCC FREESYSTEMCACHE

Som vi vet lagrar tempdb alla tillfälliga användarobjekt eller interna objekt inklusive exekveringsplancache, buffertpooldata, sessionscacher och systemcacher. Därför kommer att utföra ovanstående 6 DBCC-kommandon hjälpa till att rensa bort tempdb-datafilerna som förhindrar den normala krympningsprocessen.

Även om vi har gått igenom steg för hur man krymper tempdb via olika tillvägagångssätt, är de rekommenderade bästa metoderna för att hantera tempdb-databasen listade nedan:

a. Starta om SQL Server Services om möjligt för att återskapa tempdb-datafiler jämnt. Potentiell påverkan skulle vara att vi kommer att förlora alla exekveringsplaner och annan cacheinformation som diskuterats ovan.

b. Förodla tempdb-datafiler till en stor filstorlek som är tillgänglig i enheten som innehåller tempdb-datafiler. Detta kommer att förhindra att SQL Server ökar filstorlekarna ojämnt i SQL Server-versioner 2014 och tidigare.

c. Om SQL Server Services inte kan startas om på grund av RTO eller RPO, prova då ovanstående DBCC-kommandon efter att ha förstått effekterna tydligt.

d. Att krympa tempdb-databas eller datafiler är inte ett rekommenderat tillvägagångssätt och gör därför aldrig det i din produktionsmiljö såvida det inte finns några andra alternativ.

Slutsats

Vi har lärt oss mer om insidan av hur tempdb fungerar så att vi kan konfigurera tempdb för bättre prestanda och undvika konfliktproblem på tempdb. Vi har också gått igenom de vanligaste problemen i tempdb, åtgärder tillgängliga i SQL Server i olika versioner och hur man hanterar det effektivt. Utöver det har vi undersökt varför krympning av tempdb-databas eller datafiler inte är ett rekommenderat tillvägagångssätt när man hanterar tempdb-databas.