Förord

I denna artikel som är indelad i 4 mindre artiklar kommer du att lära dig använda NT Server 4.0's Performance Monitor samt Microsoft Excel för att analysera prestandan. Du kommer också lära dig att använda en SQL Server databas för att lagra dina uppmätta prestanda i loggfiler. Denna artikel förutsätter att du redan vet grunden inom Performance Monitor, Excel och givetvis SQL Server. Detta är del 1 och kommer innefatta hur du använder Performance Monitor för att fånga och logga data. Del två kommer diskutera hur du använder SQL Server för att lagra loggarna. Del tre kommer visa dig hur du använder Excel för att analysera det data du fått. Slutligen i del 4 kommer du se hur dina resultat behandlas.

Innehåll

  » Bakgrund
  » Övervakning av prestanda upphör aldrig
  » Välj en Performance Monitor Vy
  » Bestäm var Performance Monitor ska köras
  » Välj rätt objekt att övervaka och logga
  » Bestäm samlingsintervallet
  » Starta insamling av data

Hur du utför SQL Server Performance Trend Analys

Av Brad M. McGehee

Del 1: Använda Performance Monitor för att Logga Data

Bakgrund

Innan vi börjar denna handledning ska vi först diskutera lite kort varför vi vill övervaka SQL Servers prestanda. Som du antagligen redan vet är SQL Server mycket bra på att justera sig själv. Den har förmågan att styra sig själv och genom en feedback loop vet den hur den internt ska justera och ställa in sig själv så att den fortsätter köra effektivt, även när externa händelser inträffar, som att antalet användaranslutningar eller mängden av tillgänglig RAM förändras över tid.

Men som vi alla vet är SQL Servers förmåga att justera sig själv inte perfekt och den tar inte i beräkning varje möjlig aspekt som påverkar dess prestanda. Som DBA, behöver vi hjälpa SQL Server och ge den de resurser som den behöver för att göra ett bra jobb när den tar fram data.

Som en god DBA, vill vi inte få höra av våra användare att SQL Server har prestandaproblem. Vi vill istället vara förutseende och fånga upp prestandaproblem innan de uppstår. Det är det som NT Server 4.0 Performance Monitor kan hjälpa oss att göra. Det är ett verktyg som tillåter oss att övervaka vad som pågår i vår SQL Server, och ger oss den information som vi behöver för att fatta beslut om hur vår SQL Server bäst kan justeras.

Performance Monitor är ett viktigt verktyg, eftersom den både ger oss information om hur SQL Server fungerar och den låter oss också veta hur NT 4.0 Server fungerar, vilket naturligtvis direkt påverkar SQL Servers prestanda.

Med detta i minnet är syftet med denna handledning att visa dig hur du kan använda Performance Monitor för att fånga NT och SQL Server-relaterad data, och sedan analysera den genom att använda både Performance Monitor själv och Microsoft Excel genom att använda trendanalys. Och eftersom vi behöver en plats för att lagra våra Performance Monitorloggar kommer du att få lära dig hur de kan lagras i en SQL Server-databas.

Övervakning av prestanda upphör aldrig

Övervakning av hur NT 4.0 Server och SQL Server presterar är inte en engångshändelse. Som DBA bör du ständigt övervaka alla dina SQL Servrars uppförande. Så är fallet, vare sig du har en server eller hundra.

Som vi beskriver senare i denna handledning bör du använda Performance Monitor för att fånga prestandamätare och lagra dem i en logg. Periodvis bör denna logg exporteras till en lagringsplats för långtidslagring. Denna lagringsplats kan vara en mapp på ett nätverk som håller de ursprungliga Performance Monitor loggfilerna, en SQL Server databas, en Access databas eller ett Excel kalkylark, vilket som bäst motsvarar dina behov. I vårt fall kommer vi att använda SQL Server för att lagra dessa data.

Jag har valt SQL Server av flera anledningar. För det första, den är lättillgänglig. För det andra, vi bör veta hur den används. För det tredje, den kan hantera alla dina lagringsbehov. För det fjärde, det är lätt att importera Performance Monitor loggar till SQL Server, och lätt att exportera loggningsdata till Excel.

