SQL Server Performance Trendanalys del #2
Förord
Det här är del två i en artikel på fyra delar. Den här delen diskuterar om hur du kan använda SQL Server till att lagra dina Performance Monitor loggdata. Del tre kommer att visa dig hur du använder Microsoft Excel för att analysera dessa Performance Monitor data. I del fyra kommer du att få lära dig hur du tolkar dessa resultat.Innehåll
»»
»
»
»
»
»
»
»
»
»
»
Relaterade artiklar
» SQL Server Performance Trend Analysis del #1» SQL Server Performance Trend Analysis del #3
» SQL Server Performance Trend Analysis del #4
Del 2: Lagra Performance Monitor data i SQL Server
av Brad M.McGehee
Översikt
I den första delen av den här serien så tog vi en titt på hur du kan använda NT Server 4.0’s Performance Monitor för att samla in prestandadata från din SQL Server. Trots att Performance Monitor är ett superbt verktyg till att samla in prestandadata och relativt bra på att analysera dem, så är den väldigt dålig på att lagra dessa prestandadata till senare bruk. Performance Monitor lagrar de loggdata som den samlar in i ett format som gör det svårt att användas av annan mjukvara. Det du kan göra då är att exportera dessa data från Performance Monitor till ett ASCII format så att de kan importeras till en annan mjukvara, som t ex SQL Server, för lagring.
Varför måste vi lagra Performance Monitor data?
Hela syftet med den här artikelserien är att lära sig göra en SQL Server prestandatrendanalys. När vi talar om trendanalyser så talar vi om att samla in SQL Server prestandadata varje dag, dag efter dag, och lagra det för att sen analysera vad som händer under olika tidsperioder.Som t ex en DBA så är det viktigt för mig att veta hur många användare det är som använder min Server. Jag måste dessutom veta om siffran går upp eller ner, om siffran ändrar sig snabbt eller långsamt, om användarna är lätta eller tunga användare, och om siffran stiger snabbt så måste jag veta hur det påverkar min Servers prestanda. Så till vida att du inte har hårda data att se över så kan det vara svårt att göra smarta val om vad du ska göra för att försäkra dig om att din SQL Server har en god reaktion till dina användare.
Vi kommer att samla in data under långa tidsperioder för att kunna förse oss med de data som vi behöver för att kunna identifiera aktuella prestandaproblem, samt för att kunna planera inför framtiden. Beror det aktuella suget i CPU aktivitet på flera användare eller för att samma antal användare kör fler SQL-satser? För att kunna svara på den här frågan tillsammans med flera hundra andra frågor så måste du ha en bra historiska prestandadata. Utan dem så kan du bara gissa dig till vad som för tillfället står på.
Att förutse framtiden, åtminstone så långt som din hårdvara behöver gå, är också en viktig fråga. De flesta DBAs kan inte bara gå till sina chefer och säga att de behöver installera en ny Server imorgon för att kunna lösa ett nyligen upptäckt prestandaproblem. Istället så måste DBAs försöka förutse de framtida behoven, samt påbörja den långa processen om att införskaffa ny utrustning långt innan behovet uppstår. Den här processen kräver ofta att DBAs måste göra skäl för sin ansökan, och om det finns goda data så gör det rättfärdighetsprocessen lättare.
Om du är DBA för en SQL Server eller flera hundra SQL Servrar så måste du samla in Performance Monitor data, för att sedan lagra dem så att du lätt kan komma åt dem igen.
Microsoft gör det inte lätt att lagra och analysera Performance Monitordata
När Microsoft skapade Performance Monitor så räknade de tydligen inte med att folk skulle vilja lagra sina data för att kunna komma åt dem lätt senare. Trots att den här artikeln kommer att lära dig hur du lagrar Performance Monitor data i SQL Server så är det inte så rakt på som det borde vara. Faktum är att du kanske bestämmer dig för att inte bry dig om det här när du har läst artikeln, på grund av allt trassel.Om du kommer till den slutsatsen så gör du ett kortsiktigt misstag. Ok, det är lite krångligt, men det är värt det i slutändan.
Men om du inte har den tid som krävs för att samla in och lagra dina Performance Monitor data? Om du inte har tid, men pengar istället, så bör du överväga att införskaffa ett tredje partens verktyg som samlar in, lagrar och analyserar dina Performance Monitordata.
Det finns ett antal verktyg ute på marknaden som samlar in Performance Monitor data, men det är två som jag är speciellt familjära med, och det är Event Log Monitor från
Men om du inte har pengar till specialiserad mjukvara så måste du lagra dina Performance Monitor data manuellt, som jag beskriver i den här artikeln. Om du läser igenom de steg som jag har markerat ut dig nedan så kan du lägga på minnet att du inte behöver följa varje steg exakt såsom jag har beskrivit. Nyckelsaken att komma ihåg är den Stora Bilden, den kritiska punkten är inte detaljerna för hur du förflyttar dina data från Performance Monitor till SQL Server 7.0. Det kritiska är hur du lagrar dina data till senare bruk för trendanalyser.
En översikt för hur du lagrar dina data med hjälp av SQL Server 7.0
Nedan ser du de steg som du kan följa för att exportera SQL Server Performance Monitor data från Performance Monitor till SQL Server 7.0. Det är liknande steg för att flytta data till SQL Server 2000, bortsett från vissa mindre detaljskillnader. Följande steg förutsätter att du redan har samlat in dina SQL Server Performance Loggdata med hjälp av de tekniker som beskrevs i första delen av den här artikelserien.Här följer en kort sammanfattning för hur du exporterar data från Performance Monitor och importerar dem i SQL Server:
- Peka på loggdatan med hjälp av Performance Monitor
- Välj de Counters som du vill exportera från dina loggdata
- Exportera dina data i ett komma-omringat ASCII-format
- Städa dina Performance Monitordata med hjälp av Microsoft Excel
- (Endast en gång) Skapa en databas för att lagra dina data i
- Använd DTS för att importera Exceldata till en SQL Server tabell i ett paket
- Importera kalkylbladet i Excel till en SQL Server tabell
Peka på loggdatan med hjälp av Performance Monitor
- Innan du kan exportera dina prestandadata från Performance Monitor så måste du först peka ut den loggen som innehåller de data du vill lagra i SQL Server.
- För att göra det så startar du Performance Monitor och väljer Graph Mode (om den inte redan är vald). Sen väljer du ”Options” i menyn och därefter ”Data from”. Det här visar dialogboxen ”Data from”.
- I dialogboxen så klickar du på radioknappen ”Log file” och sen på ”Browse” knappen (den med tre perioder). Det här visar ”Open Input Log File” boxen. Här söker du och väljer den loggfilen som du skapade tidigare och klickar på ”Open”. Nu finns du återigen i dialogboxen ”Data from”, där du klickar på ”OK”. Nu vet Performance Monitor vart loggfilen ligger så att den kan arbeta med den.
Välj de Counters som du vill exportera från dina loggdata
- Ditt nästa steg är att välja de Counters som du vill lagra i SQL Server för senare trendanalys. Som vi diskuterade i den första delen av den här artikelserien så samlas det in data till varje Counter för varje objekt som du valde när du skapade loggfilen, trots att du kanske inte ville övervaka eller analysera alla Counters för alla de objekt som du skapade. Det innebär att ditt nästa steg är att välja endast de Counters som du vill lagra i SQL Server och ignorera resten. Trots att du kan lagra alla Counters för alla objekt i SQL Server så kommer det bara sluta med att du lagrar alltför mycket data, av vilka de flesta kommer inte användas.
- Hur du väljer de enstaka Counters som du vill lagra i SQL Server är att lägga till Countrarna till Graph Mode i Performance Monitor, precis så som du skulle göra om du ville övervaka Counters i real-time i Graph Mode. Du kommer att få lägga till alla de Counters som du vill se över för varje objekt som du loggade.
Exportera dina data i ett komma-omringat ASCII-format
- När du har lagt till alla Counters i Graph Mode av Performance Monitor så kommer skärmen att vara lite svårläst på grund av att det blir så mycket data så det blir svårt att se. Men oroa dig inte över det, det påverkar inte hur vi exporterar alla Counterdata. Ditt nästa steg är att spara alla dessa Counters så att du inte måste välja om dem igen nästa gång du behöver importera dem.
- Du lagrar dessa Counters genom att klicka på menyalternativet ”File” och sen ”Save Chart Settings”. Du kommer att bli visad en dialogbox där du kan spara en fil med ett namn du tillger, som innehåller alla dina inställningar. Dessa inställningar kan sedan återhämtas genom att välja ”File” och sen ”Open”. Det kommer att visa en annan dialogbox där du kan välja och ladda den filen som innehåller alla dina Counters.
- Nu när du har valt alla Counters som du vill exportera och lagra i SQL Server så är du redo att utföra den faktiska exporten från Performance Monitor. För att göra det så klickar du på menyalternativet ”File” och sedan ”Export Chart”. Det kommer att visa dialogboxen ”Performance Monitor – Export As”. Här får du välja vart du vill lagra exportfilen, vilket namn filen ska få samt vilket format du vill lagra filen i. Standardformatet för export är ”Export TSV Files”, vilket är det Tab-omringade ASCII formatet. Men istället för att välja standardformatet så väljer du ”Export CSV Files”, vilken exporterar dina data i det komma-omringade ASCII formatet. Båda två kommer att fungera, men exemplet som jag använder i den här artikeln använder det komma-omringade formatet.
Städa dina Performance Monitordata med hjälp av Microsoft Excel
- Nästa steg du måste genomgå innan du kan importera loggfilen till SQL Server är att städa upp lite i filen med hjälp av Microsoft Excel. Anledningen till att vi gör det är därför att exportfilen har lite headerinformation som behöver raderas innan vi kan göra en ren import till en SQL Server tabell med hjälp av DTS. Illustrationen nedan visar en sorts headerinformation som kan produceras i exportfilen. Det är vårt jobb att rensa undan det.
- Det här är vad du behöver göra för att rensa upp i filen. De första sex raderna innehåller headerdata, och den sjunde raden är en blank rad, så alla dessa rader måste raderas. Rad 11 innehåller namnet på objektet för varje Counter. Vi behöver inte den informationen så vi kan ta bort rad 11. Rad 12 inkluderar namnen på Date och Time kolumnerna, men resten av kolumnerna indikerar på namnet på Servern som är övervakad. Det jag gör här är att jag flyttar namnen på Date och Time kolumnen till rad 8, där resten av kolumnnamnen är lokaliserade. Efter att ha flyttat dessa kolumnrubriker så raderar jag rad 12. Du kan ha data i rad 9, men det är inte säkert. Den raden används till namnet på Counterns instans, om det finns någon. I det här exemplet så finns det ett fåtal fall där det finns fler än en instans av en Counter, så det jag gör är att jag flyttar namnet på instansen från kolumnen på rad 9 och lägger till den till kolumnnamnet på rad 8. På så sätt så vet jag vilken Counter som hör till varje instans. Rad 10 är alltså blank så jag raderar den. Det här kommer att lämna dig med endast rad 8 längst upp på kalkylbladet, och den bör nu innehålla alla de kolumnnamn som ska exporteras in i en SQL Server tabell.
- När jag väl har rensat upp bland mina data så sparar jag kalkylbladet som ett Excelkalkylblad, och inte som en CSV fil. Vilket format du väljer att spara det i är inte alltför relevant, men till den här artikeln så föredrar jag ett Excelformat.
Skapa en databas för att lagra dina Performance Monitordata i
- Innan du kan importera dina data till en SQL Server tabell så måste du först skapa en databas. Jag namngav min databas till SQL_Performance_Data. Jag skapade den till att bli 5MB stor med en 1MB stor loggfil, men du kan börja med vilken storlek du tycker passar dig. För att kunna lagra dina data så skapar du en tabell lite senare, då du första gången importerar dina data med hjälp av DTS.
Använd DTS för att importera Exceldata till en SQL Server tabell i ett paket
- När du har skapat din databas så är ditt nästa steg att använda DTS till att importera kalkylbladet till databasen som en tabell. Den första gången som du gör det här så kan du låta DTS skapa tabellen åt dig med hjälp av kolumnnamnen från Excel kalkylbladet. Efter att du har kört DTS för första gången så behöver du bara lägga till nya data i tabellen där det redan existerar data, om du vid ett senare tillfälle vill lägga till extra prestandadata. Gå igenom följande steg då du använder DTS till att importera dina prestandadata från kalkylbladet till en nyskapad tabell:
- Starta DTS Import Wizard och ange ”Microsoft Excel 8.0” som din datakälla. Därefter pekar du ut det kalkylblad som innehåller dina prestandadata.
- Destinationssökvägen anger du som ”Microsoft OLE DB Provider for SQL Server”, ditt SQL Server namn samt namnet på databasen. Använd den verifikationsmetod som passar dig bäst.
- Välj sedan alternativet ”Copy table(s) from the source database” från wizarden.
- Det är steget är det som kräver mest arbete och det finns flera olika vägar att gå, där alla fungerar. Den vägen som jag tänker visa här är bara en av flera möjliga tillvägagångssätt. Använd sedan dina egna erfarenheter och önskemål för att avgöra exakt hur du vill gå tillväga.
- Det första jag skulle vilja rekommendera är att döpa om destinationstabellen till samma namn som den SQL Server som loggas. På så sätt så kan du hålla separata tabeller för prestandadata för varje SQL Server som du övervakar, och genom att ge varje tabell namnet på SQL Servern så slipper du blanda ihop vilka data som hör till vilken Server.
- Sen klickar du på ”Transform” knappen, vilket visar de mappade kolumnerna. Du bör kanske välja andra datatyper för tabellen som ska skapas, hellre än att välja de som DTS guiden väljer åt dig. Jag väljer alla standardinställningar för datatyper förutom en. För Time kolumnen så ändrar jag standarddatatypen från smalldate till Char(11).
Importera kalkylbladet i Excel till en SQL Server tabell
- När du väl har definierat DTS paketet så kan du spara det. Och efter att du har sparat DTS paketet så kan den köras och importera data från Excel kalkylbladet till en nyskapad tabell.
- Nästa gång du importerar data till tabellen så måste du modifiera DTS paketet så att den lägger till alla nya data till den existerande tabellen, istället för att skapa en ny.
- Nu när alla data ligger i SQL Server för första gången så bör du skapa några Index till din tabell för att höja SQL-satsernas prestanda. Förutom det så är du nu redo att använda dina data som finns i tabellen till vad du än vill göra med dem. Du kan analysera de direkt med hjälp av Transact-SQL, eller så exporterar du dem tillbaka till Excel för att göra din analys.
0 Kommentarer