Använda SQL Server Activity Monitor. Använda prestationsövervakningen för att bestämma flaskhalsarna på hårdvaran som SQL-servern kör de bästa verktygen för övervakning av MS SQL Server

Alla databasadministratör, säkerligen, var tvungen att hantera det faktum att allt fungerar långsamt, eller inte fungerar alls. Det första du behöver ta reda på är att alls hända på SQL Server för tillfället. Det verkar i administratörens arsenal så mycket av alla användbara bitar: en BUVA-aktivitetsmonitor, en massa dynamiska ledningsvyer (DMV), sp_who och sp_who2 lagrade procedurer, som var ärvt sedan SQL Server 7 och SQL Server 2000.
Men låt oss se ...

Övervakningsverktyg

Aktivitetsmonitor

Det verkar, en bra sak, är engagerad i det faktum att det är nödvändigt - aktiviteten övervakas. Jag startar en tung redovisningsrapport och ser vilken aktivitetsmonitor som ska visa mig.
På skärmdumpar Aktivitetsmonitor från SQL Server 2005:

Och från SQL Server Denali (2012) CTP 3.


M-ja. Och om ett dussin människor kommer att lansera sådana rapporter? Och det här är inte ovanligt ... det blir ganska obekväma att förstå, men givetvis framsteg i ansiktet. I Denali Activity Monitor visar det mycket mer användbar information (till exempel på vilken speciell resursförväntning som händer), plus, kan vi till exempel för önskad session, kör en profil direkt från monitorn och spåra den redan i Profiler, men skadar det, det laddas och laddas och laddas och utan den laddade servern. Dessutom finns det redan ett problem med bromsar, och de begär att det vid tidpunkten för att lansera en profiler som redan har börjat utföras, kommer vi inte att se.
Och jag vill se detta - vem och vad gör det nu.

sp_who och sp_who2.

I skärmdumpen utfördes resultatet av exekveringen av SP_WHO (ovanifrån) och SP_WHO2 (botten) under konstruktionen av hela den svåra rapporten:


Ja. Mycket informativ. Titta på Sp_Who kan vi bara se vad som kör något. Naturligtvis utförs det - vi är för det och ser, och vi ser att vissa väljar utförs. Eller några välj "Ov. Bra.
Sp_who2 visar mer information. Nu kan vi se hur mycket processortiden tillbringade sessionen (och kolumnen viks den totala tiden, tydligen), antalet I / O-operationer, namnet på den databas där allt detta utförs och som är blockerat av den här sessionen ( om det är blockerat).
Aktivitetsmonitor, som vi ser, ger mer information.

Dmv

Från och med SQL Server 2005 fick vi en ny möjlighet att få information om statusen för serverns dynamiska ledningsvyer. MSDN säger: "Dynamiska administrativa visningar och funktioner returnera datastatusdata som kan användas för att övervaka serverns instans, problemdiagnostik och prestandainställningar."
Och i 2005: e SQL Server "E finns det en uppsättning synpunkter som är relaterade till utförandet av förfrågningar vid det aktuella ögonblicket (det finns dock också föreställningar för att se" historia "): här är de. Och deras nummer, Version till versionen fortsätter att öka!
Visst har de mastiska administratörerna många skript, så att du kan få information om serverns nuvarande tillstånd, men vad ska man göra om erfarenheten av att arbeta med DMV inte, men det finns redan problem?

sp_whoisactive

Adam Machanic (SQL Server MVP och MCITP) har utvecklat och ständigt blygsam det sp_whooisaktiva lagrade proceduren, som bara är beroende av dessa mest DMV och jävla är lätt att använda. Ladda ner den senaste versionen av sp_whoisactive. På Adam själv finns det en serie artiklar som är dedikerade till sp_whoisactive, bestående av 30 (trettio!) Bitar, du kan läsa den, och jag kommer att försöka intressera dig i att läsa detta material :).
Så vi antar att du hämtade och lanserade det här skriptet på en av testservrarna (på vilken version som helst, från och med 2005 och slutar med Denali). Adam rekommenderar att det finns i mastersystemdatabasen så att den kan ringas in i samband med någon databas, men det är inte nödvändigt, bara när du ringer det i samband med en annan databas måste du skriva namnet helt - BD. sham.sp_whoisactive.
Så försök. I skärmdumpen, resultatet av dess utförande under byggandet av hela samma rapport:

Resultatet av Exec SP_whoisactive-förfrågan, tyvärr, existerar inte i en skärm, så textbeskrivningen av utgången från det lagrade proceduren orsakade utan parametrar.

• - För en aktiv utredning visar exekveringstiden för "sovande" sessionen - "sömn" tid;
• - Egentligen, Spid;
• - Visar texten som för närvarande utförs nu, eller texten till den senast utförda frågan, om sessionen sover;
• - Tja, du förstod;
• - Mycket intressant kolumn. Den visas i format (AX: BMS / CMS / DMS) E. A är antalet väntande uppgifter på E. B / C / D-resursen - det här väntar tid i millisekunder. Om resursen förväntar sig endast en session (som i skärmdumpen) visas dess väntetid om 2 sessioner är deras väntetider i B / C-format. Om du förväntar dig 3 eller mer - kommer vi att se minsta, genomsnittliga och maximala väntetid på den här resursen i B / C / D-format.
• - För en aktiv utredning - den totala tiden för CPU, som spenderas av denna begäran, för en sovsession - den totala tiden för CPU för "Allt liv" i denna session;
• - För en aktiv fråga är detta antalet inspelningsoperationer i TEMPDB under utförandet av frågan. För en sovande session - ett totalt antal poster i Tempdb för all livslängd för sessionen;
• - För en aktiv fråga - Antalet sidor i Tempdb allokeras för denna begäran; För en sovsession - det totala antalet sidor i Tempdb som tilldelades under hela livslängden.
• - Om vi \u200b\u200bplötsligt blockeras av någon, kommer Spid (Session_ID) att visa vem vi är blockerade;
• - för en aktiv fråga - antalet logiska avläsningar som utförs vid genomförandet av denna begäran För en sovande session - antalet läsesidor för all livstid för denna session;
• - allt detsamma, men om rekordet;
• - För en aktiv fråga - antalet fysiska avläsningar som utförs vid utförande av denna begäran För en sovande session - Traditionellt, det totala antalet fysiska avläsningar för hela livets livstid;
• - För en aktiv fråga - Antalet åtta kilobytsidor som används vid genomförandet av denna begäran. För en sovande session - hur många minuter av minnessidor var belysade för hela hennes livstid;
• - Statusen för sessionen utförs, sover, etc.;
• - visar antalet transaktioner av den öppna denna session;
• - visar om det finns ett sådant tillfälle, processen att utföra operation (till exempel backup, återställ), visa aldrig hur mycket procent som exekveras av Select.

De återstående kolumnerna B. standardutgång Sp_whoisactive ser intressant ut, och jag kommer inte att beskriva dem - deras syfte, jag tycker att det är förståeligt för alla (host_name, database_name, program_name, start_time, login_time, bequest_id, collection_time).

Och vad? Det är allt?

Nej, det är inte allt. Jag berättar också om vad (mest intressant och användbart, från min synvinkel) parametrar kan kallas sp_whoisactive och vad som kommer att träna.

• @Help är en hemsk användbar parameter. När du ringer sp_whoisactive @help \u003d 1 får vi information om alla parametrar och utgångskolumner på skärmen. Så om något är oförståeligt, kan du alltid titta på "hjälp"
• @Filter_type och @filter - Låt dig filtrera resultatet av utförandet. @Filter_Type kan acceptera "session", "program", "databas", "Logga in" och "värd". I parametern anger vi vilket objekt med den valda typen som är intresserad av oss. Till exempel vill vi se alla sessioner som körs i masterdatabasen, för detta kallar vi exec sp_whoisactive @filter_type \u003d "databas", \u003d "mästare." Parametern är tillåten att använda "%";
• @NOT_FILTER_TYPE och @NOT_FILTER - Låt oss filtrera "tvärtom". De som till exempel vill se allt, förutom de sessioner som i databasfältet står "master", för detta utför vi exec sp_whoisactive @not_filter_type \u003d "databas", @not_filter \u003d "master". Tja, eller vi vill se att alla användare utom användaren SA ... applikationer kan ställas in. @NOT_FILTER-parametern är tillåten att använda "%";
• @Show_System_spids \u003d 1 - visar information om systemsessioner;
• @Get_Full_INNER_TEXT \u003d 1 - I SQL_TEXT-fältet kommer det inte bara att vara texten i den aktuella förfrågan (Stetiment) i paketet (Batche), och texten i hela Batcher är helt;
• @Get_Plans - Lägg till utgångskolumnen med förfrågningsplaner.
• @Get_transaktion_info \u003d 1 - lägger till utmatning och volym av poster till transaktionsloggar, liksom början av den senaste transaktionen;
• @Get_locks \u003d 1 - lägger till utmatningsinformationen om alla lås som åläggs under utförandet av frågan;
• @Find_Block_Leaders \u003d 1 - kommer att följa låskedjan och visa det totala antalet sessioner som väntar på att låsa upp den aktuella sessionen.
• @Output_column_list \u003d "[%]" - Vad händer om du inte vill se information om tempdb i produktionen av sp_whoisactive? Med denna parameter kan du styra det faktum att det visar;
• @Destination_Table \u003d "table_name" - kommer att försöka infoga resultatet av utförandet för att skriva till bordet, men kommer det här bordet inte att kontrollera om det är tillräckligt för att infoga i det.

Nu alla

Som ett resultat har vi ett annat extremt bekvämt och flexibelt verktyg för att spåra den aktuella aktiviteten på SQL Server. För sin normala drift är det tillräckligt att lösa visningsserverns tillstånd och rätten att vädja till DMV.
Det är också värt att lägga till, i fallet när det är möjligt att bara ansluta till servern

Förteckning över prestanda revisionsfrågor

Ange dina resultat i tabellen ovan.

Använda Performance Monitor (Performance monutor) för att identifiera smala SQL Server-maskinvarufordon

Det är bäst att börja granska prestanda för SQL Server från Performance Monitor (System Monitor). Övervakning av flera huvudmätare i en period av 24 timmar kommer att göra det möjligt för dig att få en ganska bra uppfattning om några viktigaste hårdvaruproblem som påverkar SQL Server-prestanda.

Helst måste du använda prestandakontrollen för att skapa en nyckelmätare läsfil under en period av 24 timmar. Du måste välja en "typisk" 24-timmarsperiod för att skapa en registreringsfil. Välj till exempel en typisk arbetsdag, inte slutet av veckan eller semestern.

Så snart du spelade in prestandaövervakningsdata om 24 timmar i registreringsfilen, visa de rekommenderade mätarna i grafen för prestandaövervakning och skriv sedan ner de genomsnittliga, minsta och maximala värdena i tabellen ovan. När du har gjort det, jämför dina resultat med resultaten av följande analys. Denna jämförelse ger dig möjlighet att bestämma eventuella flaskhalsar av hårdvara som påverkar din SQL-server.

Hur man tolkar Key Performance Monitor Counters

Följande diskuteras av vissa grundläggande prestationsövervakningsdiskar, deras rekommenderade värden och några alternativ som ska hjälpa till att identifiera och lösa hårdvaruproblem. Det bör noteras att jag begränsade antalet prestationsmonitor som behandlas. Detta görs eftersom syftet med denna artikel är att upptäcka de enkla och uppenbara problemen med prestationsförlust. Diskussion om många andra prestandaövervakningsdiskar kan hittas någon annanstans på denna webbplats.

Minne: Sidor / sekunder

Denna mätare mäter antalet sidor per sekund, som återställs från RAM till disk, eller läses i RAM från disken. De mer intensivt sidorna, den större belastningen på I / O-operationer upplevs av din server, som i sin tur kan påverka resultatet av SQL Server negativt. Ditt mål är att försöka minska sidorna till ett minimum utan att eliminera det.

Under antagandet att SQL Server är den enda huvudsakliga applikationen som körs på din server, måste detta nummer helst vara i intervallet mellan noll och 20. Det är mycket troligt att du kommer att observera utsläppen betydligt över 20, vilket är ganska normalt. Det viktigaste här är att behålla den genomsnittliga siddelningen per sekund mindre än 20.

Om din server visar ett genomsnitt på mer än 20 sidor per sekund är en av de mest sannolika orsakerna till detta bristen på nödvändig ram. I allmänhet är det mer RAM-objektet, desto mindre bör utbytesverksamheten utföras.

I de flesta fall, på en fysisk server som specialiserat sig på SQL-servern, med en tillräcklig mängd RAM, kommer det genomsnittliga siddelningsvärdet att vara mindre än 20. Ett tillräckligt antal RAM för SQL-servern kan definieras enligt följande kriterium: servern Måste ha en framgångsrik koefficient till buffertcachen (bufferthöjd cache-förhållande) 99% och högre. Denna mätare beskrivs nedan i den här artikeln. Om du har SQL Server, som har ett värde på 99% eller högre inom 24 timmar, men du får den genomsnittliga sidan som delas mer än 20 under samma tid, kan det indikera att du kör och andra. Ansökningar om det fysiska Server förutom SQL Server. Om så är fallet måste du helst ta bort dessa program, så att SQL Server kan vara den enda huvudsakliga applikationen på den fysiska servern.

Om din SQL-server inte utför några andra applikationer, och sidobytet överstiger 20 i genomsnitt inom 24 timmar, kan det innebära att du har ändrat inställningarna för SQL Server-minnet. SQL-servern måste konfigureras så att alternativet "Dynamiskt konfigurera SQL Server-minne" är inställt (dynamiskt konfigurera SQL Server-minne), och den maximala minnesinstallationen måste vara i det största värdet. För optimalt arbete måste SQL-servern ta det så många RAM som det krävs för sina egna behov, utan att uppleva behovet av att konkurrera om snabbt minne med andra applikationer.

Minne: Tillgängligt utrymme

Ett annat sätt att ta reda på om din SQL-server har tillräckligt med fysiskt minne, är att kontrollera minnesobjektet: tillgängliga byte. Dess värde måste vara mer än 5 MB. Annars behöver din SQL-server ett större antal fysiska minne. På en server specialiserad på SQL Server försöker den senare att hålla från 4-10 MB gratis fysiskt minne. Den återstående fysiska RAM används av operativsystemet och SQL-servern. När mängden tillgängligt minne är nära 5 MB eller lägre är det troligt att SQL Server upplever överbelastning på grund av brist på minne. Om så är fallet måste du öka antalet fysiska ram på servern, minska belastningen på servern eller ändra inställningarna för att konfigurera minneskonfigurationen av din SQL-server.

Fysisk disk: Disktid

Denna räknare visar hur upptagen är den fysiska diskmatrisen (inte en logisk sektion eller separat disk i arrayen). Det ger en bra relativ mått på hur upptagen dina diskarrayer är.

Som en empirisk regel bör disktidsräknaren visa mindre än 55%. Om mätvärdena överstiger 55% under kontinuerliga perioder (över 10 minuter för din 24 timmars övervakning), kan din SQL-server uppleva problem med I / O-operationer. Om du bara tittar på detta beteende ibland under din 24 timmars övervakning, skulle jag inte oroa mig för mycket, men om det hände ofta (låt oss säga, flera gånger i timmen), skulle jag börja leta efter sätt att öka prestanda för I / O Operationer på servern eller minska serverns laddning. Vissa metoder för att öka diskingången / utgången består av att lägga till nya skivor i en array (om möjligt), byte av skivorna till snabbare och lägga till cache på styrkortet (om möjligt), med olika versioner av RAID eller installera en snabbare styrenhet.

Innan du använder den här mätaren under NT 4.0 måste du manuellt aktivera den genom att ange följande: "Diskperf-y" i kommandotolken. Därefter måste du starta om din server. Således är det nödvändigt att omedelbart innefatta skivdiskar under Windows NT 4.0. Om du arbetar under Windows 2000 är den här mätaren aktiverad som standard.

Fysisk disk: Den genomsnittliga längden på skivkön

Förutom att observera mätarens värde, är "fysisk disk: disk driftstid", det är också önskvärt att övervaka värdena på skivkön (avg. Diskkö längd). Om detta värde överstiger värdet 2 för kontinuerliga perioder (över 10 minuter under din 24-timmarsövervakning) för varje enhet i matrisen, kan den här arrayen visa sig vara en flaskhals av systemets prestanda. Som en körtidsdisk, om det inträffar ibland över 24 timmars övervakningsperiod, skulle jag inte oroa mig, men om det händer ofta, skulle jag börja leta efter sätt att öka prestanda för serveringången / utgångssystemet, som beskrivet ovan.

Du måste beräkna den här indikatorn, eftersom Performance Monitor inte vet hur många fysiska diskar är i din matris. Om du till exempel har en grupp av 6 fysiska skivor, och den genomsnittliga kölängden är 10 för den här matrisen, är det faktiska medelvärdet av skivkön för varje skiva 1,66 (10/6 \u003d 1,66), vilket är väl passande in i den rekommenderade indikatorn 2 per en fysisk disk.

Innan du använder den här mätaren under NT 4.0, glöm inte att manuellt slå på den, skriv in inbjudan för att komma in i NT-kommandon, följande: "Diskperf-y" med den efterföljande omstart av din server. Därför måste du inkludera skivräknare omedelbart efter installationen av Windows NT 4.0. Om du använder Windows 2000, kommer den här mätaren att aktiveras som standard.

Använd både mätaren som beskrivs ovan för att ta reda på om din server upplever problem med I / O-systemet. Om du till exempel ser många perioder under vilken skivtiden är mer än 55%, och när den genomsnittliga diskkö längden är mer än 2 per fysisk disk kan du vara säker på att servern har problem med ingångssystemet.

Processor: Processor Tid%

Processorobjekt:% Processor Time Meter är tillgänglig för varje central processor och utvärderar användningen av varje enskild CPU. En liknande mätare är också tillgänglig för hela totalen av centrala processorer (totalt). Detta är en nyckelmätare för att spåra användningen av den centrala processorn. Om den totala processorns laddningstid på denna mätare överstiger 80% under kontinuerliga perioder (över 10 minuter i 24 timmars övervakning), kan du överväga den centrala processorn med ett smalt system. Om dessa perioder av stark belastning uppstår ibland, och du tror att du kan acceptera det, är allt i ordning. Men om de uppträder ofta bör du överväga sådana alternativ för att minska serverns belastning, som förvärvet av snabbare centrala processorer, installation av fler centrala processorer eller förvärv av centrala processorer som har en större inbyggd cache ( L2).

System: Processor Queue längd

Tillsammans med en processortidsräknare bör du också styra processorns könlängdsräknare (processorkö längd). Om denna indikator överstiger värdet av 2 till en central processor under kontinuerliga perioder (över 10 minuter under din 24-timmars övervakningsperiod) är det troligt att detta är ett smalt system av systemet. Om du till exempel har 4 centrala processorer på din server, bör processorns kötslängd inte överstiga ett totalt värde av 8.

Om processorns könlängden regelbundet överstiger det rekommenderade maximala, men användningen av en central processor är inte så hög (vilket är ett typiskt fall), tänke alternativet att reducera värdet på konfigurationsparametern för SQL Server "( Maximalt antal trådar). En möjlig orsak till ett högt värde av processorns kötslängd är närvaron av ett alltför stort antal arbetstagare som väntar på sin tur. Genom att minska deras nummer som du gör med den här parametern styrker det att använda trådarnas stammar (om det inte äger rum) eller öka sin roll.

Använd båda beskrivna meter tillsammans för att bestämma exakt om det finns problem med den centrala processorn. Om båda indikatorerna överstiger de rekommenderade värdena under samma kontinuerliga tidsperioder kan du vara säker på att den centrala processorn är en svag punkt i systemet.

SQL Server Buffer: Framgångsrik åtkomstkoefficient till buffert cache

Denna meter (SQL Server Buffer: Buffer Cache Hit-förhållande) visar hur ofta SQL-servern refererar till bufferten och inte till hårddisken för att få data. I OLTP-applikationer måste denna koefficient överstiga 90% och är idealiskt över 99%. Om din framgångsrik kontaktkoefficient med buffert cache är under 90%, ska du gå och köpa mer RAM redan idag. Om denna koefficient ligger inom intervallet mellan 90% och 99%, bör du seriöst överväga köpoptionen för ytterligare RAM, eftersom ju närmare du närmar dig 99%, desto snabbare kommer din SQL-server att fungera. I vissa fall, om din databas är väldigt stor, kommer du inte att kunna komma närmare 99%, även om du lägger det maximala tillåtna antalet RAM på din server. Då är allt du kan göra lägg till minne till det maximala och acceptera det befintliga läget för saker.

I OLAP-applikationer kan koefficienten vara mycket mindre på grund av arten av denna OLAP-applikation. Under alla omständigheter måste ökningen av RAM påskynda SQL Server-operationen.

SQL Server: Anpassade anslutningar

Eftersom antalet användare av SQL-servern påverkar dess prestanda rekommenderas det att övervaka anpassade anslutningar (SQL Server General Statistics-objekt: Användaranslutningsräknare). Det visar antalet användaranslutningar, och inte antalet användare som är anslutna till SQL-servern för tillfället.

Om läsningarna av denna räknare överstiger 255, bör du öka värdet på "Maximal arbetstråds" -konfigurationsparametern (maximalt antal arbetslådor), vars standardvärde är 255. Om antalet anslutningar överstiger det befintliga antalet Arbetsgängor, SQL-servern börjar dela de arbetstrådar som kan påverka prestanda negativt. Inställning av denna parameter ska vara högre än det maximala antalet anslutningar som kan uppnås på din server.

Vad kommer härnäst

Även om det finns ett mycket större antal räknare än de som vi har ansett är de sistnämnda nyckeln till övervakningen, som utförs i processen med revisionsprestanda. Efter att ha slutfört prestandaövervakningsanalysen, använd rekommendationerna och sedan i den här serien av artiklar för att göra de nödvändiga ändringarna som gör att din SQL-server kommer att fungera som den ska.

Alla databasadministratör, säkerligen, var tvungen att hantera det faktum att allt fungerar långsamt, eller inte fungerar alls. Det första du behöver ta reda på är att alls hända på SQL Server för tillfället. Det verkar i administratörens arsenal så mycket av alla användbara bitar: en BUVA-aktivitetsmonitor, en massa dynamiska ledningsvyer (DMV), sp_who och sp_who2 lagrade procedurer, som var ärvt sedan SQL Server 7 och SQL Server 2000.
Men låt oss se ...

Övervakningsverktyg

Aktivitetsmonitor

Det verkar, en bra sak, är engagerad i det faktum att det är nödvändigt - aktiviteten övervakas. Jag startar en tung redovisningsrapport och ser vilken aktivitetsmonitor som ska visa mig.
På skärmdumpar Aktivitetsmonitor från SQL Server 2005:

och från SQL Server Denali (2012) CTP 3.


M-ja. Och om ett dussin människor kommer att lansera sådana rapporter? Och det här är inte ovanligt ... det blir ganska obekväma att förstå, men givetvis framsteg i ansiktet. I Denali Activity Monitor visar det mycket mer användbar information (till exempel på vilken speciell resursförväntning som händer), plus, kan vi till exempel för önskad session, kör en profil direkt från monitorn och spåra den redan i Profiler, men skadar det, det laddas och laddas och laddas och utan den laddade servern. Dessutom finns det redan ett problem med bromsar, och de begär att det vid tidpunkten för att lansera en profiler som redan har börjat utföras, kommer vi inte att se.
Och jag vill se detta - vem och vad gör det nu.

sp_who och sp_who2.

I skärmdumpen utfördes resultatet av exekveringen av SP_WHO (ovanifrån) och SP_WHO2 (botten) under konstruktionen av hela den svåra rapporten:


Ja. Mycket informativ. Titta på Sp_Who kan vi bara se vad som kör något. Naturligtvis utförs det - vi är för det och ser, och vi ser att vissa väljar utförs. Eller några välj "Ov. Bra.
sp_who2 visar mer information. Nu kan vi se hur mycket processortiden tillbringade sessionen (och kolumnen viks den totala tiden, tydligen), antalet I / O-operationer, namnet på den databas där allt detta utförs och som är blockerat av den här sessionen ( om det är blockerat).
Aktivitetsmonitor, som vi ser, ger mer information.

Dmv

Från och med SQL Server 2005 fick vi en ny möjlighet att få information om statusen för serverns dynamiska ledningsvyer. MSDN säger: "Dynamiska administrativa representationer och funktioner returnera serverstatusdata som kan användas för att styra serverns instans, problemdiagnostik och prestandainställningar."
Och i den 2005: e SQL Server "E finns det en uppsättning synpunkter som är relaterade till utförandet av förfrågningar vid det aktuella ögonblicket (dock för att visa" historien "finns det också föreställningar): Här är de. Och deras nummer, från Version till versionen fortsätter att öka!
Visst har de mastiska administratörerna många skript, så att du kan få information om serverns nuvarande tillstånd, men vad ska man göra om erfarenheten av att arbeta med DMV inte, men det finns redan problem?

sp_whoisactive

Adam Machanic (SQL Server MVP och MCITP) har utvecklat och ständigt blygsam det sp_whooisaktiva lagrade proceduren, som bara är beroende av dessa mest DMV och jävla är lätt att använda. Ladda ner den senaste versionen av sp_whoisactive. På Adam själv finns det en serie artiklar som är dedikerade till sp_whoisactive, bestående av 30 (trettio!) Bitar, du kan läsa den, och jag kommer att försöka intressera dig i att läsa detta material :).
Så vi antar att du hämtade och lanserade det här skriptet på en av testservrarna (på vilken version som helst, från och med 2005 och slutar med Denali). Adam rekommenderar att det finns i mastersystemdatabasen så att den kan ringas in i samband med någon databas, men det är inte nödvändigt, bara när du ringer det i samband med en annan databas måste du skriva namnet helt - BD. sham.sp_whoisactive.
Så försök. I skärmdumpen, resultatet av dess utförande under byggandet av hela samma rapport:

Resultatet av Exec SP_whoisactive-förfrågan, tyvärr, existerar inte i en skärm, så textbeskrivningen av utgången från det lagrade proceduren orsakade utan parametrar.

• - För en aktiv förfrågan visar den tidpunkten för utförandet, för "sovande" sessionen - tiden "sova";
• - Egentligen, Spid;
• - Visar texten som för närvarande utförs nu, eller texten till den senast utförda frågan, om sessionen sover;
• - Tja, du förstod;
• - Mycket intressant kolumn. Den visas i format (AX: BMS / CMS / DMS) E. A är antalet väntande uppgifter på E. B / C / D-resursen - det här väntar tid i millisekunder. Om resursen förväntar sig endast en session (som i skärmdumpen) visas dess väntetid om 2 sessioner är deras väntetider i B / C-format. Om du förväntar dig 3 eller mer - kommer vi att se minsta, genomsnittliga och maximala väntetid på den här resursen i B / C / D-format.
• - För en aktiv utredning - den totala tiden för CPU, som spenderas av denna begäran, för sovsessionen - den totala tiden för CPU för "All Life" i denna session;
• - För en aktiv fråga är detta antalet inspelningsoperationer i TEMPDB under utförandet av frågan. För en sovande session - ett totalt antal poster i Tempdb för all livslängd för sessionen;
• - För en aktiv fråga - Antalet sidor i Tempdb allokeras för denna begäran; För en sovsession - det totala antalet sidor i Tempdb som tilldelades under hela livslängden.
• - Om vi \u200b\u200bplötsligt blockeras av någon, kommer Spid (Session_ID) att visa vem vi är blockerade;
• - för en aktiv fråga - antalet logiska avläsningar som utförs vid genomförandet av denna begäran För en sovande session - antalet läsesidor för all livstid för denna session;
• - allt detsamma, men om rekordet;
• - För en aktiv fråga - antalet fysiska avläsningar som utförs vid utförande av denna begäran För en sovande session - Traditionellt, det totala antalet fysiska avläsningar för hela livets livstid;
• - För en aktiv fråga - Antalet åtta kilobytsidor som används vid genomförandet av denna begäran. För en sovande session - hur många minuter av minnessidor var belysade för hela hennes livstid;
• - Statusen för sessionen utförs, sover, etc.;
• - visar antalet transaktioner av den öppna denna session;
• - visar om det finns ett sådant tillfälle, processen att utföra operation (till exempel backup, återställ), visa aldrig hur mycket procent som exekveras av Select.

De återstående kolumnerna B. standardutgång Sp_whoisactive ser intressant ut, och jag kommer inte att beskriva dem - deras syfte, jag tycker att det är förståeligt för alla (host_name, database_name, program_name, start_time, login_time, bequest_id, collection_time).

Och vad? Det är allt?

Nej, det är inte allt. Jag berättar också om vad (mest intressant och användbart, från min synvinkel) parametrar kan kallas sp_whoisactive och vad som kommer att träna.

• @Help är en hemsk användbar parameter. När du ringer sp_whoisactive @help \u003d 1 får vi information om alla parametrar och utgångskolumner på skärmen. Så om något förblir obegripligt, kan du alltid se "hjälp"
• @Filter_type och @filter - Låt dig filtrera resultatet av utförandet. @Filter_Type kan acceptera "session", "program", "databas", "Logga in" och "värd". I @filterparametern anger vi vilket föremål för den valda typen av typ som intresserar oss. Vi vill till exempel se alla sessioner som körs i huvuddatabasen, för detta kallar vi exec sp_whoisactive @filter_type \u003d "databas", @filter \u003d "master". @Filterparametern är tillåten att använda "%";
• @NOT_FILTER_TYPE och @NOT_FILTER - Låt oss filtrera "tvärtom". De. Till exempel vill vi se allt, förutom de sessioner, som i "databas" -fältet är "master", för detta, exekvera exec sp_whoisactive @not_filter_type \u003d "databas", @not_filter \u003d "master". Tja, eller vi vill se att alla användare utom användaren SA ... applikationer kan ställas in. @NOT_FILTER-parametern är tillåten att använda "%";
• @Show_System_spids \u003d 1 - visar information om systemsessioner;
• @Get_Full_INNER_TEXT \u003d 1 - I SQL_TEXT-fältet kommer det inte bara att vara texten i den aktuella förfrågan (Stetiment) i paketet (Batche), och texten i hela Batcher är helt;
• @Get_Plans - Lägg till utgångskolumnen med förfrågningsplaner.
• @Get_transaktion_info \u003d 1 - lägger till utmatning och volym av poster till transaktionsloggar, liksom början av den senaste transaktionen;
• @Get_locks \u003d 1 - lägger till utmatningsinformationen om alla lås som åläggs under utförandet av frågan;
• @Find_Block_Leaders \u003d 1 - kommer att följa låskedjan och visa det totala antalet sessioner som väntar på att låsa upp den aktuella sessionen.
• @Output_column_list \u003d "[%]" - Vad händer om du inte vill se information om tempdb i produktionen av sp_whoisactive? Med denna parameter kan du styra det faktum att det visar;
• @Destination_Table \u003d "table_name" - kommer att försöka infoga resultatet av utförandet för att skriva till bordet, men kommer det här bordet inte att kontrollera om det är tillräckligt för att infoga i det.

Nu alla

Som ett resultat har vi ett annat extremt bekvämt och flexibelt verktyg för att spåra den aktuella aktiviteten på SQL Server. För sin normala drift är det tillräckligt att lösa visningsserverns tillstånd och rätten att vädja till DMV.
Det är också värt att lägga till, i fallet när det är möjligt att bara ansluta till servern

Denna programvara är Sybase, arbetar med SQL Server och utfärdar en mängd information om serverns prestanda i grafisk form. Denna information är exceptionellt användbar när man analyserar orsakerna till att dess prestanda analyseras.

version 11.0.1 har ett antal nya viktiga möjligheter som avsevärt skiljer den nya versionen från alla tidigare. 11.0.1 Kan arbeta med någon version av SQL Server, som börjar med 4.9.2 och slutsystemet 11.

Men några av de mest intressanta typerna av information om användningen av databasobjekt och serverns interaktion med nätverket utfärdas endast när det övervakas SQL Server-systemet 10 och System 11. Naturligtvis data om driften av de namngivna cachebuffertarna utfärdas endast vid kontroll av prestanda för SQL Server-systemet 11.

För kompatibilitet med tidigare versioner 11.0.1 stöder också sättet att utfärda statistisk information om serverns prestanda till filer som kan användas för efterföljande jämförelse och analys. Denna möjlighet är mycket användbar i praktiken, men användningen komplicerar installationsprocessen.

den består av två komponenter: En servermodul som körs på en enda maskin med SQL Server för att ge tillgång till det delade serverns minnesområdet och en klientmodul som kan arbeta på vilken dator som helst. Kundmodulens huvuduppgift läser information som ackumuleras av serverns modul och dess presentation av användaren i grafisk form.

När du startar måste du avbryta serverns check som utförs av DBCC-memusage-kommandot, eftersom det här kommandot saktar signifikant ner serverns operation. För att göra detta, när du startar SQLMON (klientmodul), måste du ange NOMEM-parametern.

Standardkonfigurationen ger samtidig anslutning till fem klientmoduler till en servermodul. Med andra ord kan den ansluta till en servermodul eller fem klientmoduler med ett fönster på varje klient, eller en klient med fem öppna fönster.

Det maximala antalet på samma gång öppna klienter är installerat när serverns modul startas.

Således, för att stödja 20 fönster i kommandofilen i serverns modul, måste du ange parametern P2 0. Detta kommer att kräva en ändring av adressen till det valda serverns minnesområdet med hjälp av BuildMaster-kommandot och några andra åtgärder. Dessa åtgärder kan inte utföras under SQL Server-operationen. (Detaljer om processen att expandera antalet samtidigt stödda klienter, se serverns supplementservermodul.)

det har några nackdelar. Till exempel kan ett stapeldiagram som visar antalet I / O-operationer och andra egenskaper hos serverenheter som kan rapportera data samtidigt med begränsat enhetsnummer.

Detta är obekvämt när du övervakar en stor server med ett stort antal serverenheter. Dessutom kan användaren inte välja enheter, information som kommer att ingå i diagrammet, såväl som växla mellan olika uppsättningar av enheter.

Textbordet visas på skärmen samtidigt med diagrammet innehåller en lista över alla serverns enheter, men innehåller endast det totala antalet I / O-operationer för var och en av dem. Detta gör det särskilt svårt att arbeta med en stor server, där många serverns enheter som stöder användardatabasegmenten har skapats för att öka prestanda. I det här fallet är analysen av arbetet med alla tillgängliga segment omöjligt.

också tillåter inte en lång tid att visa dynamiken i förändringar i prestandaindikatorer.

Den kan skicka in data på skärmen för 60 på varandra följande prestationsmätningsintervaller. Beroende på den valda varaktigheten av varje intervall kan sådan statistik täcka en ganska stor tidsperiod. Men det här mottagandet gör det inte möjligt att jämföra de aktuella data med indikatorer på en månads- eller årlig begränsning.

Naturligtvis kan bilderna av programmiften utfärdas till skrivaren, men då måste du lagra filuppsättningar eller bergsutskrifter för att utvärdera framtida serverns prestanda. I praktiken måste serverns administratör ofta se de data som erhållits under olika perioder av bolagets konjunkturcykel, samt jämföra information om samma period av seriella konjunkturcykler för att få en uppfattning om serverns verkliga prestanda .

Eftersom lanseringen leder till en single Server-avmattning, före mätningens början, är det nödvändigt att bestämma värdet av denna avmattning för en viss hårdvaru- och mjukvaruplattform. En bra mätmetod är utförandet av en standarduppsättning av testtransaktioner.

Den kan användas både i närvaro och i avsaknad av på serverns maskin. Även om det inte finns några klientmoduler fortsätter programservermodulen sin operation, och den måste stoppas med ett separat kommando.

gör det möjligt att producera flera, olika grafiska fönster på skärmen, som alla innehåller information om en specifik aspekt av serverns funktion.

Huvudfönster (huvudfönster)
Den innehåller en lista över Windows som stöds av programmet. I händelse av att när SGLMON-klientmodulen startar, var NOMEM-parametern inte specificerad, det kretsschema över serverns minne kommer också att utfärdas i det här fönstret.

Cachebuffertar (cache)
I det här fönstret utfärdas grafer, kännetecknar arbetsverket av cachebuffertar av förfaranden och data. Genom att styra antalet fysiska och logiska I / O-operationer i databufferten kan användaren bestämma vilken del av data till datasidorna som ska utföras med hjälp av sidor som redan finns i bufferten. En sådan statistik som erhålles av databufferten och procedurbufferten gör att du kan bestämma den totala mängden minne som krävs av servercachebuffertarna och förhållandet mellan databuffertarna och förfarandena.

Cache buffertdata endast för SQL Server-system 11 (Data Cach)
Fönstret rapporterar antalet fysiska och logiska I / O-operationer för var och en av de namngivna cachebuffertarna som är konfigurerade på servern.

Diskingång / utgång (enhet I / O)
Här är grafik och sammanfattande tabeller på det aktuella och fullständiga antalet överklaganden till diskarna. De hjälper till att optimera I / O Load Distribution bland tillgängliga serverns enheter. Vid analys av den utfärdade informationen är det användbart att använda standarddiagrammet för att välja namnen på serverns enheter med namn på motsvarande partitioner av fysiska diskar, eftersom du måste veta hur var och en av dessa enheter är ansluten till vilken diskregulator.

Arbeta med nätverket, endast för SQL Server-systemet 10 och 11 (nätverksaktivitet)
Fönstret rapporteras till statistisk information om nätverksinmatning "-utmatning - storleken på förpackningarna, trafikvolymen etc.

Lås åtkomst till objekt endast för SQL Server-systemet 10 och 11 (objektlåsstatus)
Det ger information om blockering av data till datatabeller, inklusive en detaljerad distribution av de typer av lås som används, namnen på de processer som håller låset etc.

Introduktion av objektsidor endast för SQL Server System 10 och 11 (Objekt I / O)
Fönstret innehåller information om intensiteten hos I / O-portar på en av serverdatabellerna. Var uppmärksam på effektiviteten när du utarbetar en lista över de vanligaste servertabellerna. Sådan information utfärdas inte av SP_SYSON-proceduren.

Prestationsumman (prestanda)
Här presenteras en allmän bild av SQL Server-funktionen - procentandelen av processorns tid presenteras, mängden transaktion som behandlas per sekund, mängden nätverkstrafik, disk I / O, liksom intensiteten av användningen av lås .

Dynamik av prestationsindikatorer (prestandadrend)
Kontinuerliga grafer av de tidsbegränsade indikatorerna som utfärdas i fönstret Prestationsöversikt är byggda i fönstret.

Serverprocessaktivitet (processaktivitet)
Fönstret kan du välja en eller flera serverprocesser och följ användningen av processorn och I / O-volymerna för var och en av processerna.

Detaljerade processuppgifter (processdetaljer)
Fönstret innehåller detaljerad information om den valda serverprocessen.

Processlista (Processlista)
Fönstret innehåller en lista över alla tillgängliga serverprocesser som indikerar deras status. Mycket likmeddelandet av kommandot Sp_who Server.

Med hjälp av lås (processlåsaktivitet)
Fönstret utfärdar information om hur du använder låserna till den serverprocess du valt.

Använda lagrade procedurer (lagrad proceduraktivitet)
Fönstret innehåller information om utförandet av lagrade procedurer och driftstiden för varje procedur.

Transaktionstransaktion (Transaktionsaktivitet)
I fönstret kan du se ett kolumndiagram som visar mängden transaktionsbehandlad distribution av olika typer av transaktioner. Du kan till exempel se vilken del av transaktionerna kan göras med hjälp av uppdateringsmekanismen på plats (uppdatering på plats).

12.26.2006 Kevin kine

Vilken fråga minst vill du få databasadministratören? Förmodligen ett meddelande från användaren om försämringen av ansökan eller frågan om vad som hände med databasen. Det är nödvändigt att skjuta upp alla fall och gå till "Nödläge", gissa, oavsett om det är länge. Eftersom ett av databasadministratörens huvudansvar är att säkerställa den kvalitativa funktionen av industriella databaser, förblir det bara att snabbt eliminera störningen. Dags att ta reda på orsaken till misslyckandet, som regel, nej.

Mer ingen Avrals - bara systematisk observation

Men är det det enda som kan göras? Det är möjligt att genomföra proaktiv övervakning, ett enkelt förvaltningsförfarande som använder definitionen av de grundläggande parametrarna för systemet, mottagande standarder och kontinuerlig observation. I den här artikeln ska jag berätta för hur du tillämpar proaktiv övervakning och hur du skapar ett gratis styrsystem med Windows System Monitor.

Proaktiv övervakning

Proaktiv prestandaövervakning är ett enkelt system som låter dig lösa problem innan de blir kritiska. Någon har förmodligen redan observation av exceptionella situationer när automatiserade processer skapas som märker endast avvikelser från normen, men ger inte djup information och ger inte möjligheter att förhindra problem. Proaktiv prestandaövervakning, tvärtom, ger användaren alla möjliga information på arbetsmiljön och applikationerna och kortsiktiga och långsiktiga. Läsningarna av databasegenskaperna tas bort, referensmätningar är inställda och det aktiva övervakningsläget stöds.

Som namnet antyder kräver den proaktiva prestandaövervakningen åtgärder. Det är nödvändigt att spendera lite tid på installationen och lite tid att förstå databaser och applikationer. För att den proaktiva prestationsövervakningen ska vara effektiv måste du visa meddelanden, så det är möjligt att använda omfattande samlade data.

Grundläggande parametrar, Standard, Monitor

Låt oss börja med definitionen av flera termer. Baslinjeparametrar (baslinje) - Detta är en uppsättning parametrar som visar serverbeteende och applikationer under normala förhållanden. De grundläggande parametrarna erhålls som medelvärdet för resultaten av flera mätningar gjorda under samma betingelser; De är referensriktlinjer.

Benchmark Visar systemets prestanda på en viss nivå av serverbelastning, vilket gör att du kan jämföra en industriell server på en sådan nivå och bestämma serverindikatorerna hur mycket de är högre eller under normen (dvs när servern fungerar dåligt). Precis som med de grundläggande parametrarna avlägsnas värdena för standarder i en kontrollerad miljö, nyckelvärden bestäms i förhållande till fördefinierade indikatorer. Om du behöver se hur servern och programmet är uppförda på flera nivåer eller nedladdningstyper, erhålls vanligtvis flera referensvärden (med avseende på de grundläggande parametrarna).

Övervakning (övervakning) - Detta är en planerad övervakning i realtidsservern på fördefinierade förhållanden (uppsättningar av villkor som definieras för ytterligare forskning eller varningar). Om du till exempel behöver ta reda på hur mycket tid det tar ett bra utförande av en viktig affärsansökan, hur länge är säkerhetskopiering och när vissa prestationsvärden uppnåtts, övervakas observation.

Nu kommer vi att hantera proaktiv övervakning. Du kan använda produkter från tredje part eller en gratis lösning som använder System Monitor. Beslut av tredje parts företag kan förenkla processen att justera proaktiv övervakning och har andra funktioner än de som kan ge en gratis inbäddad lösning. Men innan du börjar, visar jag hur du fortsätter att utföra proaktiv övervakning med systemmonitor.

Steg 1: Bestäm de grundläggande prestandamålarna.

I det första steget för att säkerställa kontrollläget för den proaktiva övervakningen etableras en uppsättning grundläggande parametrar i databasservern. Den här inställningen indikerar serverns prestanda under normala förhållanden, hjälper till att dokumentera och förstå alla viktiga bakgrundsprocesser, bidrar också till att ange situationer som inte kräver insatser för att inte vara uppmärksam på dem. Med andra ord kan databasadministratörer bestämma alternativen för att ignorera systemmeddelanden, eftersom annat ett stort antal falska anmälningar bildas.

För att visuellt visa kvaliteten på funktionerna använder de bästa grundläggande parametrarna några grafer (idealiskt en) så att du vid första anblicken kan se hur servern fungerar. När grundläggande parametrar definieras måste du göra följande. Välj först ett alternativ för att spara prestanda data i systemloggen eller visning av realtid. Perfekt att ha båda möjligheterna: Registreringsloggar gör det möjligt för dig att återvända till läsningar när som helst för att analysera vilken produktivitet som var när den direkta övervakningen av systemet inte genomfördes. Realtidsövervakning upptar inte ett arbetsutrymme på disken och serverns resurser, men kräver ett system med 100 procent av uppmärksamhet. För det andra är det nödvändigt att bestämma det intervall genom vilket observation kommer att utföras, med tanke på kostnaderna för prestanda för datainsamling och I / O-operation och utvärdera kostnaderna för det önskade utrymmet. Ju större intervallet desto högre sannolikhet för att produktivitetsdata du är intresserad av kommer inte att erhållas. Och Slutligen väljer du lokal eller fjärrövervakning. Lokal övervakning där övervakningsprocessen använder en kontrollerad server, lägger till icke-producerande kostnader till processorn och serverskivan. Fjärrövervakning som använder en separat server kan bli av med sådana problem, men det ökar kraftigt arbetsbelastningen på nätverket.

I listade systemmonitor eller räknare som rekommenderas att användas för att bestämma de grundläggande parametrarna. Jag kan inte säga vad värdet är "korrekt" i samband med en separat applikation, eftersom den varierar från systemet till systemet. Använd medelvärdet för olika grundläggande parametrar för att installera den vanliga standarden (med basparametrar) och ange att det här alternativet är korrekt för operativsystemet.

Definiera grundläggande parametrar med hjälp av systemmonitor

Nu för att samla grundläggande parametrar, samtalssystemskärm. Öppna kontrollpanel, administrativa verktyg, prestanda. Dubbelklicka på prestanda loggar och varningar på den vänstra rutan. Tryck på höger knapp på Counter Logs och ange nya logginställningar. Ange namnet på grafen och klicka sedan på OK. I dialogrutan Välj räknare väljer du den första räknaren och klickar sedan på Lägg till. Upprepa dessa operationer tills alla räknare läggs till och klicka sedan på Stäng.

Till att börja med, prova standard 15-sekunders intervall. Eller välj ett annat intervall genom att trycka på egenskaper (eller använd kortkommandot CTRL + Q), och ange sedan värdet under tecknet av provet automatiskt varje: _ sekunder. Längre intervall upptar mindre utrymme, men de ger mindre detaljerade data.

Välj tabellen Logfiler och bestäm den plats där data lagras. Det är möjligt att visa data senare med visning av visningslogfilen. Systemmonitorn kommer att se ut på skärmen 1 när den samlar in data för grundläggande prestanda parametrar. Det kan ses att när du spårar en mängd olika mätare kan du samla mycket data, så du bör noga välja meter för huvudlinjen.

Steg 2: Inställning av referensvärden

När de grundläggande serverns prestandaparametrar är installerade kan du börja installera referensvärden, vilket gör det lättare att förstå serverns prestanda när du arbetar i flera förutbestämda situationer.

För standarder används samma övervakningsläge för att bestämma de grundläggande parametrarna. Du kan använda din lösning eller ett av de vanliga industriverktygen, till exempel TPC-C eller SAP, men de bästa resultaten av beräkningen av referensvärden erhålls när de utvecklar konventionella enskilda scenarier, som är konfigurerade att använda en specifik databasserver och dess tillämpningar.

Du kan skapa ditt eget scenario med hjälp av T-SQL Script Set, OSQL Utilities eller Query Analyzer, SQL Profiler och System Monitor. Utveckling av lasttestscenarier i T-SQL tar vanligtvis flera dagar. Ännu mer tid det kan vara nödvändigt att samla utförandet av belastningstest och analysen av de erhållna data.

Efter att ha bestämt de grundläggande parametrarna för serverns prestanda med förutbestämda belastningar kommer det att vara möjligt att veta vad som kan förväntas från systemet. Använd de data som samlats in vid mottagande av referensvärden för att utgöra grunden för den planerade observationen. Det visade sig till exempel att servern kan ge upp till 249 transaktioner per sekund, innan arbetet börjar sakta ner. I det här fallet kan du installera en anmälan med låg prioritet när servern når nedladdningen cirka 200 TPS och anmälan med hög prioritet när servern når 235 TPS. Med denna metod kan administratören lära sig om möjliga problem med servern och vidta nödvändiga åtgärder innan användarna märker något. Och inga kritiska situationer. Nu är det möjligt.

Steg 3: Planerad övervakning

Kanske är den viktigaste delen av det proaktiva övervakningsläget planerat övervakning. Utan det är det omöjligt att följa databasens funktion eller upptäcka problem i prestanda.

Du kan skapa ett billigt verktyg för övervakning av SQL Server med en kombination av SQL Server Agent och System Monitor. SQL Server Agent gör att du kan bestämma vilken evenemangsutgång till bildskärmen, som mottar ett fel om händelser och skickar automatiskt en anmälan när en felhändelse visas.

Installera SQL Server Agent kan vara lång tid och utmanande, så det är nödvändigt att hänvisa till varningar Beskrivning avsnitt i SQL Server Böcker online (BOL). SQL Server Agent utför typiskt den aktuella kontrollen av databasserverfelmeddelandena och styra inte utförandet.

Systemmonitor används för att övervaka serverns prestanda för att övervaka aktuella mätare (ange undersökningsfrekvensen upp till 15 minuter).

Minnesidor / sek

Nätverksgränssnitt-byte Totalt / sek

Fysisk disk-disköverföringar / sek

Processor-% processor tid

SQLServer: Access Methodes-Full Scans / Sec

SQLServer: Buffer Manager-Buffer Cache Hit-förhållande

SQLServer: Databaser Ansökningsdatabas-transaktioner / sek

SQLServer: Allmän statistik - Användaranvändningar

SQLServer: Latches-genomsnittlig spärr väntetid

SQLServer: Lås-genomsnittlig väntetid

SQLServer: Lås-lås timeouts / sek

SQLServer: Lås-Antal dödlås / sek

SQLServer: Memory Manager-minnesbidrag väntar

Ställ in värdet för varje räknare mellan värdena för de grundläggande parametrarna och referensvärdena som testning visade. Du kan till exempel ställa in en anmälan när mätaren når 75 procent av det högsta belastningsvärdet och varningsmeddelandet när det passerar 90 procent.

För att utföra varningar kan du använda gratis verktyg som SQL Server Alerts & Notifications, System Monitor eller Köp Microsoft Operations Manager (MOM) eller på annat sätt. Jag rekommenderar inställningsvarningar åtminstone för följande situationer:

• fel som påverkar operationen, speciellt fel med en indikator på betydelse från 19 till 25
• låsa
• använda processor
• användskiva
• skanning (SQLServer: Access Methodes)

Du kan skicka larm för att meddela administratörer via e-post, personsökare eller nätverk. Du kan installera automatiserade varningar för följande meddelanden:

• sQL Server Journal
• sQL Agent Magazine
• windows, säkerhet och system
• jobb Execution Log SQL Server

Slutligen är det nödvändigt att se till att deras egna utvecklingsapplikationer korrekt registrerar fel och svarar dessutom på felmeddelanden från andra utvecklade applikationer.

Proaktiv övervakning av prestanda SQL Server betyder definitionen av grundläggande prestandaparametrar för både servern och applikationen; Installera referensvärden som simulerar serverns funktion i enlighet med det förutbestämda scenariot som används och utför en schemalagd övervakning, idealiskt initierar en varning när problemet detekteras. Oavsett om det är gratis eller inbyggda verktyg som används eller lösningar av oberoende företag väljs, garanterar närvaron av kontroll garanterar att du får den nödvändiga informationen om driften av dina applikationer på SQL-servern vid önskat ögonblick.

Tabell 1. Objekt och systemmonitor mätare för att bestämma de grundläggande parametrarna

Objekt och räknare	Beskrivning
Minnesidor / sek	Antalet läsesidor eller skrivning till disken per sekund. Denna mätare är den främsta fel typindikator som orsakas av systemiska förseningar eller prestationsproblem
Nätverksgränssnitt-byte Totalt / sek	Antalet byte som passerar genom nätverksgränssnittet per sekund. När indikatorn på denna mätare minskar eller har en sådan tendens, indikerar detta att nätverksproblemen kan påverka applikationen
Fysicalysisk-disköverföringar / sek	Utvärdering av läs- / skrivdiskoperationer. Installera mätaren för varje fysisk disk på servern
Processor-% processor tid	Andelen av den tid som processorn spenderar utförandet av arbetsflödet. Denna räknare fungerar som en primär processoraktivitetsindikator. Om alla processorer som körs på SQL Server visar ett hundra procent, ignoreras slutanvändarnas önskemål
SQLServer: Access Methodes-Full Scans / Sec	Antal obegränsade färdiga tabeller eller indexskanningar per sekund. Sänka värdena på denna meter till det bättre eftersom utsikten ofta orsakar bristen på resurser i cache-problemet
SQLServer: Buffer Manager-Buffer Cache Hit-förhållande	Procentandel av sidor som inte krävde att läsa från disken. Ju högre deras nummer, desto mindre är ingången / utgången på skivan utförs. I ett välskött system måste detta värde vara 80 eller högre.
SQLServer: Databaser-loggtillväxter	När det gäller en specifik databas har transaktionsfilen vuxit. I ett väljusterat system måste värdet av denna räknare vara låg, förmodligen mindre än en om några dagar
SQLServer: Databaser Ansökningsdatabasprocent Loggen används	Procent av ledigt utrymme i loggfilen. Denna räknare kommer att variera, men bör inte nå 100
SQLServer: Databaser Ansökningsdatabas-transaktioner / sek	Antalet transaktioner bekräftade i databasen. Dessa motider sänktes i standarderna. Titta när transaktioner börjar ställa upp, vilket indikerar att skivmatningen / utgången kan vara långsam
SQLServer: Latches-genomsnittlig spärr väntetid	Den genomsnittliga frågefördröjningstiden före fyllning. Detta motvärdesvärde kan vara högt när servern står inför rivalitet för resurser, speciellt för minne eller för ingång / utgång
SQLServer: Lås-genomsnittlig väntetid, lås väntar / sek, antal dödlås / sek	Tillfälliga lås håller SQL Server-resurser. Titta på den uppåtgående trenden för denna anslutningsblockering, vilket indikerar ett eventuellt produktivitetsproblem
SQLServer: Allmänna statistik-användaranslutningar	Antalet anpassade anslutningar till databasservern. Kontrollera eventuella märkbara skift i värdet av denna räknare. De kan indikera nätverksproblem och indikera laster och retardation.
SQLServer: Memory Manager-minnesbidrag väntar	Det nuvarande antalet processer som väntar på tillhandahållande av minnesutrymme. Högt eller växande värde kan indikera ett otillräckligt minne.
SQLServer: Användarinställningsfrågan (en spårfråga)	Specialiserad mätare, även känd som Query Pointer. Denna mätare är en användarskapad förfrågan som indikerar systemets totala hastighet eller effektivitet. För att ställa in detta värde ringer programmet sp_User_counter1 och returnerar ett numeriskt värde.