När vår Performance Monitor loggade data väl finns i en SQL Server databas kan vi sedan välja att exportera den till Excel för detaljerad analys. Och eftersom datat finns i SQL Server har vi hela SQL Servers kapacitet att endast VÄLJA och analysera de data vi vill analysera i Excel.

Den huvudsakliga anledningen till att vi vill lagra våra Performance Monitor loggar är att det ska vara möjligt att identifiera trender i prestandan. Att titta på Performance Monitor loggar för en dag, eller till och med en vecka, kan inte riktigt säga oss om vi behöver lägga till flera CPU, eller mer diskutrymme till vår server nästa år. Vad vi behöver är flera månaders data, kanske flera års data, som vi kan använda för att göra pålitliga förutsägelser om vad vår SQL Servers resursbehov kommer att vara i framtiden.

Så en av de största nyttorna av långsiktig övervakning av NT Server 4.0 och SQL Server är att kunna förutsäga våra serverbehov i framtiden. Medan detta är viktigt behöver vi också samma loggar som hjälp för att identifiera aktuella flaskhalsar i prestandan och andra möjliga prestandarelaterade problem. Ju mer information vi har till vårt förfogande desto bättre beslut kan vi fatta.

Välj en Performance Monitor Vy

Performance Monitor har fyra operativa ”vyer”. De inkluderar:

• Chart View: För granskning och analys av prestandamätare
  
• Alert View: För att skapa prestandabaserade varningar
  
• Report View: För att granska prestandadata i tabellform
  
• Log View: För att logga prestandadata till en loggfil
  

Vårt fokus här kommer att ligga på Log View, som tillåter oss att välja de Performance Monitor mätare som vi vill samla och logga, tillsammans med hur ofta vi vill samla dessa data.

Bestäm var Performance Monitor ska köras

Det första steget för att använda Performance Monitor är att bestämma var den ska placeras när den körs. Du kan placera den på samma server som den övervakar eller på en NT Server eller en arbetsstation. Om du kör Performance Monitor från samma server som du övervakar, kommer det att påverka resultatet, men inte signifikant på de flesta servrar.

Jag föredrar att köra Performance Monitor från NT 4.0 arbetsstation, som är ansluten till den server som övervakas över ett nätverk. Detta kommer att flytta det mesta av belastningen från den server som övervakas, med ett litet undantag av en viss nätverksaktivitet.

Ett annat val är att använda den servicebaserade versionen av Performance Monitor som finns tillgänglig i NT Server 4.0 Resource Kit. Det tillåter dig att köra Performance Monitor som en tjänst, inte som en förgrundsapplikation. Detta kan hjälpa till att reducera den totala körningen av Performance Monitor. För denna handledning kommer vi att använda standardmjukvaran för Performance Monitor som kommer med NT 4.0 Server och arbetsstation.

När du väl har bestämt var Performance Monitor ska köras är nästa steg att bestämma hur många SQL Servrar som du vill övervaka. Performance Monitor kan övervaka upp till 10 olika servrar samtidigt. Om du bestämmer dig för att övervaka mer än en server åt gången kommer du definitivt att vilja dedikera en dator, som NT 4.0 arbetsstation för denna uppgift. Behöver du övervaka mer än 10 servrar åt gången kan du öppna flera instanser av Performance Monitor på din dator.

Välj rätt objekt att övervaka och logga

Nästa steg är att bestämma vilka saker vi vill övervaka och logga. Beroede på hur din server är konfigurerad så kan det finnas över 400 olika saker som du kan mäta. Men det är mycket mer än vad du någonsin kommer att behöva. Även om du skulle försöka att övervaka så många mätdelar så skulle du generera enorma mängder data, i omfattningen av över en megabyte i minuten, beroende på loggningsintervallet.

Till skillnad från Chart View, låter Performance Monitor funktioner i Log View dig inte att välja individuella mätare att övervaka. I stället måste du välja hela Performance Monitor Objekt. Det innebär att om ett speciellt Performance Monitor objekt har 25 mätare i sig, och du bara vill övervaka en av dem, kommer du ändå att få alla 25 mätare. Det finns ingen väg runt det här.

Så du måste bestämma vilka Performance Monitor objekt som har de räknare som du vill övervaka, och sedan lägga till dem i Performance Monitor Log View. Kom ihåg att ju fler objekt du väljer, desto mer data samlas in, och desto större resurser används för att samla datan. Medan du vill samla alla objekt som du behöver ska du inte samla data från alla objekt som du inte använder.

Varje DBA föredrar vissa Performance Monitor objekt som ska övervakas och loggas och jag håller mig vanligtvis till dessa:

• Minne
  
• Nätverkssegment
  
• Fysisk disk
  
• Processor
  
• Server
  
• System
  
• SQL Server: Access Methods
  
• SQL Server: Buffer Manager
  
• SQL Server: General Statistics
  
• SQL Server: Locks
  
• SQL Server: SQL Statistics
  

Till största delen inkluderar dessa objekt alla mätare jag använder för att övervaka både NT 4.0 Server och SQL Server, även om jag naturligtvis inte använder alla mätare i alla dessa objekt.

Bestäm samlingsintervallet

När du väl har valt de Performance Monitor objekt som ska samla data, är nästa steg att bestämma samlingsintervallet. Samlingsintervallet bestämmer hur ofta data undersöks och lagras i loggen. Standardintervall är 15 sekunder. Det innebär att alla mätarna för alla objekten samlas och lagras i loggen var 15:e sekund. Värdena för mätarna som samlas är medelvärdena för mätarna över 15 sekunders intervall. Om du använder ett intervall på 60 sekunder kommer datat att vara ett medelvärde och insamlat över 60 sekunder.

Ju kortare intervall desto mer detaljerad data, och ju längre intervall desto mindre detaljerad data. Om datat inte är detaljerat nog kan du missa viktiga toppar som inte kommer upp på grund av att all data i samlingsintervallet är ett genomsnittsvärde på samlingsintervallet.

Längden på samlingsintervallet är proportionerlig till datamängden som ska samlas. Ju kortare intervall desto större mängd insamlad data och ju längre intervall desto mindre mängd.

Du kanske vill experimentera med olika samlingsintervall för att hitta det som är bäst för din miljö. Samlingsintervallet som jag använder beror på hur länge jag samlar datat. Generellt, om jag samlar data för 8 timmar eller mindre, väljer jag ofta ett intervall från 30-60 sekunder. Men om jag samlar data över över ett dygn eller längre, väljer jag ett intervall från 300-600 sekunder. Detta på grund av att om du inte väljer ett större intervall blir datamängden som samlas in överväldigande stor.

Starta insamling av data

Nu när du har fattat alla dessa beslut, glöm inte att spara ditt arbete innan du börjar samla data. Du kan använda valet File|Save Log Settings för att spara en fil med all den information som du har lagt in, som vilka objekt du valt, så att du kan ladda igen om du behöver.

När dina inställningar väl är sparade, är du redo för att börja samla dina data. När du startar, titta på skärmen en stund, och se hur mycket data som blir insamlad. Om det verkar som om det blir för mycket data för fort, då kanske du samlar för mycket data eller samlar det för ofta. Du kanske vill stoppa loggningen, göra några ändringar för att reducera mängden av loggad data, och försöka igen.

Om du samlar data över flera dygn, behöver du stoppa loggen med jämna mellanrum (som en gång om dagen), och sedan starta om den direkt, men använda ett nytt filnamn. Jag tycker om att använda dagens datum som mitt filnamn. Om du inte gör detta (stopp och omstart av loggen), kommer din logg att bli enorm.

Allteftersom loggarna skrivs ut, som en gång om dagen, är din nästa uppgift att antingen granska dem direkt med Chart View i Performance Monitor för en quick-and-dirty analys, eller att importera datat direkt till en SQL Server databas för senare analys genom att använda Microsoft Excel.

Läs nu del två av denna fyrdelade artikel, och lär dig hur du importerar Prestanda loggdata till SQL server för senare trendanalys.

0 Kommentarer

Skriv en kommentar på artikeln

Ditt betyg på artikeln

UtmärktLäsvärdIntressantMindre braDålig

Kommentar: