Guide för tråd- och uppgiftsarkitektur

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

Schemaläggning av operativsystemsaktivitet

Trådar är de minsta enheterna för bearbetning som utförs av ett operativsystem och möjliggör att programlogik delas upp i flera samtidiga exekveringsvägar. Trådar är användbara när komplexa program har många uppgifter som kan utföras samtidigt.

När ett operativsystem kör en instans av ett program skapas en enhet som kallas en process för att hantera instansen. Processen har en exekveringstråd. Det här är serien med programmeringsinstruktioner som utförs av programkoden. Om ett enkelt program till exempel har en enda uppsättning instruktioner som kan utföras seriellt, hanteras den uppsättningen instruktioner som en enda uppgift, och det finns bara en körningssökväg (eller tråd) via programmet. Mer komplexa program kan ha flera uppgifter som kan utföras samtidigt i stället för seriellt. Ett program kan göra detta genom att starta separata processer för varje aktivitet, vilket är en resursintensiv åtgärd, eller starta separata trådar, som är relativt mindre resursintensiva. Dessutom kan varje tråd schemaläggas för körning oberoende av de andra trådarna som är associerade med en process.

Trådar gör det möjligt för komplexa program att använda en processor (CPU) effektivare, även på datorer som har en enda processor. Med en PROCESSOR kan bara en tråd köras i taget. Om en tråd kör en tidskrävande åtgärd som inte använder processorn, till exempel en diskläsning eller skrivning, kan en annan av trådarna köras tills den första åtgärden har slutförts. Genom att kunna köra trådar medan andra trådar väntar på att en åtgärd ska slutföras kan ett program maximera användningen av processorn. Detta gäller särskilt för disk-I/O-intensiva program för flera användare, till exempel en databasserver. Datorer som har flera processorer kan köra en tråd per processor samtidigt. Om en dator till exempel har åtta processorer kan den köra åtta trådar samtidigt.

Schemaläggning av SQL Server-aktiviteter

När det gäller SQL Server är en begäran den logiska representationen av en fråga eller batch. En begäran representerar också åtgärder som krävs av systemtrådar, till exempel kontrollpunkt eller loggskrivare. Begäranden finns i olika tillstånd under hela livslängden och kan ackumulera väntetider när resurser som krävs för att utföra begäran inte är tillgängliga, till exempel lås eller låsningar. Mer information om begäransstatus finns i sys.dm_exec_requests.

Uppgifter

En uppgift representerar den arbetsenhet som måste slutföras för att uppfylla begäran. En eller flera uppgifter kan tilldelas till en enda begäran.

• Parallella begäranden har flera aktiva uppgifter som körs samtidigt istället för att köras i sekvenser, med en överordnad uppgift (eller koordinerande uppgift) och flera underordnade uppgifter. En körningsplan för en parallell förfrågan kan ha sekventiella grenar – områden i planen med operatorer som inte körs parallellt. Den överordnade aktiviteten ansvarar också för att köra dessa serieoperatorer.
• Seriebegäranden har bara en aktiv aktivitet vid en viss tidpunkt under körningen. Uppgifter finns i olika tillstånd under hela livslängden. Mer information om aktivitetstillstånd finns i sys.dm_os_tasks. Uppgifter i suspenderat tillstånd väntar på att de resurser som krävs för att utföra uppgifterna ska bli tillgängliga. För mer information om väntande processer, se sys.dm_os_waiting_tasks.

Arbetare

En SQL Server-arbetstråd, även kallad arbetare eller tråd, är en logisk representation av en operativsystemtråd. När du kör seriebegärandenskapar SQL Server Database Engine en arbetare för att köra den aktiva aktiviteten (1:1). När du kör parallella begäranden i radlägetilldelar SQL Server Database Engine en arbetare för att samordna de underordnade arbetare som ansvarar för att utföra uppgifter som tilldelats dem (även 1:1), som kallas överordnad tråd (eller samordningstråd). Den överordnade tråden har en överordnad aktivitet associerad med den. Föräldertråden är startpunkten för begäran och finns redan innan programvarumotorn tolkar en fråga. Huvudansvaret för den överordnade tråden är:

