Förord

Innehåll

  » Checklista för prestandaanalys
  » De flesta konfigurationsinställningarna i SQL Server bör inte
  » Kom igång
  » Hur du gör ändringar i SQL Serverns konfigurationsinställninga
  » Affinity Mask
  » AWE enabled
  » Cost threshold for Parallelism
  » Cursor Threshold
  » Fill Factor (%)
  » Index Create Memory (kB)
  » Lightweight Pooling
  » Locks
  » Max Degree of Parallellism
  » Max Server Memory (MB) & Min Server Memory (MB)
  » Max Text Repl Size
  » Max Worker Threads
  » Min Memory Per Query
  » Nested Triggers
  » Network Packet Size (B)
  » Open Objects
  » Priority Boost
  » Query Governor Cost Limit
  » Query Wait (s)
  » Recovery Interval (min)
  » Scan for Startup Procs
  » Set Working set Size
  » User Connections
  » Och nu då?

Checklista för prestandan i SQL Serverns konfiguration

av Brad M. MacGee

Checklista för prestandaanalys

Skriv in dina resultat i tabellen ovan

De flesta konfigurationsinställningarna i SQL Server bör inte ändras

I den här artikeln ska vi titta på några prestandarelaterade konfigurationsinställningar i SQL Server. Det är specifika inställningar för SQL Server, som kan modifieras genom antingen Enterprise Manager eller sp_configure.

Som rubriken påvisar så bör du helst inte göra några ändringar i standardinställningarna i SQL Serverns konfiguration. Det beror på att de satta standardinställningarna ger optimal prestanda i de flesta SQL Servrarna. Och speciellt om du inte vet som händer när du gör ändringar i inställningarna. Det kan hända att du istället skadar prestandan istället för att förbättrar den.

När du har hand om en särskild SQL Server för första gången, så bör du se över de aktuella konfigurationsinställningarna och sedan jämföra de med standardinställningarna för att se om någon har ändrat på någon av dem. Om någon av inställningarna har förändrats, så är ditt nästa mål att ta reda på varför man har gjort de ändringarna. Om du inte får reda på varför, eller om anledningarna verkar konstiga, så bör du ändra dem tillbaka till standardvärdena. Nästa steg är att se över alla inställningar som redan var satta till sina standardvärden när du började, och se om du kan få ut någonting bättre genom att ändra från standardvärdena till andra, kanske lämpligare värden.

Den här artikeln behandlar SQL Server 2000, även fast en del förslag kan genomföras på SQL Server 7.0. Men innan du försöker dig på några av förslagen i SQL Server 7.0 så bör du titta igenom avsnittet om konfigurationsinställningar i SQL Server 7.0 Book Online, bara för att vara säker.

Det finns 36 olika konfigurationsinställningar i SQL Server 2000, men vi ska bara fokusera oss på de 23 prestandarelaterade inställningarna här.

Kom igång

Det lättaste sättet att påbörja en analys av konfigurationsinställningarna är genom att på varje Server köra följande kommando i Query Analyzer:

sp_configure

Det kommer att generera följande tabell:



Den första kolumnen ”name” är namnet på SQL Serverns konfigurationsinställning. Den andra kolumnen ”minimum” är det minsta giltiga värdet på inställningen. Den tredje kolumnen ”maximum” är det högsta giltiga värdet för inställningen. Den fjärde kolumnen ”config_value” är det aktuella värdet på inställningen (men behöver inte vara just det, eftersom inställningen inte aktiveras förrän SQL Server har startats om, eller tills man har kört RECONFIGURE WITH OVERRIDE, som sig bör). Och den sista kolumnen ”run_value” är det värdet som SQL Server kör under för tillfället. Om du inte har gjort några ändringar i dem inställningarna sen du sist startade om SQL Server, så kommer värdena i de sista två kolumnerna alltid att vara desamma.

Tyvärr så listas inte standardvärdena när du kör sp_configure. För din bekvämlighets skull så kommer den här artikeln att lista alla standardvärden för de konfigurationsinställningar som vi diskuterar här (se tabellen ovan).

Hur du gör ändringar i SQL Serverns konfigurationsinställningar

Du kan oftast, men inte alltid, ändra SQL Serverns konfigurationsinställningar med hjälp av Enterprise Manager. Annars så är det enklaste sättet att ändra någon inställning på genom att köra sp_configure kommandot, så här:

sp_configure ['configuration name'], [configuration setting value]
GO
RECONFIGURE WITH OVERRIDE
GO

där:

configuration name: Namnet på konfigurationsinställningen (se namnen i tabellen ovan). Notera att namnet måste omfattas av enkla citationstecken (eller dubbla citationstecken, beroende på Query Analyzerns konfiguration).

configuration setting value: Det numeriska värdet på inställningen (inga citationstecken).

När du väl har kört sp_configure, så måste du gå igenom ytterligare ett steg. Du måste antingen köra RECONFIGURE (normala inställningar) eller RECONFIGURE WITH OVERRIDE (används för inställningar där ett misstag kan orsaka problem), annars kommer inte din nya inställning att aktiveras. Istället för att försöka komma ihåg när du ska använda vilket RECONFIGURE kommando, så är det lättare att alltid köra RECONFIGURE WITH OVERRIDE, eftersom den fungerar för alla inställningar. Om du använder Enterprise Manager för att göra ändringar, så kör den automatiskt RECONFIGURE WITH OVERRIDE, så då behöver inte du göra det.

När du har gjort det så brukar de flesta, men inte alla, inställningar aktiveras med en gång. För de inställningar som inte aktiveras omedelbart efter RECONFIGURE, så måste SQL Server tjänsten stoppas och sedan startas om. I tabellen ovan så kan du se vilka prestandarelaterade inställningar som kräver att tjänsten startas om efter ändringar.

Innan vi är färdiga med det här avsnittet så är det en sak till du bör veta. Några av de här inställningarna anses vara Avancerade inställningar. Innan du kan göra några ändringar i de inställningarna med sp_configure, så måste du först ändra i en annan SQL Server konfigurationsinställning, vilken tillåter dig att ändra de Avancerade inställningarna. Kommandot för det är:

sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO

Endast efter att ha kört ovanstående kommando så kan du ändra en Avancerad SQL Server konfiguration. Tabellen ovan visar dig vilka av de prestandarelaterade inställningarna som är Avancerade.

Nu när du vet hur du ändrar en SQL Server inställning, så ska vi ta en titt på de inställningarna som har med prestanda att göra.

Affinity Mask

När en SQL Server körs under Windows NT 4.0 eller Windows 2000, så kan en SQL Server tråd (thread) flyttas från en CPU till en annan. Den funktionen låter SQL Server att köra flera trådar på samma gång, vilket resulterar i en bättre balanserad last mellan SQL Serverns CPUn. Det enda negativa med den här funktionen är att varje gång som en tråd flyttas från en CPU till en annan, så måste processorns Cache laddas om, vilket i vissa fall kan skada prestandan.

På vissa Servrar som är högt belastade, och som har fler än 4 CPUn, så kan man ange (till en viss begränsning) vilken (eller vilka) processor(er) som ska köra en specifik processtråd. På så sätt behöver inte processorns Cache laddas om lika mycket och dessutom hjälper det till att få ut så mycket prestanda som möjligt från Servern. Du kan t ex specificera att SQL Server bara ska köras på en del av de tillgängliga CPUn i Servern.

Standardvärdet för inställningen ”Affinity Mask” är ”0”, och det säger åt SQL Servern att tillåta Windows Scheduling-algoritmen till att bestämma en tråds förbindelse. Med andra ord så blir det operativsystemet, och inte SQL Servern, som bestämmer vilken tråd som ska köras på vilken CPU, och när en tråd ska flyttas från en CPU till en annan. I en Server med 4 eller färre CPUn, så är det standardinställningen som är det bästa valet. Samma sak gäller för en Server som har flera än 4 CPUn men som inte är enormt sysselsatt – standardinställningen är den inställning som ger optimal prestanda.

Men för Servrar som har fler än 4 CPUn, och som är högt belastade på grund av att det är fler applikationer än SQL Server som körs på samma Server, så bör du ändra inställningen för ”Affinity Mask” till ett lämpligare värde. Var vänlig att notera; om du använder ”Affinity Mask” för att begränsa CPU användningen på en Server där SQL Server är den enda applikationen som körs, så kan du skada prestandan istället för att hjälpa den.

Låt oss t ex säga att du har en Server som kör SQL Server, flera COM+ objekt samt IIS. Låt oss också säga att Servern har 8 CPUn, och är väldigt sysselsatt. Genom att reducera antalet CPUn som kan köra SQL Server från 8 till 4, så kommer SQL Serverns trådar bara att köra på 4 CPUn istället för 8. Genom att göra det så reducerar du det antalet gånger som SQL Serverns trådar måste byta CPU, vilket i sin tur reducerar det antalet gånger som processorns Cache måste laddas om, samt minskar arbetslasten för CPUn och höjer prestandan. De resterande 4 CPUn kommer då att köra de applikationer som inte är SQL Serverbaserade, samt hjälpa dem att minimera alla trådars förflyttningar och höja prestandan.

Om du t ex har ett system med 8 CPUn så bör du använda ett värde i kommandot sp_configure, för att välja vilka CPUn som SQL Server enbart ska köra på. Värdena ser du nedan i listan:



Att specificera en lämplig Affinity Mask är inget lätt jobb, och innan du utför det så bör du konsultera SQL Server Books Online för vidare information. Du bör också testa och se hur din SQL Servers prestanda mår både före och efter att du har gjort några förändringar, för att se om dina nya värden har hjälpt eller stjälpt prestandan. För att finna det optimala värdet på Affinity Mask på just din Server, så finns det inget enklare sätt än att använda ”Trial and Error” metoden.

Som en del i din analysering ingår det att om du upptäcker att Affinity Mask används, ta reda på varför det används. Om du inte får ett acceptabelt svar så bör du ta bort det, och återgå till standardvärdena.

AWE enabled

Om du kör SQL Server 2000 Standard Edition under Windows NT 4.0 eller vilken Windows 2000 version som helst; eller om du kör SQL Server 2000 Enterprise Edition under Windows NT 4.0 eller Windows 2000 Server; eller om du har mindre än 4 GB RAM i din Server; så ska ”AWE enabled” alternativet alltid stå på standardvärdet ”0” – vilket innebär att AWE minnet inte används.

AWE API (Advanced Windowing Extensions API) tillåter applikationer (som är skrivna för att använda AWE API) att köra under Windows 2000 Advanced Server eller Datacenter Server, för att kunna accessa mer än 4 GB i RAM. SQL Server 2000 Enterprise Edition (inte Standard Edition) är AWE-enabled och kan utnyttja de RAM i en Server som överstiger 4 GB. Då operativsystemet Windows 2000 Advanced Server körs så kan SQL Server Enterprise Edition använda upp till 8 GB RAM, och då Windows 2000 Datacenter Server körs så kan SQL Server 2000 Enterprise Edition använda upp till 64 GB RAM.

Om en fysisk Server har mer än 4 GB RAM, kör Windows 2000 (Advanced eller Datacenter Server) tillsammans med SQL Server 2000 Enterprise Edition, så är det som standard att inte Servern kan komma åt mer än 4 GB RAM. För att operativsystemet och SQL Server 2000 Enterprise Edition ska kunna dra fördel av det extra RAM som finns, så måste två steg genomföras.

Hur du exakt konfigurerar stödet för AWE minne beror på hur mycket RAM din Server redan har. När du konfigurerar Windows 2000 (Advanced eller Datacenter) så måste du i alla fall skriva in någon av följande växlar på boot-raden i boot.ini-filen och sedan starta om Servern:

• 4 GB RAM: /3GB (AWE stödet används inte)
  
• 8 GB RAM: /3GB /PAE
  
• 16 GB RAM: /3GB /PAE
  
• 16 GB+ RAM: /PAE
  

Växeln ’/3GB’ används till att tala om för SQL Server att den ska utnyttja 3 GB av de 4 GB som Windows 2000 normalt stöder. Om du inte anger det här alternativet, så kommer SQL Server bara att dra fördel av de första 2 GB av de 4 GB i Servern, och praktiskt taget slösa bort 1 GB RAM.

Teknologin AWE Memory används endast till de RAM som överskrider de vanliga 4 GB, det är därför som växeln ’/3GB’ behövs för att kunna använda så mycket av RAM minnet i din Server som möjligt. Om din Server har 16 GB RAM eller mindre så är den växeln viktig, men om din Server har mer än 16 GB RAM så får du inte använda växeln alls. Därför att de extra 1 GB som ges när du använder växeln, behövs till operativsystemet för att kunna dra fördel av allt extra AWE minne. Med andra ord så behöver operativsystemet själv 2 GB RAM för att kunna hantera AWE minnet, då du har 16 GB RAM eller mer i din Server. Om Servern har 16 GB RAM eller mindre, så behöver operativsystemet bara 1 GB RAM, och de extra 1 GB RAM kan då användas till SQL Server.

När du har utfört det här steget så är nästa steg att sätta alternativet ”AWE enabled” till ”1”, och sen starta om SQL Server tjänsten. Endast då kan SQL Server börja dra fördel av det extra RAM minnet som finns i din Server.

Du bör vara försiktig när du använder ”AWE enabled”, för efter att du har aktiverat det så hanterar inte längre SQL Server dynamiskt minne. Istället använder den allt RAM minne den kan komma åt (förutom de 128 MB som behövs för operativsystemet). Om du inte vill att SQL Server ska använda allt RAM minne den kommer åt, så kan du begränsa RAM minnet genom att specificera ett lämpligare värde i inställningen ”Max Server Memory” (förklaras i detalj senare i artikeln).

Som en del av din analyseringsprocess så bör du kontrollera värdet i ”Max Server Memory” och se om det matchar din Servers konfiguration. Om det inte gör det så gör du de lämpliga ändringarna.

Cost threshold for Parallelism

Att använda parallellism när du exekverar en SQL Server Query har sina kostnader. Det beror på att det krävs lite mer arbetslast när du kör en Query parallellt (pga flera CPUn) än vad det gör om du kör den seriellt. Men om fördelarna med att köra satsen parallellt väger över kostnaden, så är det bra att köra den parallellt.

En tumregel är att om din Query körs seriellt och går väldigt snabbt, så är det ingen idé att ens fundera på parallellism. Det beror på att det kräver mer tid att undersöka satsen för eventuell parallellism än vad det skulle ta köra en seriell sats.

Som standard är det så att Query Analyzer avgör om satsen tar mindre än 5 sekunder att exekvera, och i så fall är det ingen idé för SQL Server att använda parallellism för den satsen. Den 5-sekundersgränsen kan dock ändras under SQL Server inställningen ”Cost Threshold for Parallellism” till något värde mellan 0-32767 sekunder. Så om du sätter värdet till t ex 10 sekunder så är det ingen idé att använda parallellism på en sats som tar mindre än 10 sekunder att exekveras.

Oftast så bör du inte ändra den här inställningen. Men om du upptäcker att det är många SQL Server satser som använder parallellism och om CPU lasten är väldigt hög, så kan du ändra den här siffran till ett högre värde (du kommer att få experimentera för att få fram ditt optimala värde). På så sätt reducerar du antalet satser som använder parallellism samt reducerar behovet från CPU användningen, vilket i sin tur kan höja Serverns prestanda.

Ett annat alternativ att tänka på kan vara att reducera värdet från 5 sekunder till något lägre värde, trots att det i de flesta fall kan skada hellre än hjälpa prestandan. Om din SQL Server fungerar som ett datalager där många väldigt komplicerade satser körs, så kan det vara användbart med ett lägre värde. Ett lägre värde tillåter Query Analyzer att köra flera satser som använder parallellism, vilket i vissa situationer kan hjälpa en hel del.

Du bör testa alla ändringar från standardvärdet noggrant, innan du implementerar det på någon produktionsserver.

Om din SQL Server bara har access till en enda CPU (antingen för att du bara har en enda CPU, eller för att du har gjort den inställningen under ”Affinity Mask”), så är parallellism ingenting att tänka på för dina satser.

Om du i din analys upptäcker att ”Cost threshold for Parallellism” används, försök då att ta reda på varför. Om du inte kan få något svar, ändra då tillbaka till standardvärdet.

Cursor Threshold

Om din SQL Server inte använder pekare, eller om den gör det väldigt lite, så bör inte den här inställningen ändras från sitt standardvärde ”-1”.

Inställningen ”-1” under ”Cursor Threshold” talar om för SQL Server att exekvera alla pekare synkront, vilket är den ideala inställningen då det inte finns så många pekare att exekvera på din Server. Men om många, eller alla, av SQL Serverns pekare producerar stora returnerade set, så är inte en synkron exekvering av pekarna det effektivaste sättet att exekvera dem på.

Inställningen ”Cursor Threshold” har förutom standardalternativet, två ytterligare alternativ då man kör stora pekare. Inställningen ”0” talar om för SQL Servern att köra pekarna asynkront, vilket är mer effektivt då de flesta, eller alla, pekare returnerar stora resulterande set.

Men vad ska du göra om några pekare returnerar stora paket, och andra returnerar små paket? I det här fallet så kan du avgöra vad som är litet och vad som är stort, och sedan använda det värdet som gränsvärde för SQL Server. Låt oss t ex säga att vi anser att returnerande set under 1000 poster är lite, och set över 1000 poster är mycket. Då kan du sätta SQL Servern ”Cursor Threshold” till 1000.

Om du har satt ”Cursor Threshold” till 1000, så innebär det att Query Analyzer kommer att förutse huruvida de returnerande seten kommer att bestå av fler eller färre än 1000 poster. Om den förutser att setet kommer att bestå av färre än 1000 poster så kommer pekaren att köras synkront, och om setet kommer att bestå av fler än 1000 poster så kommer pekaren att köras asynkront.

På många sätt så kan den här inställningen ge det bästa för båda parterna. Det enda problemet är att bestämma det optimala värdet för ”Cursor Threshold”, och det bästa sättet för att få reda på vilket värde du bör ha är genom att testa sig fram. Men som du kanske kan förstå så är standardvärdet ofta det bästa värdet. Du bör endast göra ändringar om du vet att en applikation ofta använder pekare, och då du har testat och sett att ändringarna kan hjälpa prestandan istället för att skada den.

Som en del av din analys så måste du alltså ta reda på hur ofta pekare används, samt ta reda på hur stora de resulterande seten blir. Du kan bara veta vilken inställning som är bäst för din Server genom att ta reda på det. Du kan självklart eliminera användandet av pekare helt på din Server. På så sätt kan inställningen stå kvar på standardvärdet, och då behöver du inte oroa dig över någon extra arbetslast som blir av att använda pekare.

Fill Factor (%)

Det här alternativet låter dig ange en standard fyllfaktor för ett Index när det skapas. Som standard så är det ”0”, vilket kan vara förvillande eftersom det innebär att (leaf) Indexsidor fylls till 100 % (inte 0 %), medan de mellanliggande (icke-leaf) Indexsidorna har lite plats kvar (de fylls inte riktigt till 100 %). Fyllfaktorn kan ha värden från 0 till 100.

Standardvärdet för fyllfaktorn är bara relevant då du har skapat en ny Indexsida utan att ange ett specifikt värde för fyllfaktorn. Om du anger ett specifikt värde för fyllfaktorn då du skapar en ny Indexsida, så används det värdet i stället för standardvärdet.

I de flesta fall så är det bäst att låta standardvärdet kvarstå, men om du verkligen vill ha en annan fyllfaktor så anger du det specifika värdet när du skapar ett nytt Index.

Som en del av din analys så måste du ta reda på om värdet för fyllfaktorn är något annat än ”0”. Om det inte är ”0” så måste du försöka ta reda på varför. Och om du inte kan få reda på varför man har ändrat, eller om svaret inte är tillfredsställande nog, så bör du ändra tillbaka. Kom också ihåg att om värdet har ändrats, så kan alla Indexsidor som har skapats efter ändringen också använda det nya värdet som standardvärde. Om det är så, så måste du omvärdera de Indexen och se ifall fyllfaktorn som de skapades under är den lämpliga.

Index Create Memory (kB)

Inställningen “Index Create Memory” bestämmer hur mycket minne som kan användas av SQL Server då man skapar Index. Standardvärdet ”0” talar om för SQL Server att automatiskt bestämma det ideala värdet. I de flesta fall så klarar SQL Server av att konfigurera den optimala mängden minne.

Men i vissa ovanliga fall, speciellt vid väldigt stora tabeller, så kan det hända att SQL Server gör ett misstag och gör att stora Index skapas väldigt långsamt, eller inte alls. Om du stöter på en sådan situation så bör du ställa in värdet manuellt. Du kommer säkerligen att misslyckas några gånger tills du finner det optimala värdet för just dig. De giltiga värdena för den här inställningen är från 704-2147483647. Siffrorna refererar till mängden RAM i kB som SQL Server kan använda för att skapa Index.

Kom ihåg att om du ändrar den här inställningen, så kommer det minne som du tilldelar skapandet av Index inte finnas tillgängligt för andra användningsområden. Om din Server har tillräckligt med RAM minne så är det inga problem. Men om din Server inte har så mycket RAM minne, så kan en ändring av den här inställningen ha en negativ effekt på prestandan ur flera aspekter i din SQL Server. Du bör endast göra ändringar då du ska skapa eller bygga om stora Index, och ändra tillbaka vid alla andra tillfällen.

Precis som med alla andra inställningar så måste du kontrollera ifall det är standardvärdet som står eller inte. Om det inte är standardvärdet så måste du försöka ta reda på varför man har gjort några ändringar. Om du inte kan få något svar, eller om det inte fanns någon rimlig anledning till att ändra, så bör du ändra tillbaka till standarden.

Lightweight Pooling

Som standard så kör SQL Server 7.0 och 2000 under ett så kallat “thread mode”. Det innebär att SQL Server använder så kallade UMS threads (User Mode Schedulers) för att köra användarprocesser. SQL Server skapar en UMS tråd för varje processor, där var och en av dem turas om med att köra alla användarprocesser som finns att finna på en sysselsatt SQL Server. För att få optimal effektivitet så försöker UMS att balansera alla användarprocesser som körs på varje tråd, för att på så sätt hålla en jämn balans av användarprocesser över alla CPUn i Servern.

SQL Server kan också köras under det som kallas ”fiber mode”. I det här fallet så kör SQL Server en tråd per processor (ungefär som Thread Mode), fast med den skillnaden att ett flertal fibrer körs inom varje tråd. Fibrer används för att anta den identitet på tråden som den exekverar, och den blockerar inte några andra SQL Server trådar som körs på Servern. Se fiber som en ”lättviktig tråd” som under vissa omständigheter kräver mindre arbetslast än vad de vanliga UMS trådarna hanteras med. Fibermetoden sätts på och stängs av genom att använda SQL Serverns konfigurationsinställning ”Lightweight Pooling”. Standardvärdet är ”0”, vilket innebär att Fiber Mode är avstängt.

Så vad menas med allt det här? Precis som allt annat så finns det vissa för- och nackdelar med att använda den ena metoden istället för den andra. Generellt sett så är det bara gynnsamt att använda Fiber Mode under följande förutsättningar:

• Då det finns två eller flera CPUn på Servern (ju fler CPUn, desto mer lönsamt blir det).
  
• Då alla CPUn arbetar nära max (95-100 %) mestadels av tiden.
  
• Då det sker väldigt mycket ”Context Switching” på Servern (du kan se hur mycket det sker genom att titta på Performance Monitor Countern System Object: Context Switching/Sec). Generellt sett så anses 5 000 Context Switchings per sekund vara väldigt högt.
  
• Då Servern mycket sällan, eller aldrig, använder sig utav någon av de distribuerade satserna eller av de utökade lagrade procedurerna.
  

Om alla ovanstående villkor är uppfyllda, så kan du aktivera ”Lightweight Pooling” i din SQL Server. Och när du gör det så kan du märka av en 5 % eller högre förbättring av prestandan.

Men om inte alla fyra villkoren är uppfyllda, så kan du faktiskt skada prestandan genom att aktivera ”Lighweight Pooling”. Om din SQL Server t ex använder många av de distibuerade satserna eller utökade lagrade procedurerna, så kan du definitivt skada prestandan om du aktiverar ”Lighweight Pooling”. Det beror på att satserna och procedurerna inte kan använda sig av Fibermetoden, och då kommer SQL Servern vid behov att hoppa fram och tillbaka från Thread Mode till Fiber Mode, och det är inte alls bra för prestandan.

Precis som med alla andra inställningar så måste du kontrollera ifall det är standardvärdet som står eller inte. Om det inte är standardvärdet så måste du försöka ta reda på varför man har gjort några ändringar. Du bör dessutom se ifall de ovanstående fyra villkoren råkar vara uppfyllda, i så fall kan det vara bra att aktivera ”Lighweight pooling”. Om inte villkoren är uppfyllda så ska standardvärdet stå kvar på ”0”.

Locks

Varje gång som SQL Server låser ett record, så måste den låsningen lagras i minnet. Standardvärdet är ”0”, vilket innebär att låsningen hanteras dynamiskt av SQL Servern. Internt så kan SQL Servern reservera 2-40 % av ledigt utrymme för låsning. Men om SQL Server märker att allokering av extra minne för låsning kan skapa paging på operativsystemets nivå, så kommer den inte att allokera minnet för låsning. Istället så låter den operativsystemet få det extra minnet för att kunna förhindra paging.

I de flesta fall bör du låta SQL Server hantera låsningen dynamiskt genom att låta standardvärdet stå kvar. Om du skriver in ett eget värde för minneslåsning (giltiga värden är från 5000 till 2147483647 kB) så kan inte längre SQL Servern hantera detta dynamiskt, och i vissa fall kan det sänka SQL Serverns prestandan.

Om du skulle få ett Errormeddelande där det står att du har överskridit det maximala antalet tillgängliga låsningar, så har du följande metoder att tillgå:

• Undersök dina satser noggrant för att se om det är de som orsakar dessa överdrivna låsningar. Om det är dem så är det också möjligt att prestandan tar skada på grund av konflikter i applikationerna. Det är bättre att fixa dåliga satser än att allokera minne för att leta upp låsningar.
  
• Reducera antalet applikationer som är uppe och kör på Servern.
  
• Lägg till extra RAM till Servern.
  
• Höj antalet tillåtna låsningar (basera dina siffror på tester). Det här är det alternativet som du helst inte vill behöva använda, eftersom du genom att du tilldelar extra minne till låsningen, så förhindrar du det minnet att kunna användas av SQL Server till fördelaktiga syften.
  

Gör ditt bästa för att motstå användningen av denna inställning. Om du i din analys upptäcker att det har gjorts ändringar från standardvärdet, så försök ta reda på varför. Om du inte kan få reda på varför, eller om det inte fanns någon rimlig anledningar, så bör du ändra tillbaka.

Max Degree of Parallellism

Det här alternativet låter dig specificera om parallellism ska vara aktiverat, avaktiverat, eller bara aktiverat för vissa (inte alla) CPUn på din Server. Parallellism refererar till Query Analyzerns förmåga att använda fler än en CPU för att exekvera en sats. Parallellism är som standard aktiverad och kan använda så många CPUn som finns i Servern (om inte antalet har reducerats med ”Affinit Mask”). Men om din Server bara har en CPU så ignoreras inställningen i ”Max Degree of Parallellism”.

Standardvärdet är ”0”, vilket innebär att parallellism är aktiverad för alla tillgängliga CPUn på Servern. Om du ändrar inställningen till ”1” så stänger du av parallellismen för alla tillgängliga CPUn. Inställningen låter dig specificera hur många CPUn du vill ska använda parallellism. Om du t ex har en Server med 8 CPUn, men du vill bara använda parallellism på 4 av dem, så kan du ange värdet 4 för den här inställningen. Men bara för att möjligheten finns så är det tveksamt att det medför några fördelar för prestandan genom att utnyttja den.

Om parallellism är aktiverad, vilket den är som standard om du har flera CPUn, så kommer Query Optimizer att analysera alla satser för att se om det är möjligt att använda parallellism, och det kräver en del arbetslast för Servern. På många OLTP Servrar, så ligger det inte i satsernas natur att behöva någon parallellism för att köra dem. Exempel på det är standarduttrycken SELECT, INSERT, UPDATE och DELETE. På grund av det så slösar Query Optimizer tid på att analysera varje SQL-sats för att se om dem kan dra fördel av parallellism. Så om du vet att dina satser förmodligen aldrig kommer att dra fördel av parallellism, så kan du spara in lite arbetslast genom att stänga av den funktionen så att inte satserna ska analyseras för detta.

Sen om dina SQL Server satser kan dra fördel av parallellism, så bör du självklart inte stänga av funktionen. Om du t ex har en OLTP applikation som kör många relaterade satser, eller andra komplicerade satser, så bör du ha funktionen aktiverad. Du bör testa den här inställningen och se huruvida en ändring kan hjälpa eller stjälpa din SQL Server prestanda i just din unika arbetsmiljö.

I de flesta fall, där du kör både OLAP och OLTP satser, så bör den här funktionen vara på. Som en del i din prestandaanalys så bör du se efter om funktionen är avaktiverad eller begränsad, och sen försöka ta reda på varför den är det. Du bör också ta reda på om Servern är virtuellt OLTP-inriktad. Om den är det så kan det vara bra att stänga av funktionen. Fast innan du gör det så bör du göra noggranna tester för att se hur det påverkar SQL Serverns prestanda. Men om Servern kör både OLAP och OLTP, eller mest OLAP satser, så kan det vara bäst för prestandan om parallellism är aktiverad.

Max Server Memory (MB) & Min Server Memory (MB)

För bäst SQL Server prestanda så bör du hänge din Server till att endast köra SQL Server, inga andra applikationer. I de flesta fall bör inställningarna för ”Maximum Server Memory ” och ”Minimum Server Memory” förbli på standardvärdena. Det beror på att standardvärdet låter din SQL Server allokera Serverns minne dynamiskt, vilket ger den optimala prestandan. Om du ”hårdkodar” minimum och maximum värdet för minnet, så riskerar du att skada din SQL Servers prestanda.

Om SQL Server däremot inte kan få köras på en egen fysisk Server (andra applikationer körs på samma fysiska Server som SQL Server), så kan du överväga att ändra något av minimum eller maximum värdena, trots att det inte krävs.

Låt oss titta på båda inställningarna:

När inställningen ”Maximum Server Memory” är satt till standardvärdet av 2147483647 (MB), så låter den SQL Server hantera användningen av minnet dynamiskt, och om den behöver så har den tillgång till allt RAM minne som är tillgängligt (förutom en del som går till operativssystemet).

Men om du inte vill att SQL Server ska använda allt tillgängligt RAM minne i Servern så kan du manuellt specificera hur mycket RAM SQL Server få använda maximalt. Du kan skriva värden mellan 4 (det lägsta tillåtna värdet) och den maximala mängden RAM som du har i Servern (men allokera inte allt, operativsystemet behöver minne också).

När ”Max Server Memory” är satt till sitt standardvärde, så justeras som sagt minneshanteringen dynamiskt. Men det innebär också att om du kör fler applikationer än SQL Server på en fysisk Server, så kommer SQL Server att ”vara sjysst” och ge upp en del minne ifall de andra applikationerna behöver det. Så oftast finns det ingen anledning att ändra från standardvärdet. Bara i vissa ovanliga situationer där SQL Server inte verkar ”vara sjysst”, eller om du vill se till att inte SQL Server har tillgång till allt RAM minne själv, då kan du ändra värde i inställningen. Om t ex dina ”andra” applikationer är viktigare än SQL Serverns prestanda, då kan du minska ner på SQL Serverns prestanda om du vill.

Det finns alltså två olika prestandafrågor som skapas då du försöker ändra värdet ”Max Server Memory” manuellt. För det första; om du allokerar för mycket minne till SQL Server och inte lämnar någonting till operativsystemet, så har inte operativsystemet något annat val än att börja med överdriven paging, vilket gör Serverns prestanda slö. För det andra; om du kör med Full-Text Search Service så måste du lämna tillräckligt minne till dess funktion. Dess minne allokeras nämligen inte dynamiskt som med resten av SQL Serverns minne, så det måste finnas tillräckligt med minne för att den ska kunna köra ordentligt.

När inställningen ”Minimum Server Memory” är satt till standardvärdet ”0” (MB), så talar det om för SQL Server att hantera minnesanvändningen dynamiskt. Det innebär att SQL Servern börjar allokera minne när det behövs, och hur mycket RAM minne som används beror på SQL Serverns behov.

Om du ändrar värdet i ”Min Server Memory” till någonting annat än standardvärdet ”0”, så tror många att SQL Server automatiskt kommer att börja använda den mängden minne. Utan när minimängden minne är nådd (därför att det behövs) så kommer den aldrig att gå under den specificerade minimängden RAM.

Så om du t ex specificerar minimängden RAM till 100 MB och sen startar om SQL Server, så kommer inte SQL Server att omedelbart reservera dessa 100 MB RAM som sin minimala användning. Utan SQL Server kommer bara att ta så mycket den behöver. Om den aldrig kommer att behöva 100 MB så kommer det aldrig att reserveras. Men om SQL Server överskrider de angivna 100 MB och sen inte behöver de längre, så kommer de här 100 MB bli den nedre gränsen för hur mycket minne SQL Server allokerar. På grund av det här så finns det egentligen ingen anledning att ändra från standardvärdet i ”Min Server Memory”.

Om din fysiska Server endast kör SQL Server, så finns det ingen anledning alls att ändra i denna inställning. Men om du kör flera applikationer på samma Server, så kan det dra med sig en viss fördel att ändra till ett minimivärde. Men det kan vara mycket svårt att veta vilket värde du ska sätta, och prestandavinsten kan vara marginell.

Om du i din analys upptäcker att värdet i denna inställning är ändrat, försök då ta reda på varför. Om du inte kan få reda på varför, eller om det inte verkade finnas någon egentlig anledning, så bör du ändra tillbaka till standardvärdet.

Max Text Repl Size

Inställningen “Max Text Repl Size” låter dig specificera den maximala storleken på text- eller bilddata, som du kan lägga in i en replikerad fysisk kolumn med hjälp av en enkel fysisk INSERT-, UPDATE-, WRITETEXT- eller UPDATETEXT-transaktion. Om du inte använder dig av replikering, eller om du inte replikerar några text- eller bilddata, så bör du inte göra någon ändring i den här inställningen.

Standardvärdet är ”65536”, det minsta värdet är ”0”, och det maximala värdet är ”2147483647” (i bytes). Om du kör tunga replikeringar av dina text- eller bilddata, så bör du bara ändra från standardvärdet om storleken på dessa data överskrider 64 kB. Men som med de flesta inställningar så får du pröva dig fram för att se vad som är bäst under just dina omständigheter.

Som en del i din analys så måste du se huruvida replikering används eller inte, och om det inte gör det så är det enda rätta värdet standardvärdet. Om värdet däremot har ändrats, så måste du ta reda på ifall text- eller bilddata replikeras. Om det inte gör det, eller om dess data underskrider 64 kB, så bör du ändra tillbaka till standardvärdet.

Max Worker Threads

SQL Serverns konfigurationsinställning “Max Worker Threads” används för att avgöra hur många Worker Threads som görs tillgängliga för sqlservr.exe-processen från operativsystemet. Inställningens standardvärde är 255 Worker Threads. SQL Server använder några av trådarna själv också, men det ska vi inte gå in på här. Fokusen här ligger de trådar som skapas till fördel för användarna.

Om det finns fler än 255 användaranslutningar så kommer SQL Server att använda sig av Thread pooling, där fler än en användaranslutning delar på en ensam Worker Thread. Trots att Thread Pooling kan reducera mängden systemresurser som SQL Server använder så kan det skapa stockningar för de användaranslutningar som vill accessa SQL Servern, vilket skadar prestandan.

Om du vill se hur många Worker Threads din SQL Server använder, så kan du med hjälp av Enterprise Manager se hur många anslutningar som för tillfället är uppe mot din Server. För varje SQL Server anslutning så skapas det en Worker Thread upp till det antalet som är specificerat i inställningen ”Max Worker Threads”. Så om det är 100 användaranslutningar mot din SQL Server så bör det finnas 100 Worker Threads uppsatta. Men om det är 500 anslutningar och bara 255 Worker Threads tillgängliga, så kommer det bara att användas 255 Worker Threads där alla anslutningar delar på de tillgängliga trådarna.

Förutsatt att det finns tillräckligt med RAM i din Server så bör du för optimal prestanda sätta antalet ”Max Worker Threads” till det maximala antal användaranslutningar som din Server upplever, plus 5. Men som du snart kommer att få se så måste den här generelle rekommendationen begränsas lite.

Vi har redan nämnt att standardvärdet för ”Max Worker Threads” är 255. Om din Server aldrig kommer upp i 255 anslutningar så behöver du inte ändra från standardvärdet, eftersom antalet Worker Threads bara skapas då de behövs. Om det bara finns 50 anslutningar mot Servern så kommer det bara att skapas 50 Worker Threads, inte 255 (standardvärdet).

Om du generellt sett har fler än 255 användaranslutningar mot Servern och har ”Max Worker Threads” satt till sitt standardvärde på 255 trådar, så kommer SQL Server att skapa en Thread Pooling. Det innebär att en ensam tråd blir ansvarig för fler än en anslutning. Det är här som dilemmat uppstår. Om du ökar ”Max Worker Threads” så att det blir en anslutning per tråd, så kommer SQL Server att ta till lite extra resurser (mestadels minne). Så om du har en massa RAM minne som inte används av varken SQL Server eller några andra applikationer, så kan det höja SQL Serverns prestanda om du ökar antalet Worker Threads i inställningen.

Men om du inte har tillräckligt med tillgängligt RAM minne, så kan du istället skada SQL Serverns prestanda genom att höja antalet Worker Threads. Det beror på att Thread Pooling inte kräver lika mycket resurser. Men å andra sidan så kan Thread Pooling skapa problem med resursstockningar mellan anslutningarna. Det kan ske då du t ex har två anslutningar som delar på en tråd, och då båda anslutningarna vill utföra samma sak samtidigt (vilket inte kan ske, eftersom en ensam tråd kan bara ta hand om en anslutning i taget).

Så vad gör du? Kort sagt; om du normalt sett har färre än 255 anslutningar mot din Server samtidigt, så bör du hålla kvar standardvärdet. Eller om din Server upplever fler än 255 anslutningar, och om Servern har tillräckligt med RAM, så kan du höja värdet till antalet anslutningar plus 5. Men om Servern inte har tillräckligt med RAM, så bör du helst låta standardvärdet stå kvar. Om din SQL Server upplever tusentals anslutningar samtidigt, så får du prova dig fram tills du hittar den fina linjen mellan de extra resurser som en ökning av Worker Threads kan kräva, och de stockningar som kan ske mellan anslutningar som kämpar om samma tråd.

Som du kanske kan förstå så måste du testa SQL Serverns prestanda både före och efter att du har gjort några ändringar, för att se hur prestandan påverkades av dem. Du måste göra det innan du sätter upp det i någon produktionsmiljö.

Som en del i din analys så bör du följa ovanstående råd för att se hur ställer in den här inställningen.

Min Memory Per Query

När en SQL-sats körs så gör SQL Server sitt bästa för att köra den så snabbt och effektivt som möjligt, genom att tilldela den optimalt med minne. Som standard så är ”Min Memory Per Query” satt till 1024 kB för varje sats som körs. Du kan sätta värden från 0-2147483647 kB.

Om en sats behöver mer minne för att kunna köras mer effektivt, så kan SQL Servern automatiskt tilldela mer minne till satsen (om det finns tillgängligt). På grund av det så är det inte rekommenderat att du ändrar värdet från standardvärdet i ”Min Memory Per Query”.

I vissa fall, om din SQL Server har mer RAM än det behöver för att köras, så kan det hjälpa SQL-satsens prestanda om du ökar värdet till exempelvis 2048 kB eller lite högre. Så länge som det finns ”överdrivet” med tillgängligt RAM minne i Servern (vanligtvis den RAM som inte används av SQL Servern), så kan en höjning av värdet öka Serverns prestanda. Men om det inte finns tillräckligt med RAM tillgängligt så kan du skada prestandan genom att höja värdet för ”Min Memory Per Query”.

Nested Triggers

Den här konfigurationsinställningen kan påverka prestandan, men inte på det traditionella sättet. Som standard så är inställningen ”Nested Triggers” satt till ”1”. Det innebär att Nested Trigger kan köras (Nested Triggers är triggers som aktiverar en annan trigger, som aktiverar en annan trigger (osv), upp till 32 nivåer). Om du ändrar inställningen till ”0” så tillåts inte Nested Triggers. Uppenbarligen så kan du höja prestandan genom att inte tillåta Nested Triggers, men då förlorar du applikationens flexibilitet.

Den här inställningen bör stå kvar på standardvärdet, så till vida att du inte vill förhindra utvecklare från att använda sig av Nested Triggers.

Network Packet Size (B)

Med den här inställningen så kan du specificera storleken på paketen som SQL Server använder då den pratar med klienter över nätverket. Standardvärdet är 4 096 b. De giltiga värdena som du kan skriva in går från 512 b till ett maximalt värde som är baserat på den maximala mängden data som ditt nätverksprotokoll stöder.

Teoretiskt sett så kan prestandan förbättras om storleken på paketet mer eller mindre matchar mängden data i paketet. Om t ex det är lite data, mindre än 512 B i genomsnitt, så kan du höja prestandan genom att ändra värdet från 4 096 till 512 bytes. Du kanske förflyttar en stor mängd data ofta, som t ex med bulklaster, eller hanterar mycket text- eller bilddata, då kan du öka standardstorleken på paketen till ett högre värde än 4 096 bytes. Genom att göra det så minskar du antalet packet som ska skickas, vilket minskar arbetslasten och höjer prestandan.

