Optimera SQL Servers prestanda
Förord
Den här artikeln behandlar hur man optimerar en SQL-databas. Innehåller mycket generella tips och förslag på vad man bör tänka på och vad man bör kontrollera, dock ingen kod.
Innehåll
»Optimera SQL Servers prestanda
Jag önskar att jag kunde ge dig en komplett lista över de steg som du kan utföra för att optimera din SQL-server till 100%. Olyckligtvis är livet inte så enkelt. Att optimera en SQL Server är ett komplext växelspel med många variabler, över vilka man har liten eller ingen kontroll. Här följer några av de många variabler som påverkar optimeringen av SQL Server (alla är ej med):
- SQL Server (programkoden)
- Konfiguration av SQL Server
- SQL Server Programet (Transaktions-SQL som körs på servern)
- Klient-Server programkod (ej Transaktions-SQL)
- Mellanprogramvara (MTS och MSMQ)
- Databasdesign
- Klient-Server Hårdvara
- Klient-Server Operativsystem
- Nätverkshårdvara och bandbredd
- Klientprogram
- Arbetsbelastningen
- Antalet klienter
- Användarmönster
Den här listan kan göras hur lång som helst. Som databasutvecklare är allt du kan göra att försöka isolera de faktorer du kan kontrollera och optimera prestandan hos dem. En annan faktor som försvårar optimering är att en rekommenderad optimeringsteknik kanske hjälper i en situation, medan samma förslag faktiskt kan försämra prestandan i en annan situation. Många gånger är optimering en serie av kompromisser, där du, som databasutvecklare, måste bestämma vilka faktorer som är viktigast. Optimering och finjustering av SQL Server är en teknik som man lär sig, precis som vilket hantverk som helst. Det vill säga att ju bättre grund du har att stå på och ju mer erfarenhet du har, desto bättre kommer du vara på ditt jobb. Här följer några generella tips som kan hjälpa dig att bli bättre på att optimera din SQL Server:
På den här hemsidan kan du hitta flera hundra tips för att optimera Microsoft SQL Server. Det de alla har gemensamt är de här tre målen:
- minimera disk I/O
- minimera användingen av CPU
- minimera nätversktrafiken
Ett annat sätt att säga det är att du vill flytta så lite data som möjligt mellan SQL Server och klienten, och bara flytta det en gång. Vilken väg du än väljer för att optimera och finjustera SQL Server, kommer ditt övergripande mål alltid vara detsamma. Ju mer du kan reducera punkterna ovan, desto bättre kommer prestandan på ditt SQL Server-baserade program att vara.
Många av optimerings- och prestandaförbättringsförslagen på den här hemsidan kommer bara att resultera i mycket små prestandavinster. Sett var för sig är vissa av dem inte ens värt besväret. Men, ditt mål borde inte vara att göra en enkel prestandaförbättring, utan många. Det är bara genom att införa många olika prestandaförbättringar och optimeringstips som ditt program kan bli snabbare och mer skalbart. Varje liten prestandaförbättring snabbar upp programmet.
Repetetitiva frågor
Vissa program har hundratals, om inte tusentals frågor, vilket gör det näst intill omöjligt att optimera varje fråga för hand. Eftersom tiden är en begränsning, fokusera dina optermeringsinsatser till de frågor som körs mest. Du kanske anser att en fråga som tar 0.5 sekunder inte behöver optimeras, men om den frågan måste köras 10 000 gånger i ditt program under en uppdateringsprocess? Fokusera dina insatser på de frågor som får mest effekt på helhetsutförandet av ditt program.
Hantera grunderna
Ju bättre du förstår hur SQL Server fungerar internt, desto bättre kommer du kunna optimera den. Ett försök att optimera utan att veta vad som försigår under huven, är som att försöka optimera ett kärnkraftverk utan att veta något om kärnkraft.
Läs vad andra gjort
Läs boken, Inside SQL Server 7.0 eller Inside SQL Server 2000 av Kalen Delaney. De är de bästa böckerna på marknaden om hur SQL Server fungerar.
Optimera löpande
Prestandaförbättring och optimering är inget som borde lämnas till sist i ett projekt, eller efter att systemet sjösatts och man upptäckt prestandaproblem, det är något som måste tas i beaktande redan när ett projekt inleds. Du borde ta med prestandaförbättringar i beräkningen redan i sammanställningen av kravspecifikationen. Ta reda på vad användarna förväntar sig i form av prestanda. När du vet det kan din design av programet ta hänsyn till den informationen. Updated 12-29-2000
När du optimerar SQL Server, gör bara en förändring i taget, kontrollera den sedan för att se om förändringen förbättrade något. Det förutsätter att du redan har testrutiner och gamla resultat med vilka du kan jämföra resultaten efter din ändring. Om du inte har bra dokumentation av före och efter, är det inte säkert att du kommer att kunna avgöra om din förändring var till det bättre eller inte.
Dokumentera dina optimeringsexperiment i en logg. Det tvingar dig att experimentera med lite mer eftertanke och hjälper till att förhindra en återupprepning av de misstag du gjort.
Om det inte är självklart var man ska leta efter prestandaförbättringar är de bästa ställena att leta efter dem på följande ställen, och i den här ordningen:
- Programmet (inkluderar klient- och serverkod)
- Databasdesign (logisk och fysisk)
- SQL Server (konfigurationen)
- Hårdvara (flaskhalsar, dålig design, dålig konfiguration etc.)
Det här verkar kanske inte intuitivt vid första anblicken. De flesta databasdesigners vill börja med hårdvaran. Men i den verkliga världen indikerar den ovanstående ordningen den mest sannolika följden för var prestandaproblemen kan tänkas finnas. Medan alla dessa områden kan ge prestandaförbättringar, är det de två första som ger störst utrymme för förbättringar.
Nästlade problem
I vissa fall kan det vara svårt att lokalisera prestandaproblem eftersom två eller flera problem har gaddat ihop sig mot dig. Det är ett svårt problem att reda ut. Hemligheten är att enbart försöka fixa ett åt gången och att testa prestandan före och efter varje förändring. Till slut kommer du att hitta alla dina prestadaproblem.
Svarstider
Medan du försöker lokalisera ett prestandaproblem, ta reda på om problemet är konsistent, eller om det varierar över tiden. Om så är fallet, kan problemet ha att göra med hur upptagen servern är. Det kanske inte finns några prestandaproblem innan 08.00 eller efter 16.00, medan antalet användare dess emellan kan vara för stort för att servern ska klara av det med tillfredsställande svarstider. Att vara medveten om det här kan vara en stor fördel när man ska lokalisera prestandaproblem.
Flaskhalsar
Idealet vore att du trimmade din SQL Server till att möte användartopparna, inte medelnivåerna. Om du tex. vet att en användartopp orsakar en flaskhals på servern mellan 10.00 och 11.00 varje dag, borde du agera för att få bort flaskhalsen, även om den bara existerar för en kort stund. Du vill inte att dina användare ska bli lidande under den vältrafikerade timmen. Designa din serverkapacitet med användartoppar i tankarna.
Optimera klokt och systematiskt
Överoptimera inte ditt program eller SQL Server. Till exempel kan ett speciellt index producera ett resultat på en sekund, medan ett annat kan ge ett resultat på två. Vid en första anblick ser det ut som om den snabba frågan är bättre, och det kan hända att du har rätt. Men du får inte glömma bort att två sekunder kan vara tillräckligt för att göra användaren nöjd, och att den extra sekunden inte spelar någon roll. Det extra indexet kan istället ha orsakat att ensekunds-indexet nu är fem megabyte större än tvåsekunds-indexet, och att det även försämrar prestandan på INSERTS, UPDATES och DELETES mer än vad tvåsekunders-indexet gjorde. Visst, det är många om och men, men det är verkligheten. Det finns många situationer där överoptimering av ditt program eller SQL Server bara är ett slöseri med tid. Fokusera alltid på det mest kritiska. Optimera inte bara för optimerandets skull. Added 8-28-2000
0 Kommentarer