• Samordna en parallell genomsökning.
• Starta parallella underordnade arbetare.
• Samla in rader från parallella trådar och skicka till klienten.
• Utför lokala och globala aggregeringar.

Anteckning

Om en frågeplan har seriella och parallella grenar ansvarar en av de parallella uppgifterna för att utföra seriegrenen.

Antalet arbetstrådar som skapas för varje uppgift beror på:

• Om begäran var berättigad till parallellitet enligt frågeoptimerarens beslut.

• Vad den faktiska tillgängliga grad av parallellitet (DOP) i systemet är, baserat på aktuell belastning. Detta kan skilja sig från uppskattad DOP, som baseras på serverkonfigurationen för max grad av parallellitet (MAXDOP). Serverkonfigurationen för MAXDOP kan till exempel vara 8, men tillgänglig DOP under körningstid kan bara vara 2, vilket påverkar frågeutförandet. Minnesbelastning och brist på arbetskraft är två faktorer som minskar tillgänglig DOP vid körning.

Not

Den maximala graden av parallellitet (MAXDOP) gräns anges per aktivitet, inte per begäran. Det innebär att under en parallell frågekörning kan en enskild begäran skapa flera uppgifter upp till MAXDOP-gränsen, och varje uppgift använder en arbetare. Mer information om MAXDOP finns i Konfigurera den maximala graden av parallellitet serverkonfigurationsalternativ.

Schemaläggare

En schemaläggare, även kallad SOS-schemaläggare, hanterar arbetstrådar som behöver bearbetningstid för att utföra arbete för uppgifter. Varje schemaläggare mappas till en enskild processor (CPU). Den tid då en arbetare kan förbli aktiv i en schemaläggare kallas för OS-kvantum, med högst 4 ms. När kvanttiden har gått ut ger en arbetare sin tid till andra arbetare som behöver åtkomst till CPU-resurser och ändrar dess tillstånd. Det här samarbetet mellan arbetare för att maximera åtkomsten till CPU-resurser kallas kooperativ schemaläggning, även kallat icke-förebyggande schemaläggning. Ändringen i arbetstillståndet sprids i sin tur till den uppgift som är associerad med den arbetaren och till den begäran som är associerad med uppgiften. Mer information om arbetartillstånd finns i sys.dm_os_workers. Mer information om schemaläggare finns i sys.dm_os_schedulers.

Sammanfattningsvis kan en begäran skapa en eller flera uppgifter för att utföra enheter av arbete. Varje uppgift tilldelas en arbetstråd som ansvarar för att slutföra uppgiften. Varje arbetstråd måste schemaläggas (placeras på en schemaläggare) för aktivt utförande av uppgiften.

Tänk på följande scenario:

• Worker 1 är en långvarig uppgift, till exempel en läsförfrågan med förläsning över diskbaserade tabeller. Worker 1 hittar att dess nödvändiga datasidor redan finns i buffertpoolen, så den behöver inte ge efter för att vänta på I/O-åtgärder och kan använda hela kvantumet innan det ger.
• Worker 2 utför kortare uppgifter under millisekunder och måste därför ge resultat innan den fullständiga kvantmängden är slut.

I det här scenariot och fram till SQL Server 2014 (12.x) får Worker 1 i princip monopolisera schemaläggaren genom att ha mer övergripande kvanttid.

Från och med SQL Server 2016 (13.x) inkluderar samarbetsschemaläggning schemaläggning Large Deficit First (LDF). Med LDF-schemaläggning övervakas kvantanvändningsmönster och en arbetstråd monopoliserar inte en schemaläggare. I samma scenario tillåts Worker 2 att använda flera kvantor i följd innan Worker 1 får mer tid, vilket hindrar Worker 1 från att monopolisera schemaläggaren på ett ohälsosamt sätt.

Schema för parallella uppgifter

Föreställ dig en SQL Server som har konfigurerats med MaxDOP 8 och cpu-tillhörighet har konfigurerats för 24 processorer (schemaläggare) mellan NUMA-noderna 0 och 1. Schemaläggare 0 till 11 tillhör NUMA-noden 0, schemaläggare 12 till 23 tillhör NUMA-noden 1. Ett program skickar följande fråga (begäran) till databasmotorn:

SELECT h.SalesOrderID,
    h.OrderDate,
    h.DueDate,
    h.ShipDate
FROM Sales.SalesOrderHeaderBulk AS h
INNER JOIN Sales.SalesOrderDetailBulk AS d
    ON h.SalesOrderID = d.SalesOrderID
WHERE (h.OrderDate >= '2014-3-28 00:00:00');

Tips

Exempelfrågan kan köras med hjälp av AdventureWorks2016_EXT exempeldatabas. Tabellerna Sales.SalesOrderHeader och Sales.SalesOrderDetail förstorades 50 gånger och bytte namn till Sales.SalesOrderHeaderBulk och Sales.SalesOrderDetailBulk.

Körningsplanen visar en Hash Join mellan två tabeller och alla operatorer kördes parallellt, vilket anges av den gula cirkeln med två pilar. Varje parallellismoperator är en annan gren i planen. Därför finns det tre grenar i följande körningsplan.

Not

Om du ser en körningsplan som ett träd är en gren ett område i planen som grupperar en eller flera operatorer mellan parallellismoperatorer, även kallade Exchange Iterators. Mer information om planoperatorer finns i Showplans logiska och fysiska operatorreferens.

Det finns tre grenar i körningsplanen, men när som helst under körningen kan endast två grenar köras samtidigt i den här körningsplanen:

1. Delen där en klustad indexsökning används på Sales.SalesOrderHeaderBulk (indata för uppbyggnad vid sammanslagningen) körs självständigt.
2. Sedan körs grenen där en klustrad indexsökning används på Sales.SalesOrderDetailBulk (probindata för sammanfogningen) samtidigt med grenen där bitmap skapades och där för närvarande hashmatchning körs.

Showplan XML visar att 16 arbetstrådar har reserverats och använts på NUMA-noden 0:

<ThreadStat Branches="2" UsedThreads="16">
  <ThreadReservation NodeId="0" ReservedThreads="16" />
</ThreadStat>

Trådreservation säkerställer att databasmotorn har tillräckligt med arbetstrådar för att utföra alla uppgifter som behövs för begäran. Trådar kan reserveras över flera NUMA-noder eller reserveras i bara en NUMA-nod. Trådreservation görs under körning innan exekveringen startar och är beroende av schemaläggarens belastning. Antalet reserverade arbetstrådar härleds generellt från formeln concurrent branches * runtime DOP och utesluter den överordnade arbetstråden. Varje gren är begränsad till ett antal arbetstrådar som är lika med MaxDOP. I det här exemplet finns det två samtidiga grenar och MaxDOP är inställt på 8 och därför 2 * 8 = 16.

Som referens kan du se livekörningsplanen från Live Query Statistics, där en gren har slutförts och två grenar körs samtidigt.

SQL Server Database Engine tilldelar en arbetstråd för att köra en aktiv uppgift (1:1), vilket kan observeras under frågekörningen genom att använda sys.dm_os_tasks DMV, som visas i följande exempel:

SELECT parent_task_address, task_address,
       task_state, scheduler_id, worker_address
FROM sys.dm_os_tasks
WHERE session_id = <insert_session_id>
ORDER BY parent_task_address, scheduler_id;

Tips

Kolumnen parent_task_address är alltid NULL för den överordnade aktiviteten.

Tips

På en mycket upptagen SQL Server-databasmotor är det möjligt att se ett antal aktiva aktiviteter som överskrider gränsen som angetts av reserverade trådar. De här uppgifterna kan tillhöra en gren som inte längre används och är i ett övergående tillstånd och väntar på att rensas.

Här är resultatet. Observera att det finns 17 aktiva uppgifter för grenar som för närvarande körs: 16 underordnade uppgifter som motsvarar de reserverade trådarna, plus den överordnade eller samordnande uppgiften.

moderuppgiftsadress	uppgiftsadress	uppgiftsstatus	schemaläggar-id	arbetare_adress
NOLL	0x000001EF4758ACA8	AVSTÄNGD	3	0x000001EFE6CB6160
0x000001EF4758ACA8	0x000001EFE43F3468	AVSTÄNGD	0	0x000001EF6DB70160
0x000001EF4758ACA8	0x000001EEB243A4E8	AVSTÄNGD	0	0x000001EF6DB7A160
0x000001EF4758ACA8	0x000001EC86251468	AVSTÄNGD	5	0x000001EEC05E8160
0x000001EF4758ACA8	0x000001EFE3023468	AVSTÄNGD	5	0x000001EF6B46A160
0x000001EF4758ACA8	0x000001EFE3AF1468	AVSTÄNGD	6	0x000001EF6BD38160
0x000001EF4758ACA8	0x000001EFE4AFCCA8	AVSTÄNGD	6	0x000001EF6ACB4160
0x000001EF4758ACA8	0x000001EFDE043848	AVSTÄNGD	7	0x000001EEA18C2160
0x000001EF4758ACA8	0x000001EF69038108	AVSTÄNGD	7	0x000001EF6AEBA160
0x000001EF4758ACA8	0x000001EFCFDD8CA8	AVSTÄNGD	8	0x000001EFCB6F0160
0x000001EF4758ACA8	0x000001EFCFDD88C8	AVSTÄNGD	8	0x000001EF6DC46160
0x000001EF4758ACA8	0x000001EFBCC54108	AVSTÄNGD	9	0x000001EFCB886160
0x000001EF4758ACA8	0x000001EC86279468	AVSTÄNGD	9	0x000001EF6DE08160
0x000001EF4758ACA8	0x000001EFDE901848	AVSTÄNGD	10	0x000001EFF56E0160
0x000001EF4758ACA8	0x000001EF6DB32108	AVSTÄNGD	10	0x000001EFCC3D0160
0x000001EF4758ACA8	0x000001EC8628D468	AVSTÄNGD	11	0x000001EFBFA4A160
0x000001EF4758ACA8	0x000001EFBD3A1C28	AVSTÄNGD	11	0x000001EF6BD72160

Observera att var och en av de 16 underordnade aktiviteterna har en annan arbetstråd tilldelad (visas i kolumnen worker_address), men alla arbetare tilldelas till samma pool med åtta schemaläggare (0,5,6,7,8,9,10,11) och att den överordnade aktiviteten tilldelas till en schemaläggare utanför den här poolen (3).

Viktig

När den första uppsättningen parallella aktiviteter på en viss gren har schemalagts använder databasmotorn samma pool med schemaläggare för ytterligare aktiviteter på andra grenar. Det innebär att samma uppsättning schemaläggare kommer att användas för alla parallella uppgifter i hela exekveringsplanen, endast begränsat av MaxDOP.

SQL Server Database Engine försöker alltid tilldela scheduels från samma NUMA-nod för uppgiftsutförande och tilldela dem sekventiellt (i jämn fördelning) om scheduels är tillgängliga. Arbetstråden som tilldelats den överordnade aktiviteten kan dock placeras i en annan NUMA-nod än andra uppgifter.

En arbetstråd kan bara förbli aktiv i schemaläggaren under dess kvant (4 ms) och måste överlämna sin schemaläggare efter att kvantet har förflutit, så att en arbetstråd som tilldelats till en annan uppgift kan bli aktiv. När en arbetares kvant upphör att gälla och inte längre är aktiv placeras respektive uppgift i en FIFO-kö i ett RUNNABLE-tillstånd tills den flyttas till ett KÖRNINGstillstånd igen, förutsatt att aktiviteten inte kräver åtkomst till resurser som inte är tillgängliga för tillfället, till exempel en spärr eller ett lås, i vilket fall uppgiften skulle placeras i ett SUSPENDED-tillstånd i stället för RUNNABLE, tills dessa resurser är tillgängliga.

Tips

För utdata från DMV:en som visas ovan är alla aktiva aktiviteter i suspenderat tillstånd. Mer detaljerad information om väntande uppgifter finns tillgänglig genom att göra en förfrågan till sys.dm_os_waiting_tasks DMV.

Sammanfattningsvis skapar en parallell begäran flera uppgifter. Varje uppgift måste tilldelas till en enda arbetstråd. Varje arbetstråd måste tilldelas till en enda schemaläggare. Därför får antalet schemaläggare som används inte överskrida antalet parallella aktiviteter per gren, vilket anges av MaxDOP-konfigurationen eller frågetipset. Koordineringstråden bidrar inte till MaxDOP-gränsen.

Trådallokering till processorer

Som standard startar varje instans av SQL Server varje tråd, och operativsystemet distribuerar trådar från instanser av SQL Server mellan processorerna (PROCESSORer) på en dator baserat på belastning. Om processtillhörighet har aktiverats på operativsystemnivå tilldelar operativsystemet varje tråd till en specifik PROCESSOR. I motsats tilldelar SQL Server Database Engine SQL Server arbetstrådar till schemaläggare som distribuerar trådarna jämnt mellan processorerna, i ett roterande schema.

För att utföra multitasking, till exempel när flera program har åtkomst till samma uppsättning processorer, flyttar operativsystemet ibland arbetstrådar mellan olika processorer. Även om den är effektiv ur operativsystemssynpunkt kan den här aktiviteten minska SQL Server-prestanda under tunga systembelastningar, eftersom varje processorcache läses in upprepade gånger med data. Att tilldela processorer till specifika trådar kan förbättra prestanda under dessa förhållanden genom att eliminera processoromladdningar och minska trådmigreringen mellan processorer (vilket minskar kontextväxlingen). en sådan association mellan en tråd och en processor kallas processortillhörighet. Om tillhörighet har aktiverats tilldelar operativsystemet varje thread till en specifik processor.

Alternativet tillhörighetsmask anges med hjälp av ALTER SERVER CONFIGURATION. När tillhörighetsmasken inte har angetts allokerar instansen av SQL Server arbetstrådar jämnt bland de schemaläggare som inte har maskerats.

Försiktighet

Konfigurera inte CPU-tillhörighet i operativsystemet och konfigurera även tillhörighetsmasken i SQL Server. De här inställningarna försöker uppnå samma resultat, och om konfigurationerna är inkonsekventa kan du få oförutsägbara resultat. Mer information finns i tillhörighetsmaskalternativet .

Trådpooler hjälper till att optimera prestanda när ett stort antal klienter är anslutna till servern. Vanligtvis skapas en separat operativsystemtråd för varje frågebegäran. Men med hundratals anslutningar till servern kan en tråd per frågebegäran förbruka stora mängder systemresurser. Alternativet maximalt antal arbetstrådar gör det möjligt för SQL Server att skapa en pool med arbetstrådar för att betjäna ett större antal frågebegäranden, vilket förbättrar prestandan.

Använda alternativet för lättviktspoolning

Omkostnaderna för att växla trådkontexter kanske inte är särskilt stora. De flesta instanser av SQL Server ser inga prestandaskillnader mellan att ange enkel pool alternativet till 0 eller 1. De enda instanser av SQL Server som kan dra nytta av enkel pool är de som körs på en dator med följande egenskaper:

• En stor server med flera processorer
• Alla processorer körs nära maximal kapacitet
• Det finns en hög nivå av kontextväxling

Dessa system kan se en liten ökning i prestanda om värdet för lättviktspoolning är inställt på 1.

Viktig

Använd inte schemaläggning av fiberläge för rutindrift. Detta kan minska prestandan genom att hämma de regelbundna fördelarna med kontextväxling, och eftersom vissa komponenter i SQL Server inte kan fungera korrekt i fiberläge. Mer information finns i lättviktspooler.

Tråd- och fiberexekvering

Microsoft Windows använder ett numeriskt prioritetssystem som sträcker sig från 1 till 31 för att schemalägga trådar för att köras. Noll är reserverat för användning av operativsystem. När flera trådar väntar på att köras skickar Windows tråden med högsta prioritet.

Som standard är varje instans av SQL Server en prioritet på 7, vilket kallas för normal prioritet. Den här standardinställningen ger SQL Server-trådar en tillräckligt hög prioritet för att få tillräckligt med CPU-resurser utan att påverka andra program negativt.

Viktig

Den här funktionen tas bort i en framtida version av SQL Server. Undvik att använda den här funktionen i nytt utvecklingsarbete och planera att ändra program som för närvarande använder den här funktionen.

Konfigurationsalternativet prioritetsökning kan användas för att öka prioriteten för trådarna från en instans av SQL Server till 13. Detta kallas för hög prioritet. Den här inställningen ger SQL Server-trådar högre prioritet än de flesta andra program. SQL Server-trådar skickas därför vanligtvis när de är redo att köras och föregrips inte av trådar från andra program. Detta kan förbättra prestanda när en server bara kör instanser av SQL Server och inga andra program. Men om en minnesintensiv åtgärd inträffar i SQL Server kommer andra program sannolikt inte att ha en tillräckligt hög prioritet för att föregripa SQL Server-tråden.

Om du kör flera instanser av SQL Server på en dator och aktiverar prioritetsökning för endast några av instanserna kan prestandan för alla instanser som körs med normal prioritet påverkas negativt. Prestandan för andra program och komponenter på servern kan också minska om prioritetsökning är aktiverat. Därför bör den endast användas under strikt kontrollerade förhållanden.

Frekvent tillägg av CPU

Möjligheten att dynamiskt lägga till processorer i ett körande system. Att lägga till processorer kan ske fysiskt genom att lägga till ny maskinvara, logiskt genom partitionering av onlinemaskinvara eller praktiskt taget via ett virtualiseringslager. SQL Server har stöd för frekvent tillägg av CPU.

Krav för hot-add CPU:

• Kräver maskinvara som stöder frekvent tillägg av CPU.
• Kräver en version av Windows Server Datacenter eller Enterprise Edition som stöds. Från och med Windows Server 2012 stöds dynamisk tilläggning i Standardutgåvan.
• Kräver SQL Server Enterprise-utgåva.
• SQL Server kan inte konfigureras för att använda mjuk NUMA. Mer information om mjuk NUMA finns i Soft-NUMA (SQL Server).

SQL Server använder inte processorer automatiskt när de har lagts till. Detta hindrar SQL Server från att använda processorer som kan läggas till för något annat ändamål. När du har lagt till processorer kör du instruktionen RECONFIGURE så att SQL Server identifierar de nya processorerna som tillgängliga resurser.

Not

Om masken affinitet64 har konfigurerats måste masken affinity64 ändras för att använda de nya processorerna.

Metodtips för att köra SQL Server på datorer som har fler än 64 processorer

Tilldelning av maskinvarutrådar till processorer

Använd inte konfigurationsalternativen för tillhörighetsmask och tillhörighet64 maskserver för att binda processorer till specifika trådar. Dessa alternativ är begränsade till 64 processorer. Använd alternativet SET PROCESS AFFINITYALTER SERVER CONFIGURATION i stället.

Storlekshantering för transaktionsloggfil

Förlita dig inte på automatisk tillväxt för att öka storleken på transaktionsloggfilen. Att öka transaktionsloggen måste vara en seriell process. Om du utökar loggen kan du förhindra att transaktionsskrivningsåtgärder fortsätter tills loggtillägget är klart. I stället förallokerar du utrymme för loggfilerna genom att ange filstorleken till ett värde som är tillräckligt stort för att stödja den typiska arbetsbelastningen i miljön.

Ange maximal grad av parallellitet för indexåtgärder

Prestanda för indexåtgärder som att skapa eller återskapa index kan förbättras på datorer som har många processorer genom att tillfälligt ange databasens återställningsmodell till antingen den massloggade eller enkla återställningsmodellen. Dessa indexåtgärder kan generera betydande loggaktivitet och loggkonflikter kan påverka valet av den bästa graden av parallellitet (DOP) som SQL Server gör.

Förutom att justera maximal grad av parallellitet (MAXDOP) serverkonfigurationsalternativ kan du överväga att justera parallelliteten för indexåtgärder med hjälp av alternativet MAXDOP. Mer information finns i Konfigurera parallella indexåtgärder. Mer information och riktlinjer om hur du justerar konfigurationsalternativet för den maximala graden av parallellitetsserver finns i Konfigurera konfigurationsalternativet för maximal grad av parallellitetsserver.

Maximalt antal arbetstrådar alternativ

SQL Server konfigurerar dynamiskt alternativet för serverkonfigurationen maximalt antal arbetstrådar vid start. SQL Server använder antalet tillgängliga processorer och systemarkitekturen för att fastställa den här serverkonfigurationen under starten, med hjälp av en dokumenterad formel.

Det här alternativet är ett avancerat alternativ och bör endast ändras av en erfaren databasadministratör eller certifierad SQL Server-tekniker. Om du misstänker att det finns ett prestandaproblem, är det förmodligen inte tillgängligheten av arbetstrådar. Orsaken är mer sannolikt något såsom I/O som gör att arbetstrådarna väntar. Det är bäst att hitta den bakomliggande orsaken till ett prestandaproblem innan du ändrar inställningen för max arbetstrådar. Men om du behöver ange det maximala antalet arbetstrådar manuellt måste det här konfigurationsvärdet alltid anges till ett värde på minst sju gånger så många processorer som finns i systemet. Mer information finns i Konfigurera maximalt antal arbetstrådar.

Undvik användning av SQL Trace och SQL Server Profiler

Vi rekommenderar att du inte använder SQL Trace och SQL Profiler i en produktionsmiljö. Omkostnaderna för att köra dessa verktyg ökar också i takt med att antalet processorer ökar. Om du måste använda SQL Trace i en produktionsmiljö begränsar du antalet spårningshändelser till ett minimum. Profilera och testa varje spårningshändelse noggrant under belastning och undvik att använda kombinationer av händelser som avsevärt påverkar prestanda.

Viktig

SQL Trace och SQL Server Profiler är inaktuella. Microsoft.SqlServer.Management.Trace namnrymd som innehåller SQL Server Trace- och Replay-objekten är också inaktuella.

Den här funktionen tas bort i en framtida version av SQL Server. Undvik att använda den här funktionen i nytt utvecklingsarbete och planera att ändra program som för närvarande använder den här funktionen.

Använd utökade händelser i stället. Mer information om extended eventsfinns i Snabbstart: Utökade händelser i SQL Server och SSMS XEvent Profiler.

Not

SQL Server Profiler för Analysis Services-arbetsbelastningar är INTE inaktuella och kommer att fortsätta att stödjas.

Ange antalet tempdb datafiler

Antalet filer beror på antalet (logiska) processorer på datorn. Om antalet logiska processorer är mindre än eller lika med åtta använder du som allmän regel samma antal datafiler som logiska processorer. Om antalet logiska processorer är större än åtta använder du åtta datafiler och om konkurrensen fortsätter ökar du antalet datafiler med multiplar av 4 tills konkurrensen minskas till acceptabla nivåer eller gör ändringar i arbetsbelastningen/koden. Tänk också på andra rekommendationer för tempdb, som finns i Optimera tempdb-prestanda i SQL Server.

Men genom att noggrant överväga samtidighetsbehoven för tempdbkan du minska kostnaderna för databashantering. Om ett system till exempel har 64 processorer och vanligtvis bara 32 frågor använder tempdbförbättras inte prestanda genom att öka antalet tempdb filer till 64.

SQL Server-komponenter som kan använda fler än 64 processorer

I följande tabell visas SQL Server-komponenter och anger om de kan använda fler än 64 processorer.

Processnamn	Körbart program	Använda fler än 64 processorer
SQL Server Database Engine	Sqlserver.exe	Ja
Rapporteringstjänster	Rs.exe	Nej
Analysis Services	As.exe	Nej
Integrationstjänster	Is.exe	Nej
Serviceförmedlare	Sb.exe	Nej
Full-Text sökning	Fts.exe	Nej
SQL Server-Agent	Sqlagent.exe	Nej
SQL Server Management Studio	Ssms.exe	Nej
Konfiguration av SQL Server	Setup.exe	Nej