Teoretiskt sett så låter det här alldeles perfekt. Men i verkligheten så märker du av en ytterst liten, om ens någon förbättring i prestandan. Det beror på att det inte finns någon genomsnittlig datastorlek. I vissa fall kan det vara lite data, och i andra kan det vara enormt mycket data. På grund av det så är det ganska meningslöst att minska värdet i ”Network Packet Size”.

Som en del i din analys bör du ta reda på om det finns någon anledning att ha något annat värde än standardvärdet i denna inställning. Om det inte finns det så kan du låta standardvärdet stå kvar.

Open Objects

“Open Objects” refererar till det totala antalet objekt (såsom tabeller, vyer, regler, standarder, triggers samt lagrade procedurer) som kan vara öppna samtidigt i SQL Server. Standardvärdet för denna inställning är ”0”, vilket innebär att SQL Server reglerar (ökar eller minskar) den här siffran dynamiskt för att hålla optimal prestanda.

I vissa ovanliga fall då allt minne i Servern används till fullo, så kan du få upp ett meddelande där det står att du har överskridigt antalet tillåtna öppna objekt. Det du kan göra då är att antingen lägga till extra minne, eller minska lasten på Servern genom att t ex reducera antalet databaser på Servern.

Om inget av ovanstående alternativ verkar praktiskt, så kan du manuellt gå in och höja det maximala antalet öppna objekt i ”Open Objects”, till ett lämpligare värde. Men det kan medföra två problem. För det första så kan det kräva en hel del tester innan du finner det lämpliga värdet. Och för det andra så kan inte det minne som allokeras till de öppna objekten användas till andra SQL Server behov, vilket kan sänka Serverns allmänna prestanda. Visst, nu kan du köra fler applikationer på Servern, men de kommer att gå mycket slöare. Undvik att göra ändringar i den här inställningen.

Medan du utför din analys och finner att den här inställningen är annat än ”0”, så har antingen någon gjort ett misstag som bör korrigeras, eller så är Serverns hårdvara minimal och du behöver lägga till extra RAM minne. Det kan också vara så att du måste flytta över en del av Serverns arbete till en större, och mindre sysselsatt Server.

Priority Boost

Som standard så körs SQL Servens processer under samma förhållanden som alla andra applikationer på en Server. Det innebär att ingen applikationsprocess har högre prioritet än någon annan då det gäller att erhålla fler CPU cykler.

Konfigurationsinställningen ”Priority Boost” låter dig ändra på det. Standardinställningen är ”0”, vilket innebär att SQL Serverns processer kör under samma förhållanden som de andra applikationsprocesserna. Men om du ändrar värdet till ”1” så har SQL Server en högre prioritet än de andra applikationerna. Det innebär att SQL Servern har första prioritet när det gäller CPU cykler än de andra applikationsprocesserna som körs på samma Server. Men hjälper det verkligen prestandan?

Låt oss titta på några scenarion. Låt oss för det första anta att vår Server inte bara kör SQL Server, utan har fler applikationer (inte rekommenderat, men det kan vara så i verkligheten), och att det finns massvis med CPU kraft tillgängligt. Om så är fallet och du skulle ge SQL Server första prioritet, vad händer då? Inte mycket. Om det finns massor med CPU kraft att tillgå, så spelar det ingen roll om SQL Server får första prioritet. Visst, SQL Server tjänar nog in någon millisekund här och där jämfört med de andra applikationerna, men jag tvivlar på att du märker någon direkt skillnad.

Det andra scenariot liknar ovanstående, men i det här fallet så antar vi att CPU kraften är alldeles utpumpad. Om så är fallet och om du skulle ge SQL Servern första prioritet, så kommer SQL Server självklart att jobba snabbare, men på de andra applikationernas bekostnad. Om det så du vill ha det, så OK. Men den bästa lösningen skulle vara att lägga till extra CPUn eller att minska lasten på Serven.

Men hur blir det om SQL Server är den enda applikationen på en fysisk Server, och då det finns massvis med tillgänglig CPU kraft? I det här fallet så kommer du inte att tjäna någonting på att ge SQL Servern första prioritet, eftersom det inte finns någon applikation (förutom operativsystemet) att tävla med gällande CPU cykler. Dessutom så finns det massor av CPU cykler att tillgå redan.

Och slutligen, om SQL Server är den enda applikationen på en fysisk Server, och CPUn är helt utmattad, så kommer du att landa på plus minus noll om du ger SQL Server första prioritet. Det som kommer hända är att operativsystemet påverkas negativt, och SQL Server kommer att tjäna ytterst lite, om något alls på det.

Som du kan se så är den här inställningen inte värt besväret. Faktum är att Microsoft har dokumenterat flera problem som är relaterade till den här inställningen, vilket gör det mindre åtråvärt att ens försöka sig på det.

Om du i din analys finner att den här funktionen är på, ta reda på varför. Om det inte skapar några problem med att ha den aktiverad, så kan du lämna den på. Annars skulle jag starkt rekommendera att du ändrar tillbaka till standardvärdet.

Query Governor Cost Limit

Inställningen “Query Governor Cost Limit” låter dig begränsa hur länge en sats maximalt kan få köras, och det här är en av de få konfigurationsinställningarna i SQL Server som jag uppskattar. Låt oss t ex säga att några av Serverns användare gillar att köra långtgående SQL-satser som verkligen kan skada din Servers prestanda. Genom att ändra i den här inställningen så kan du förhindra att användaren köra satser som överskrider t ex 300 sekunder (eller hur länge du själv väljer). Standardvärdet är ”0”, vilket innebär att det inte finns någon begränsning för hur länge en sats kan köras.

Värdet som du sätter i den här inställningen är bara ungefärlig, och baseras på hur länge din Query Optimizer uppskattar att satsen kommer att köras. Om uppskattningen är längre än det du har specificerat så kommer den inte att köra satsen alls, utan skapar istället ett Error. På så sätt kan du spara in på en hel del värdefulla Serverresurser.

Å andra sidan så kan användarna bli förargade över att de inte kan köra de satser som behövs för att de ska kunna utföra sitt jobb. Det du bör göra då är att hjälpa användarna att skriva mer effektiva satser. Då blir alla glada och nöjda.

Till skillnad från de andra förslagen jag har gjort, så är det okej om det i din analys visar sig stå något annat än ”0” här. Så länge som inte användarna klagar så är det en bra deal. Faktum är att om det skulle stå ”0” så kan du testa med ett värde för att se vad som händer. Se bara till att du inte testar för låga värdet först. Börja med t ex 600 sekunder och se hur det går. Om det är OK så kan du sänka till 500, osv tills användarna börjar klaga. Då får du dra dig tillbaka.

Query Wait (s)

Om din SQL Server är väldigt sysselsatt och skadar minnesresurserna, så kan den börja köa sådana satser som den räknar som minneskrävande (sådana som kräver sortering och uppdelning), tills det finns tillräckligt med minne för att köra dem. I vissa fall så finns det helt enkelt inte tillräckligt med minne så det sker en time-out för satserna, vilket producerar ett Error. Som standard så sker en time-out för satserna efter 25 gånger den tid det tar för satserna att köras (enligt Query Optimizer).

Den bästa lösningen för ett sådant problem är att lägga till extra minne i Servern eller att reducera lasten i Servern. Men om du inte kan göra det så finns det ett annat alternativ för att tampas med problemet, och det är att använda konfigurationsinställningen ”Query Wait”. Standardinställningen för det här är ”-1”, vilket innebär att väntetiden är som jag beskrev tidigare, och som låter satsen timas ut. Men om du vill att väntetiden ska vara längre, så sätter du ett högre värde i ”Query Wait”. Du kommer definitivt att få testa dig fram för att finna det optimala värdet för det här.

Problemet med att använda den här inställningen är att en transaktion av intensiva satser kan innehålla låsningar, vilket kan leda till ”Deadlocks” eller andra blockeringsproblem. Dessa kan i slutändan medföra större problem än att satsen timas ut. På grund av det här så rekommenderar jag inga ändringar i inställningen.

Om du i din analys finner ett värde som inte är standardvärdet, försök då att ta reda på varför det är det. Om det inte finns någon rimlig anledning för detta, så bör du ändra tillbaka till standardvärdet. Men, om någon har tänkt igenom det här noggrant, och om inställningen inte skapar några låsningsproblem så kan du lämna det värdet som står.

Recovery Interval (min)

Om du har en OLTP Serverapplikation som är väldigt aktiv och som hanterar många INSERTs, UPDATEs eller DELETEs, så är det möjligt att standardvärdet för ”Recovery Interval” inte är det lämpliga. Standardvärdet är ”0” och det innebär att SQL Servern avgör vilket som är det lämpliga återskapningsintervallet. Om du ser över din Servers prestanda med Performance Monitor och upptäcker att det regelbundet sker en 100 % skrivaktivitet på disken (det kan ske under en checkpoint process), så bör du överväga att höja ”Recovery Interval” till exempelvis 5 eller 10. Dessa siffror refererar till det maximala antalet minuter som det bör ta för SQL Server att utföra en återskapning efter en omstart. Standardvärdet är ”0”, vilken betyder en maximal återskapningsperiod på 1 minut.

En annan anledning till att använda den här inställningen är om Servern är hängiven till OLAP eller ett datalager. Dessa read-only databaser drar sällan fördel av de korta återskapningsperioderna.

Om din Server inte matchar något av ovanstående förslag så är det bästa alternativet att låta standardvärdet stå kvar.

Genom att förlänga checkpoint tiden så kan du reducera antalet gånger som SQL Server måste utföra en checkpoint, vilket i sin tur reducerar SQL Serverns extraarbete. Du kommer att få experimentera med dessa siffror för att finna en kompromiss mellan prestanda och den tid det tar för SQL Server att utföra en återskapning.

Det idealiska vore om du höll den här siffran så låg som möjligt, för att reducera den tid det tar att starta om mssqlserver tjänsten nästa gång det sker. Det beror på att varje gång som mssqlserver startas om så går den automatiskt igenom en återskapningsprocess. Och ju högre värde som ”Recovery Interval” är satt till, desto längre tid tar det för återskapningsprocessen. Du måste finna den kompromiss som passar just dina behov.

Som en del i din analys bör du värdera det aktuella värdet i ”Recovery Interval”, för att se om den passar in i behovet. När det gäller sysselsatta OLTP Servrar, så bör du göra en noggrann undersökning innan du höjer värdet i ”Recovery Interval”, för att se om det kommer att hjälpa. Det är viktigt med tester. Men om din Server är en dedikerad OLAP eller datalager Server, så är det ett simpelt beslut att höja ”Recovery Interval”.

Scan for Startup Procs

Om SQL Server är konfigurerad korrekt, så har den förmågan att automatiskt söka efter lagrade procedurer och köra dem då mssqlserver startas upp. Det kan vara användbart då du vill att någonting särskilt ska utföras vid en uppstart, som att t ex lagra en specifik lagrad procedur i Cachen så att den redan finns där när användarna accessar Servern.

Som standard så är ”Scan for startup Procs” satt till ”0”, vilket innebär att Servern inte söker automatiskt efter lagrade procedurer då den startas. Om du inte har några lagrade procedurer som är avsedda för en uppstart, så är standardvärdet det enda rätta. Det är ingen idé att slösa på resurser för att söka efter en procedur som inte finns.

Men om du har en eller flera procedurer som du vill ska aktiveras då Servern startas så kan du sätta det här värdet till ”1”, vilket aktiverar en sökning.

Om du i din analys ser att värdet är satt till ”1” så måste du leta efter de lagrade procedurer som ska aktiveras vid en uppstart. Om du inte finner några, så bör du ändra tillbaka till ”0”.

Set Working set Size

Inställningen “Set Working set Size” används till att fixera den minimala och maximala mängden minne som SQL Servern får använda då den startas. Den förhindrar också Page Swapping.

Som standard så är “Set Working set Size” satt till ”0”, vilket innebär att den inte är på. För att aktivera den så måste du sätta värdet till ”1”, PLUS att den minsta och högsta storleken på minnet måste vara satta till samma värde. Det är det värdet som används för att reservera storleken på arbetssetet.

Precis som med de flesta inställningarna så behövs den här egentligen inte. Den enda gången som du bör överväga att använda den är om din Server enbart kör SQL Server, om det är tung last på Servern och då det inte finns tillräckligt med tillgängligt minne. Men till och med då kommer förbättringen i prestanda att vara minimal, och du riskerar möjligheten att inte lämna tillräckligt med minne till operativsystemet. Tester är nyckeln till framgång.

Om det här värdet är satt till någonting annat än standardvärdet, kontrollera då så att minimum- och maximumvärdet är samma värde, annars kommer det inte att fungera som det ska. Om villkoren ovan är uppfyllda, och om du har gjort noggranna tester, så kan du lämna värdet som det är. Annars så bör du ändra tillbaka till standardvärdet. Glöm då inte att ändra tillbaka alla tre värden!

User Connections

Som standard så allokerar SQL Server bara så många användaranslutningar som den behöver. På så sätt tillåts de som vill ansluta att ansluta, vilket på samma gång reducerar mängden minne som används. När inställningen ”User Connections” är satt till standardvärdet ”0” så sköts det här dynamiskt. Under i stort sett alla omständigheter, så är standardvärdet det bästa värdet.

Om du ändrar värdet för ”User Connections” så talar du om för SQL Server att bara ansluta så många användare som du har specificerat, varken mer eller mindre. Samtidigt så kommer SQL Server att allokera minne för varje specificerad anslutning, vare sig det kommer användas eller inte. På grund av dessa problem, och på grund av att SQL Server i och med detta inte kan sköta det här dynamiskt och mer effektivt, så finns det ingen anledning att ändra från standardvärdet.

Om din analys visar att det står någonting annat än ”0” här så ändrar du bara tillbaka till 0. Fråga inte ens varför.

Och nu då?

Vårt mål är att utföra den del av prestandaanalyseringen som vi har diskuterat i den här artikeln, på var och en av dina Servrar, och sedan använda den informationen du får ut till att göra eventuella korrigeringar – om du kan.

När du har klarat av den här delen i analyseringen, så är du nu redo för att analysera din SQL Servers databaskonfigurationer.

0 Kommentarer

Skriv en kommentar på artikeln

Ditt betyg på artikeln

UtmärktLäsvärdIntressantMindre braDålig

Kommentar: