Lako pratite aktivnost SQL Servera. Ko je aktivan? Korišćenje monitora aktivnosti SQL Servera Nadgledanje performansi ms sql servera

Ovo je softverski proizvod iz Sybase-a koji radi u sprezi sa SQL Serverom i pruža razne informacije o performansama servera u grafičkom obliku. Ova informacija je izuzetno korisna u analizi razloga za pad njenog učinka.

verzija 11.0.1 ima niz novih važnih karakteristika koje značajno razlikuju novu verziju od svih prethodnih. 11.0.1 može raditi sa bilo kojom verzijom SQL Servera od 4.9.2 do System 11.

Međutim, neki od najzanimljivijih tipova informacija o obrascima upotrebe objekata baze podataka i interakciji servera sa mrežom daju se samo kada se nadgledaju SQL Server System 10 i System 11. Naravno, podaci o performansama imenovanih keš bafera su pruža samo kada se nadgleda performanse SQL Server System 11.

Za kompatibilnost sa prethodnim verzijama, 11.0.1 takođe podržava način za izlaz statističkih informacija o performansama servera u datoteke koje se mogu koristiti za naknadno poređenje i analizu. Ova funkcija je vrlo korisna u praksi, ali njeno korištenje otežava proces instalacije.

sastoji se od dvije komponente: serverskog modula koji radi na istom stroju sa SQL Serverom kako bi se omogućio pristup zajedničkoj memorijskoj oblasti servera i klijentskog modula koji se može pokrenuti na bilo kojem računalu. Glavni zadatak klijentskog modula je da pročita informacije koje je akumulirao serverski modul i predstavi ih korisniku u grafičkom obliku.

Prilikom pokretanja, morate otkazati provjeru memorije servera koju vrši naredba dbcc memusage, jer ova naredba značajno usporava server. Da biste to učinili, kada pokrećete sqlmon (klijentski modul), morate navesti parametar – nomem.

Podrazumevana konfiguracija omogućava istovremeno povezivanje do pet klijentskih modula na jedan serverski modul. Drugim riječima, jedan serverski modul može biti povezan ili na pet klijentskih modula sa jednim prozorom na svakom klijentu, ili na jednog klijenta sa pet otvorenih prozora.

Maksimalan broj istovremeno otvorenih prozora klijenta je postavljen kada se serverski modul pokrene.

Dakle, da biste podržali 20 prozora u komandnoj datoteci za pokretanje serverskog modula, potrebno je navesti parametar n2 0. U ovom slučaju, morat ćete promijeniti adresu početka područja dijeljene memorije servera pomoću naredbu buildmaster i neke druge radnje. Ove radnje se nikada ne bi trebale izvoditi dok je SQL Server pokrenut. (Za detalje o procesu proširenja broja podržanih istovremenih klijenata, pogledajte priručnik Server Supplement.)

ima neke nedostatke. Na primjer, trakasti grafikon koji prikazuje broj I/O operacija u toku i druge karakteristike performansi serverskih uređaja može prijaviti podatke samo o ograničenom broju uređaja u isto vrijeme.

Ovo je nezgodno kada se nadgleda veliki server sa velikim brojem serverskih uređaja. Osim toga, korisnik ne može birati uređaje za koje će informacije biti uključene u grafikon, niti se prebacivati ​​između različitih skupova uređaja.

Tekstualna tabela koja se pojavljuje na ekranu istovremeno sa dijagramom sadrži listu svih serverskih uređaja, ali uključuje samo ukupan broj I/O operacija za svaki od njih. Ovo je posebno teško kada se radi sa velikim serverom koji ima mnogo serverskih uređaja koji podržavaju segmente korisničke baze podataka radi poboljšanja njegovih performansi. U ovom slučaju je nemoguće analizirati rad svih postojećih segmenata.

Takođe ne dozvoljava da se dinamika promjena indikatora performansi prikaže na ekranu dugo vremena.

Može prikazati podatke za 60 uzastopnih intervala mjerenja performansi. Ovisno o odabranom trajanju svakog intervala, takva statistika može pokriti prilično veliki vremenski period. Međutim, ova tehnika ne omogućava poređenje trenutnih podataka sa pokazateljima od prije mjesec ili godinu dana.

Naravno, slike prozora programa mogu se poslati na štampač, ali tada ćete morati da skladištite skupove datoteka ili planine ispisa da biste procenili buduće performanse servera. U praksi, administrator servera će često morati da preispita podatke prikupljene u različitim periodima poslovnog ciklusa kompanije, kao i da uporedi informacije u sličnim periodima u uzastopnim poslovnim ciklusima, kako bi stekao uvid u stvarne performanse servera.

Budući da pokretanje rezultira određenim usporavanjem servera, prije početka mjerenja potrebno je odrediti veličinu ovog usporavanja za određenu hardversku i softversku platformu. Dobar način mjerenja je pokretanje standardnog skupa testnih transakcija.

Može se koristiti i ako postoji ili ne na serverskoj mašini. Čak i ako nema klijentskih modula, serverski modul programa nastavlja sa radom i mora se zaustaviti posebnom komandom.

omogućava vam da prikažete nekoliko različitih grafičkih prozora, od kojih svaki sadrži informacije o određenom aspektu funkcionisanja servera.

Glavni prozor
Ovo sadrži listu prozora koje podržava program. Ako prilikom pokretanja sglmon-a, klijentskog modula, parametar – nomem nije naveden, ovaj prozor će prikazati i kružni grafikon upotrebe memorije serverske mašine.

Keš baferi
Ovaj prozor prikazuje grafikone koji karakterišu rad procedura i bafera keša podataka. Kontrolom broja fizičkih i logičkih I/O operacija u baferu predmemorije podataka, korisnik može odrediti koliko će stranice podataka pristupiti serveru koristeći stranice koje su već u baferu. Ove statistike, dobijene za bafer podataka i bafer procedure, omogućavaju nam da odredimo ukupnu količinu memorije koju zahtevaju keš baferi servera i odnos između bafera keša podataka i procedura.

Predmemorija bafera podataka, samo SQL Server System 11 (Keš podataka)
Prozor izvještava o broju fizičkih i logičkih I/O operacija za svaki od imenovanih keš bafera konfiguriranih na poslužitelju.

Disk I/O
Ovdje možete pronaći grafikone i zbirne tabele za trenutni i ukupan broj pristupa disku. Oni pomažu optimizirati raspodjelu I/O opterećenja među postojećim serverskim uređajima. Prilikom analize izlaznih informacija, korisno je koristiti standardnu ​​šemu za odabir imena serverskih uređaja na osnovu imena odgovarajućih sekcija fizičkih diskova, jer, dok pratite tečaj sa serverskim uređajima, trebate znati koji disk kontroler svaki od ovih uređaja je povezan.

Rad sa mrežom, samo za SQL Server sistem 10 i 11 (mrežna aktivnost)
Prozor izvještava statističke informacije o mrežnom ulazu i izlazu - veličinama paketa, obima prometa itd.

Blokiranje pristupa objektima, samo za SQL Server System 10 i 11 (Object Lock Status)
Ovo prikazuje informacije o zaključavanju pristupa tablici podataka, uključujući detaljan pregled tipova korištenih brava, imena procesa koji drže brave, itd.

Object Page I/O, SQL Server System 10 i 11 samo (Object Page I/O)
Prozor sadrži informacije o intenzitetu I/O stranica jedne od tablica podataka poslužitelja. Obratite pažnju na efikasnost prilikom sastavljanja liste najčešće korišćenih serverskih tabela. Ovu vrstu informacija ne vraća sp_sysmon.

Sažetak performansi
Ovo daje opštu sliku o tome kako SQL Server radi - procenat utrošenog CPU vremena, broj obrađenih transakcija u sekundi, obim mrežnog saobraćaja, disk I/O i upotreba zaključavanja.

Performans Trend
Prozor prikazuje kontinuirane grafikone indikatora performansi servera prikazanih u prozoru Performance Summary u odnosu na vrijeme.

Procesna aktivnost servera (Process Activit)
Prozor vam omogućava da odaberete jedan ili više serverskih procesa i nadgledate upotrebu CPU-a i I/O volumene za svaki proces.

Detalji procesa
Prozor sadrži detaljne informacije o odabranom serverskom procesu.

Lista procesa
Prozor sadrži listu svih trenutno dostupnih serverskih procesa sa naznakom njihovog statusa. Vrlo slično izdavanju naredbe servera sp_who.

Korištenje aktivnosti zaključavanja procesa
Prozor pruža informacije o korištenju zaključavanja od strane serverskog procesa koji ste odabrali.

Korištenje aktivnosti pohranjene procedure
Prozor sadrži informacije o izvršavanju pohranjenih procedura i vremenu izvođenja svake procedure.

Transakciona aktivnost
U prozoru možete vidjeti trakasti grafikon koji prikazuje broj transakcija koje se obrađuju, razvrstane po različitim vrstama transakcija. Možete vidjeti, na primjer, koji dio transakcija može biti dovršen pomoću mehanizma ažuriranja na mjestu.

26.12.2006. Kevin Kline

Koje je posljednje pitanje koje bi DBA želio postaviti? Vjerovatno poruka od korisnika o propadanju aplikacije ili pitanje šta se dogodilo s bazom podataka. Moramo sve ostaviti po strani i preći u “hitni režim”, pitajući se koliko će ovo trajati. Budući da je jedna od glavnih odgovornosti administratora baze podataka da osigura kvalitetno funkcionisanje industrijskih baza podataka, ostaje samo da se problem otkloni što je brže moguće. U pravilu nema vremena da se otkrije uzrok kvara.

Nema više žurnih poslova - samo sistematsko posmatranje

Ali da li je to jedino što se može učiniti? Postoji mogućnost sprovođenja proaktivnog praćenja performansi, jednostavna procedura upravljanja koja koristi osnovne linije sistema, benchmarking i kontinuirano praćenje. U ovom članku ću govoriti o tome kako koristiti proaktivno nadgledanje i kako kreirati besplatan sistem za praćenje pomoću Windows System Monitora.

Proaktivno praćenje

Proaktivno praćenje performansi je jednostavan sistem koji vam pomaže da riješite probleme prije nego što postanu kritični. Neki ljudi vjerovatno već koriste praćenje izuzetaka, gdje kreiraju automatizirane procese koji samo primjećuju anomalije, ali ne pružaju detaljne informacije ili mogućnost sprječavanja problema. Proaktivno praćenje performansi, s druge strane, pruža korisniku sve vrste informacija o radnom okruženju i aplikacijama, kako kratkoročnih tako i dugoročnih. Uzimaju se brojači performansi baze podataka, uspostavljaju se referentne metrike i održava se aktivno praćenje.

Kao što ime sugerira, proaktivno praćenje učinka zahtijeva akciju. Potrebno je malo vremena za instalaciju i malo vremena za razumijevanje kako baze podataka i aplikacije rade. Da bi proaktivno praćenje učinka bilo efikasno, poruke se moraju pregledati tako da se bogati prikupljeni podaci mogu iskoristiti.

Osnovni parametri, standard, monitor

Počnimo s definiranjem nekoliko pojmova. Osnovni parametri (osnovna linija) je skup parametara koji odražavaju ponašanje servera i aplikacije u normalnim uslovima. Osnovni parametri su dobijeni kao proseci na osnovu rezultata više merenja u istim uslovima; oni su mjerila za poređenje.

Benchmark prikazuje performanse sistema na određenom nivou opterećenja servera, što vam omogućava da uporedite performanse industrijskog servera na ovom nivou i odredite performanse servera, koliko su one veće ili niže od normalnih (tj. server radi loše). Kao i kod osnovnih parametara, referentne vrijednosti se uzimaju u kontroliranom okruženju, a ključne vrijednosti se određuju u odnosu na unaprijed definirane indikatore. Ako trebate vidjeti kako se server i aplikacija ponašaju na nekoliko nivoa ili tipova opterećenja, tada obično dobijete nekoliko referentnih vrijednosti (u odnosu na osnovne parametre)

Monitoring- ovo je planirano praćenje servera u realnom vremenu pod unapred definisanim uslovima (setovi uslova definisanih za dalju istragu ili upozorenja). Na primjer, ako želite znati koliko je vremena potrebno da bi se kritična poslovna aplikacija uspješno pokrenula, koliko dugo traje sigurnosna kopija ili kada su dostignute određene prekretnice performansi, ti specifični događaji se prate.

Sada pređimo na proaktivno praćenje. Možete koristiti proizvode treće strane ili besplatno rješenje koje koristi System Monitor. Rešenja trećih strana mogu pojednostaviti proces postavljanja proaktivnog nadzora i mogu imati različite karakteristike od onih koje nudi besplatno, ugrađeno rešenje. Ali prije nego što počnemo, pokazat ću vam kako da počnete s proaktivnim nadzorom koristeći System Monitor.

Korak 1: Definirajte osnovne linije učinka.

U prvom koraku obezbeđivanja proaktivnog režima praćenja uspostavlja se skup osnovnih parametara za rad servera baze podataka. Ovaj agregat ukazuje na performanse servera u normalnim uslovima, pomaže da se dokumentuju i razumeju svi značajni pozadinski procesi, a takođe pomaže da se identifikuju situacije koje ne zahtevaju intervenciju kako bi se mogle zanemariti u budućnosti. Drugim riječima, administratori baze podataka mogu definirati opcije za ignoriranje sistemskih poruka, jer se u suprotnom generira veliki broj lažnih obavijesti.

Da bi se jasno prikazao kvalitet rada, najbolje osnovne linije koriste nekoliko grafikona (idealno jedan) tako da možete na prvi pogled vidjeti kako server radi. Nakon što su osnovni parametri određeni, potrebno je učiniti sljedeće. Prvo odaberite opciju da sačuvate podatke o performansama u sistemskom dnevniku ili ih prikažete u realnom vremenu. Idealno je imati oboje: evidencije vam omogućavaju da se osvrnete na očitanja u bilo kom trenutku kako biste analizirali kakve su bile performanse kada niste direktno nadgledali sistem. Praćenje u realnom vremenu ne zauzima prostor na disku ili serverske resurse, ali zahtijeva 100 posto vaše pažnje na sistem. Drugo, morate odrediti interval u kojem će se vršiti nadzor, uzimajući u obzir troškove performansi prikupljanja podataka i I/O operacija podataka, te procijeniti trošak potrebnog prostora. Što je interval duži, veća je vjerovatnoća da podaci o performansama od interesa neće biti dobijeni. Na kraju, odaberite lokalni ili daljinski nadzor. Lokalni nadzor, u kojem proces nadgledanja koristi nadgledani server, dodaje CPU i disk nadopterećenje serveru. Daljinski nadzor, koji koristi poseban server, može eliminisati ove probleme, ali uvelike povećava radno opterećenje na mreži.

Navodi metriku ili brojače System Monitora koje preporučujemo da koristite za određivanje vaše osnovne linije. Ne mogu reći koja je “ispravna” vrijednost u kontekstu određene aplikacije, jer se razlikuje od sistema do sistema. Koristite prosjek različitih osnovnih linija da postavite normalne osnovne performanse i naznačite da je ovo ispravna opcija za sistem koji se koristi.

Definiranje osnovnih postavki pomoću System Monitora

Sada, u svrhu prikupljanja osnovnih parametara, pozovimo System Monitor. Otvorimo Control Panel, Administrative Tools, Performance. Dvaput kliknite na Performance Logs and Alerts u lijevom oknu. Kliknite desnim tasterom miša na Counter Logs i izaberite New Log Settings. Unesite naziv za grafikon, a zatim kliknite na OK. U dijaloškom okviru za odabir brojača odaberite prvi brojač, a zatim kliknite na Dodaj. Ponavljajte ove korake dok se ne dodaju svi brojači, a zatim kliknite Zatvori.

Za početak isprobajte zadani interval od 15 sekundi. Ili izaberite drugi interval klikom na Svojstva (ili koristite prečicu na tastaturi Ctrl + Q), a zatim unesite vrednost označenu sa Uzorak automatski svakih: _ sekundi. Duži intervali zauzimaju manje prostora, ali pružaju manje detaljne podatke.

Odaberite tabelu Log Files i odredite gdje će podaci biti pohranjeni. Podatke možete pogledati kasnije koristeći prikaz podataka iz datoteke dnevnika. Monitor sistema će izgledati kao što je prikazano na slici 1 kada prikuplja osnovne podatke o performansama. Vidi se da se može prikupiti mnogo podataka praćenjem više brojila u isto vrijeme, tako da treba pažljivo odabrati brojila za glavni vod.

Korak 2: Postavljanje referentnih vrijednosti

Kada se uspostavi osnovna linija performansi servera, možete početi sa postavljanjem mjerila, što olakšava razumijevanje performansi servera kada se radi u nekoliko unaprijed definiranih situacija.

Za standarde se koristi isti način praćenja kao i za određivanje osnovnih parametara. Možete koristiti vlastito rješenje ili jedan od uobičajenih industrijskih alata kao što su TPC-C ili SAP, ali najbolji rezultati za izračunavanje referentnih vrijednosti postižu se razvojem uobičajenih prilagođenih skripti koje su konfigurirane za korištenje određenog poslužitelja baze podataka i njegovih aplikacija .

Možete kreirati vlastitu skriptu koristeći T-SQL paket skripti, osql uslužne programe ili Query Analyzer, SQL Profiler i System Monitor. Razvoj skripti za testiranje opterećenja u T-SQL obično traje nekoliko dana. Možda će biti potrebno još više vremena za prikupljanje podataka o izvršenju testa opterećenja i analizu rezultirajućih podataka.

Nakon što uspostavite osnovnu liniju performansi servera pod unaprijed određenim radnim opterećenjima, možete znati što možete očekivati ​​od sistema. Koristite podatke prikupljene za dobijanje referentnih vrednosti da formirate osnovu za rutinsko praćenje. Na primjer, otkriveno je da server može isporučiti do 249 transakcija u sekundi prije nego što je počeo da usporava. U ovom slučaju, možete postaviti obavještenje niskog prioriteta kada server dostigne oko 200 TPS i obavještenje visokog prioriteta kada server dostigne 235 TPS. Ova metoda će omogućiti administratoru da sazna o mogućim problemima sa serverom i preduzme potrebne mjere prije nego što korisnici išta primjete. I nema kritičnih situacija. Sada je to moguće.

Korak 3: Planirano praćenje

Možda je najvažnija komponenta proaktivnog režima praćenja planirano praćenje. Bez toga ne možete pratiti performanse baze podataka niti otkriti probleme s performansama.

Možete kreirati jeftin alat za praćenje SQL Servera koristeći kombinaciju SQL Server Agenta i System Monitora. SQL Server Agent vam omogućava da odredite koji je događaj izazvao pojavu greške na monitoru, odredite ko prima obavijesti o događajima i automatski pošalje obavijest kada dođe do greške.

Instaliranje SQL Server Agenta može biti dugotrajno i složeno, tako da ćete morati pogledati odjeljak Upozorenja u SQL Serveru za više informacija. Knjige na mreži (BOL). SQL Server Agent obično prati poruke o grešci servera baze podataka i ne nadgleda izvršenje.

Za praćenje performansi servera, koristite System Monitor za praćenje trenutnih brojača (podesite učestalost prozivanja na 15 minuta).

Memory-Pages/sec

Mrežni interfejs – ukupno bajtova/sek

Prenosi fizički disk-disk/sek

Procesor-% procesorskog vremena

SQLServer: Metode pristupa-Puna skeniranja/sek

SQLServer: Upravljač međuspremnikom-Međuspremnik omjer pogodaka predmemorije

SQLServer: Databases Application Database-Transactions/sec

SQLServer:Opća statistika-korisničke veze

SQLServer: Latches-Prosječno vrijeme čekanja zasuna

SQLServer: Zaključavanje-prosječno vrijeme čekanja

SQLServer: Zaključavanje-Zaključavanje Timeouts/sec

SQLServer: Brave-Broj zastoja u sekundi

SQLServer:Memory Manager-Memory Grants na čekanju

Postavite vrijednost za svaki brojač između osnovnih vrijednosti i referentnih vrijednosti prikazanih testiranjem. Na primjer, možete postaviti obavijest kada mjerač dostigne 75 posto najveće vrijednosti opterećenja i poruku upozorenja kada prijeđe 90 posto.

Da biste izvršili upozorenja, možete koristiti besplatne alate kao što su SQL Server Alerts & Notifications, System Monitor ili kupiti Microsoft Operations Manager (MOM) ili druge alate. Preporučujem postavljanje upozorenja barem za sljedeće situacije:

  • greške koje utiču na rad, posebno greške sa ocenom ozbiljnosti od 19 do 25
  • blokiranje
  • Upotreba CPU-a
  • korištenje diska
  • skeniranje (SQLServer: Metode pristupa)

Alarmi se mogu slati za obavještavanje administratora putem e-pošte, pejdžera ili mreže. Možete postaviti automatska upozorenja za sljedeće izvore poruka:

  • SQL Server log
  • Dnevnik SQL agenta
  • Dnevnik Windows aplikacija, sigurnost i sistem
  • Dnevnik izvršenja posla SQL Servera

Konačno, morate se pobrinuti da vaše vlastite aplikacije ispravno evidentiraju greške i da odgovorite na poruke o greškama iz drugih razvijenih aplikacija.

Proaktivno praćenje performansi SQL Servera znači uspostavljanje osnovnih parametara performansi i za server i za aplikaciju; postavljanje mjerila koja simuliraju ponašanje servera prema unaprijed definiranom scenariju u upotrebi i izvođenje planiranog nadzora, idealno za pokretanje upozorenja kada se otkrije problem. Bilo da koristite besplatne ili ugrađene alate, ili odaberete rješenja trećih strana, kontrola osigurava da dobijete informacije koje su vam potrebne kada su vam potrebne o tome kako vaše aplikacije rade na SQL Serveru.

Tablica 1. Objekti System Monitora i brojači za određivanje osnovnih parametara
Objekt i brojač Opis
Memory-Pages/secBroj stranica pročitanih ili upisanih na disk u sekundi. Ovaj brojač je primarni pokazatelj tipova grešaka uzrokovanih kašnjenjima sistema ili problemima sa performansama
Mrežni interfejs – ukupno bajtova/sekBroj bajtova koji prolaze kroz mrežni interfejs u sekundi. Kada se ovaj brojač smanjuje ili ima trend na ovaj način, to ukazuje da problemi s mrežom mogu utjecati na aplikaciju
PhysicalDisk-Disk Transfers/secProcjena operacija čitanja/pisanja diska. Postavite brojač za svaki fizički disk na serveru
Procesor-% procesorskog vremenaProcenat vremena koje procesor troši na izvršavanje radne niti. Ovaj brojač služi kao primarni indikator aktivnosti procesora. Ako svi procesori koji rade na SQL Serveru pokažu 100% iskorištenost, upiti krajnjih korisnika se vjerovatno zanemaruju
SQLServer: Metode pristupa-Puna skeniranja/sekNeograničeno skeniranje tablica ili indeksa u sekundi. Smanjenje ovog brojača je na bolje jer pogledi često uzrokuju nedostatak resursa i probleme s keširanjem
SQLServer: Upravljač međuspremnikom-Međuspremnik omjer pogodaka predmemorijeProcenat stranica koje nisu zahtijevale čitanje diska. Što je njihov broj veći, manje se izvodi I/O diska. Na dobro podešenom sistemu ova vrijednost bi trebala biti 80 ili više.
SQLServer:Baze podataka-Log rastaKoliko je narastao fajl transakcije za određenu bazu podataka? Na dobro podešenom sistemu, ovaj brojač bi trebao biti nizak, vjerovatno manji od jedan svakih nekoliko dana
SQLServer: Databases Application Database-Percent Log KorištenPostotak slobodnog prostora u datoteci evidencije. Ovaj brojač varira prema planu, ali ne bi trebao dostići 100
SQLServer: Databases Application Database-Transactions/secBroj transakcija potvrđenih u bazi podataka. Ovaj brojač je ponekad izostavljen iz standarda. Gledajte kada transakcije počnu stajati u redu, to je pokazatelj da je I/O diska možda spor
SQLServer: Latches-Prosječno vrijeme čekanja zasunaProsječno vrijeme zadržavanja zahtjeva prije nego što se ispuni. Ova vrijednost brojača može biti visoka kada server ima sukob za resurse, posebno memoriju ili I/O
SQLServer: zaključavanja-prosječno vrijeme čekanja, zaključavanje čekanja/s, broj zastoja u sekundiPrivremene brave drže resurse SQL Servera. Pazite na uzlazni trend kod ovih brojača vezanih za zaključavanje, što ukazuje na mogući problem s performansama
SQLServer:Opća statistika-korisničke vezeBroj korisničkih veza na poslužitelj baze podataka. Provjerite ima li primjetnih pomaka u vrijednosti ovog brojača. Oni mogu ukazivati ​​na probleme sa mrežom i ukazati na opterećenja i usporavanja
SQLServer:Memory Manager-Memory Grants na čekanjuTrenutni broj procesa koji čekaju da im se dodijeli memorijski prostor. Visoka ili rastuća vrijednost može ukazivati ​​na nedovoljan kapacitet memorije
SQLServer:Upit za postavljanje korisnika (upit za praćenje)Specijalizirani brojač, također poznat kao indeks upita. Ovaj brojač je upit koji generira korisnik koji pokazuje ukupnu brzinu ili efikasnost sistema. Za postavljanje ove vrijednosti, aplikacija poziva sp_user_counter1 i vraća numeričku vrijednost.


Svaki administrator baze podataka vjerovatno se morao suočiti s činjenicom da sve radi sporo ili uopće ne radi. Prva stvar koju treba da saznate je šta se trenutno dešava na SQL Serveru. Čini se da administrator ima toliko korisnih stvari u svom arsenalu: glupi Monitor aktivnosti, gomilu dinamičkih pogleda upravljanja (dmv), pohranjene procedure sp_who i sp_who2, naslijeđene iz dana SQL Servera 7 i SQL Servera 2000.
Ali hajde da shvatimo...

Alati za praćenje

Monitor aktivnosti

Čini se da je to odlična stvar, radi upravo ono što treba - prati aktivnost. Pokrećem težak računovodstveni izvještaj i vidim šta mi prikazuje Activity Monitor.
Snimci ekrana prikazuju monitor aktivnosti sa SQL Servera 2005:

i sa SQL Server Denali (2012) CTP 3.


Hmmm. Šta ako desetak ljudi vodi takve izvještaje? I to nije neuobičajeno... Biće prilično nezgodno shvatiti, iako je, naravno, napredak očigledan. U Denali Activity Monitor prikazuje mnogo više korisnih informacija (na primjer, na kojem se konkretnom resursu čeka čekanje), plus, možemo, na primjer, pokrenuti profiler za željenu sesiju direktno sa monitora i pratiti ga već u profileru , ali, dovraga, dodatno učitava i već preopterećen server. Osim toga, već postoji problem sa kočnicama, a nećemo vidjeti one zahtjeve koji su već počeli da se izvršavaju u trenutku kada je profiler pokrenut.
A to je upravo ono što želim da vidim – ko šta radi u ovom trenutku.

sp_who i sp_who2

Snimak ekrana prikazuje rezultat izvršavanja sp_who (gore) i sp_who2 (dolje), izvršenog prilikom pravljenja istog nesretnog izvještaja:


Da. Vrlo informativno. Gledajući sp_who možemo vidjeti samo da nešto radi. Naravno da se izvršava - zato gledamo, ali vidimo da se izvršava neka vrsta SELECT. Ili nekoliko SELECT-ova.
sp_who2 prikazuje više informacija. Sada možemo vidjeti koliko je procesorskog vremena potrošeno na sesiju (i zbrojiti ukupno vrijeme u koloni, naizgled), broj I/o operacija, naziv baze podataka u kojoj se sve ovo izvodi i ko je ovo sesija je blokirana (ako je blokirana).
Monitor aktivnosti, kao što vidimo, pruža više informacija.

DMV

Počevši od SQL Servera 2005, imamo novu mogućnost da dobijemo informacije o stanju servera - Dinamički prikazi upravljanja. MSDN kaže ovo: "Dinamički prikazi upravljanja i funkcije vraćaju podatke o zdravlju servera koji se mogu koristiti za praćenje zdravlja instance servera, dijagnosticiranje problema i podešavanje performansi."
Zaista, u SQL Serveru 2005 postoji skup pogleda koji se odnosi na izvršavanje upita u trenutnom trenutku (međutim, postoje i pogledi za gledanje „istorije“): evo ih i njihov broj se nastavlja povećavati od verzije do verzije!
Sigurno da iskusni administratori imaju gomilu skripti spremnih da dobiju informacije o trenutnom stanju servera, ali šta učiniti ako još nemate iskustva u radu sa DMV-om, ali već postoje problemi?

sp_WhoIsActive

Adam Machanic (SQL Server MVP i MCITP) je razvio i stalno poboljšava pohranjenu proceduru sp_WhoIsActive, koja se oslanja na te iste DMV-ove i prokleto je jednostavna za korištenje. Možete preuzeti najnoviju verziju sp_WhoIsActive. Sam Adam ima seriju članaka posvećenih sp_WhoIsActive, koja se sastoji od čak 30 (trideset!) komada, možete ga pročitati, ali ja ću se potruditi da vas zainteresujem za čitanje ovog materijala :).
Dakle, pretpostavićemo da ste preuzeli i pokrenuli ovu skriptu na jednom od test servera (na bilo kojoj verziji, od 2005 do Denali). Adam savjetuje da je pohranite u bazu podataka glavnog sistema kako bi se mogla pozvati u kontekstu bilo koje baze podataka, ali to nije potrebno, samo kada je pozivate u kontekstu druge baze podataka, morat ćete napisati ime u cijelosti - DB .schema.sp_whoIsActive.
Pa hajde da probamo. Snimak ekrana prikazuje rezultat njegovog izvršenja pri izradi istog izvještaja:

Rezultat upita exec sp_whoIsActive, nažalost, ne stane u jedan ekran, pa evo tekstualnog opisa izlaza pohranjene procedure pozvane bez parametara.

  • - za aktivni zahtjev prikazuje vrijeme izvršenja, za "sleeping" sesiju - vrijeme "sleep";
  • - zapravo, spid;
  • - prikazuje tekst zahteva koji se trenutno izvršava, ili tekst poslednjeg završenog zahteva ako sesija spava;
  • - pa, razumete;
  • - veoma interesantna kolumna. Izlazi u formatu (Ax: Bms/Cms/Dms)E. A je broj zadataka koji čekaju na resursu E. B/C/D je vrijeme čekanja u milisekundama. Ako postoji samo jedna sesija koja čeka da se resurs oslobodi (kao na snimku ekrana), njegovo vrijeme čekanja će biti prikazano, ako postoje 2 sesije, njihova vremena čekanja će biti prikazana u B/C formatu. Ako 3 ili više čekaju, videćemo minimalno, prosečno i maksimalno vreme čekanja na OVOM resursu u B/C/D formatu;
  • - za aktivni zahtjev - ukupno CPU vrijeme potrošeno na ovaj zahtjev, za sesiju mirovanja - ukupno CPU vrijeme za "cijeli život" ove sesije;
  • - za aktivni upit, ovo je broj operacija pisanja u TempDB tokom izvršenja upita; za spavajuću sesiju - ukupan broj zapisa u TempDB-u za cijeli životni vijek sesije;
  • - za aktivni zahtjev - broj stranica u TempDB-u dodijeljenih za ovaj zahtjev; za spavajuću sesiju - ukupan broj stranica u TempDB-u dodijeljenih tokom cijelog životnog vijeka sesije;
  • - ako nas iznenada neko blokira, pokazaće se spid (session_id) osobe koja nas je blokirala;
  • - za aktivni zahtjev - broj logičkih čitanja izvršenih prilikom izvršavanja ovog zahtjeva; za spavajuću sesiju - broj stranica pročitanih tokom čitavog trajanja ove sesije;
  • - sve je isto, ali o snimanju;
  • - za aktivni zahtjev - broj fizičkih čitanja izvršenih prilikom izvršavanja ovog zahtjeva; za seansu spavanja - tradicionalno, ukupan broj fizičkih očitavanja tokom čitavog trajanja sesije;
  • - za aktivni zahtjev - broj stranica od osam kilobajta korištenih prilikom izvršavanja ovog zahtjeva; za sesiju spavanja - koliko mu je ukupno memorijskih stranica dodijeljeno tokom cijelog životnog vijeka;
  • - status sesije - trčanje, spavanje, itd.;
  • - prikazuje broj transakcija otvorenih ovom sesijom;
  • - prikazuje, ako je moguće, napredak operacije (na primjer, BACKUP, RESTORE), nikada neće pokazati koliko je posto SELECT završeno.

Preostale kolone u standardni izlaz sp_WhoIsActive su malo interesantni i neću ih opisivati ​​- njihova svrha je, mislim, svima jasna (host_name, database_name, program_name, start_time, login_time, request_id, collection_time).

Pa šta? Ovo je sve?

Ne, to nije sve. Također ću govoriti o tome s kojim (s moje tačke gledišta najzanimljivijim i najkorisnijim) parametrima možete pozvati sp_WhoIsActive i šta će iz toga proizaći.

  • @help je užasno korisna opcija. Kada pozovemo sp_whoIsActive @help = 1, dobijamo informacije o SVIM parametrima i izlaznim kolonama na ekranu. Dakle, ako nešto ostane nejasno, uvijek možete pogledati "pomoć"
  • @filter_type i @filter - omogućavaju vam da filtrirate rezultat izvršenja. @filter_type može uzeti vrijednosti "session", "program", "database", "login" i "host". U parametru @filter označavamo koji nas objekt odabranog tipa zanima. Na primjer, želimo vidjeti sve sesije koje se izvode u glavnoj bazi podataka, za ovo pozivamo exec sp_whoIsActive @filter_type = "database", @filter = "master" . Parametar @filter dozvoljava upotrebu "%";
  • @not_filter_type i @not_filter - omogućavaju nam da filtriramo "obrnuto". To jest, na primjer, želimo vidjeti sve osim onih sesija koje imaju “master” u polju “database”, za to izvršavamo exec sp_WhoIsActive @not_filter_type = “database”, @not_filter = “master” . Pa, ili, želimo vidjeti šta svi korisnici osim korisnika sa rade... Može biti mnogo aplikacija. Parametar @not_filter dozvoljava upotrebu "%";
  • @show_system_spids = 1 - prikazaće informacije o sistemskim sesijama;
  • @get_full_inner_text = 1 - polje sql_text će sadržavati ne samo tekst trenutnog zahtjeva (izvoda) u grupi (batch), već i tekst cijele grupe;
  • @get_plans - će dodati kolonu sa planovima za izvršenje upita na izlaz;
  • @get_transaction_info = 1 - na izlaz će dodati broj i obim unosa u evidenciji transakcija, kao i vrijeme početka posljednje transakcije;
  • @get_locks = 1 - dodaće izlaznim informacijama o svim zaključavanjima primenjenim tokom izvršavanja zahteva;
  • @find_block_leaders = 1 - će pratiti lanac blokiranja i prikazati ukupan broj sesija koje čekaju da trenutna sesija ukloni blok;
  • @output_column_list = "[%]" - šta ako ne želite da vidite tempDB informacije u sp_whoIsActive izlazu? Ova opcija vam omogućava da kontrolišete šta ona daje;
  • @destination_table = "table_name" - pokušaće da ubaci rezultat izvršenja u tabelu, ali neće proveriti da li ova tabela postoji i da li ima dovoljno prava za umetanje u nju.

To je sada sve

Kao rezultat toga, imamo još jedan izuzetno zgodan i fleksibilan alat za praćenje trenutne aktivnosti na SQL Serveru. Za njegov normalan rad dovoljna je dozvola VIEW SERVER STATE i prava pristupa dmv-u.
Također je vrijedno dodati u slučaju kada se server može povezati samo preko

Kontrolna lista revizije učinka

Unesite svoje rezultate u gornju tabelu.

Korišćenje monitora performansi za identifikaciju uskih grla u hardveru SQL servera

Najbolje mjesto za početak revizije performansi SQL Servera je sa Monitorom performansi (System Monitor). Praćenje nekoliko ključnih brojača u periodu od 24 sata daće vam prilično dobru ideju o svim većim hardverskim problemima koji utiču na performanse SQL Servera.

U idealnom slučaju, trebali biste koristiti monitor performansi za kreiranje 24-satnog dnevnika očitavanja ključnih mjerača. Odabrat ćete "tipični" period od 24 sata za kreiranje datoteke dnevnika.

Na primjer, odaberite tipičan radni dan, a ne kraj sedmice ili praznik.

Nakon što snimite 24 sata podataka Monitora performansi u datoteci evidencije, prikažite preporučene brojače u režimu Grafik monitora performansi, a zatim zabilježite prosječne, minimalne i maksimalne vrijednosti u gornjoj tabeli. Nakon što to učinite, uporedite svoje rezultate s rezultatima analize u nastavku. Ovo poređenje će vam dati priliku da identifikujete sva potencijalna hardverska uska grla koja utiču na vaš SQL Server.

Kako protumačiti ključne brojače monitora performansi

U nastavku razmatramo neke osnovne brojače monitora performansi, njihove preporučene vrijednosti i neke opcije koje bi trebale pomoći u identifikaciji i rješavanju hardverskih problema. Treba napomenuti da sam ograničio broj razmatranih brojača monitora performansi. To je učinjeno jer je svrha ovog članka da otkrije jednostavne i očigledne probleme gubitka produktivnosti. Rasprava o mnogim drugim brojačima za praćenje performansi može se naći na drugom mjestu na ovoj web stranici.

Memorija: Stranice/sekunde

Pod pretpostavkom da je SQL Server jedina glavna aplikacija koja radi na vašem serveru, ovaj broj bi u idealnom slučaju trebao biti između nule i 20. Vrlo je vjerovatno da ćete vidjeti odstupanja znatno iznad 20, što je sasvim normalno. Ovdje je ključno zadržati prosječnu stopu razmjene stranica ispod 20.

Ako vaš server u prosjeku radi više od 20 stranica u sekundi, jedan od najvjerovatnijih razloga za to je nedostatak potrebne RAM memorije. Uopšteno govoreći, što je više RAM-a dostupno, to bi trebalo izvršiti manje zamjene stranica.

U većini slučajeva, na fizičkom serveru posvećenom SQL Serveru sa adekvatnim RAM-om, prosječna zamjena stranica će biti manja od 20. Adekvatna RAM memorija za SQL Server može se odrediti prema sljedećem kriteriju: server mora imati omjer pogodaka keša bafera (Buffer Hit Cache Ratio) 99% ili više. Ovaj brojač je opisan kasnije u ovom članku. Ako imate SQL Server koji ima ovaj omjer od 99% ili više u periodu od 24 sata, ali dobijate prosječnu razmjenu stranica od preko 20 u istom vremenskom periodu, to može značiti da koristite druge aplikacije na fizički server koji nije SQL Server. Ako je to slučaj, idealno bi trebalo da uklonite ove aplikacije, dopuštajući SQL Serveru da bude jedina glavna aplikacija na fizičkom serveru.

Ako vaš SQL Server ne pokreće nijednu drugu aplikaciju i zamjena stranica prelazi 20 u prosjeku u periodu od 24 sata, to može značiti da ste promijenili postavke memorije SQL Servera. SQL Server mora biti konfiguriran tako da je opcija "Dinamički konfiguriraj memoriju SQL Servera" postavljena, a postavka "Maksimalna memorija" mora biti postavljena na najvišu postavku. Za optimalan rad, SQL Serveru bi trebalo dozvoliti da uzme onoliko RAM-a koliko mu je potrebno za svoje potrebe, bez potrebe da se takmiči za RAM sa drugim aplikacijama.

Memorija: Dostupan prostor

Drugi način da saznate da li vaš SQL Server ima dovoljno fizičke RAM memorije jeste da proverite brojač Memorijski objekat: dostupnih bajtova. Njegova vrijednost mora biti veća od 5 MB. Inače, vašem SQL Serveru treba više fizičke RAM memorije. Na serveru specijalizovanom za SQL Server, ovaj drugi pokušava da zadrži 4-10MB slobodne fizičke memorije. Preostali fizički RAM koriste operativni sistem i SQL Server. Kada je količina dostupne memorije blizu 5 MB ili manje, najvjerovatnije je da je SQL Server preopterećen zbog malo memorije. Ako je to slučaj, morate povećati količinu fizičke RAM memorije na serveru, smanjiti opterećenje servera ili u skladu s tim promijeniti postavke konfiguracije memorije SQL Servera.

Fizički disk: % radnog vremena diska

Ovaj brojač pokazuje koliko je zauzet fizički niz diskova (ne logička particija ili pojedinačni disk u nizu). Pruža dobru relativnu mjeru zauzetosti vaših diskova.

Po pravilu, brojač vremena na disku treba da čita manje od 55%.

Ako očitanja brojača prelaze 55% u neprekidnim periodima (većim od 10 minuta tokom 24 sata praćenja), onda vaš SQL Server možda ima problema s I/O. Ako ovo ponašanje vidite samo povremeno tokom 24 sata praćenja, ne bih se previše brinuo, ali ako se dešavalo često (recimo, nekoliko puta na sat), onda bih počeo tražiti načine da povećam I/O performanse na serveru ili smanjiti opterećenje servera. Neki načini da povećate I/O diska su dodavanje novih diskova u niz (ako je moguće), zamjena diskova bržim, dodavanje keša na ploči kontrolera (ako je moguće), korištenje različitih verzija RAID-a ili instaliranje bržeg kontrolera .

Prije korištenja ovog brojača pod NT 4.0, morate ga ručno omogućiti unošenjem sljedećeg u komandnu liniju: "diskperf-y". Nakon ovoga moraćete ponovo pokrenuti server. Stoga morate odmah omogućiti brojače diskova pod Windows NT 4.0. Ako koristite Windows 2000, ovaj brojač je podrazumevano omogućen.

Osim praćenja vrijednosti brojača "Physical Disk: Disk Uptime", preporučljivo je pratiti i vrijednost brojača prosječne dužine reda čekanja na disku (Pros. dužina čekanja diska). Ako ova vrijednost prelazi 2 za kontinuirane periode (veće od 10 minuta tokom vašeg 24-satnog perioda praćenja) za svaki pogon u nizu, tada niz može biti usko grlo u performansama sistema. Slično kao kod tajmera na disku, ako se ovo dešava povremeno tokom perioda praćenja od 24 sata, ne bih se previše brinuo, ali ako se dešava često, onda bih počeo da tražim načine da povećam I/O performanse servera, kao što je opisano gore.

Morat ćete izračunati ovu cifru jer Performance Monitor ne zna koliko fizičkih diskova ima u vašem nizu. Na primjer, ako imate niz od 6 fizičkih diskova, a prosječna dužina reda čekanja je 10 za taj niz, tada je stvarni prosječni red čekanja po disku 1,66 (10/6=1,66), što dobro spada u preporučena 2- po-1 fizički disk.

Prije korištenja ovog brojača pod NT 4.0, obavezno ga ručno omogućite tako što ćete ukucati "diskperf-y" u NT Command Prompt i zatim ponovo pokrenuti server. Stoga je potrebno uključiti brojače diskova odmah nakon instaliranja Windows NT 4.0. Ako koristite Windows 2000, ovaj brojač će po defaultu biti omogućen.

Upotrijebite oba gore opisana brojača kako biste točno utvrdili da li vaš server ima problema s I/O. Na primjer, ako vidite mnogo vremenskih perioda u kojima je vrijeme rada diska veće od 55% i kada je prosječna dužina reda čekanja na disku veća od 2 po fizičkom disku, možete biti sigurni da server ima I/O problem.

Procesor: CPU vrijeme %

Brojač procesorskog objekta: % Processor Time je dostupan za svaki CPU i procjenjuje korištenje svakog pojedinačnog CPU-a. Sličan brojač je takođe dostupan za ceo set centralnih procesora (ukupan broj). Ovo je ključni brojač za praćenje upotrebe CPU-a. Ako ukupno vrijeme učitavanja procesora za ovaj brojač prelazi 80% za kontinuirane periode (preko 10 minuta tokom 24-satnog perioda praćenja), onda možete smatrati da je CPU usko grlo sistema. Ako se ovi periodi velikog opterećenja javljaju povremeno, a mislite da možete živjeti s tim, onda je sve u redu. Ali ako se javljaju često, trebali biste razmotriti opcije za smanjenje opterećenja servera kao što je kupovina bržih CPU-a, instaliranje više CPU-a ili kupovina CPU-a koji imaju veću ugrađenu L2 keš memoriju.

Sistem: Dužina čekanja CPU-a

Uz brojač CPU vremena, trebali biste pratiti i brojač dužine čekanja procesora. Ako ova stopa premašuje 2 po CPU-u za neprekidne periode (veće od 10 minuta tokom vašeg 24-satnog perioda praćenja), onda je vjerovatno usko grlo u sistemu. Na primjer, ako vaš server ima 4 CPU-a, dužina CPU reda ne bi trebala premašiti ukupno 8.

Ako dužina reda CPU-a redovno premašuje preporučeni maksimum, ali iskorištenost CPU-a nije tako visoka (što je tipičan slučaj), razmislite o smanjenju vrijednosti konfiguracijskog parametra "maksimalni broj radnih niti" SQL Servera.

Mogući razlog za veliku dužinu čekanja CPU-a je prisustvo prevelikog broja radnih niti koje čekaju na svoj red. Smanjenje njihovog broja, što radite s ovim parametrom, prisiljava vas da koristite prikupljanje niti (ako to već nije slučaj) ili povećate njegovu ulogu.

SQL Server Buffer: Stopa pogodaka u keš memoriji međumemorije

Ovaj brojač (SQL Server Buffer: Buffer Cache Hit Ratio) pokazuje koliko često SQL Server pristupa baferu, a ne čvrstom disku radi preuzimanja podataka. U OLTP aplikacijama, ovaj omjer bi trebao premašiti 90%, a idealno bi bio veći od 99%. Ako je vaša stopa pogodaka keša bafera ispod 90%, trebali biste izaći i kupiti više RAM-a danas. Ako je ovaj omjer između 90% i 99%, onda biste trebali ozbiljno razmisliti o kupovini više RAM-a, jer što se više približavate 99%, brže će raditi vaš SQL Server. U nekim slučajevima, ako je vaša baza podataka veoma velika, nećete moći da se približite 99% čak i ako stavite maksimalnu količinu RAM-a na vaš server. Tada sve što možete učiniti je dodati što više memorije i prihvatiti status quo.

U OLAP aplikacijama, omjer može biti mnogo manji zbog prirode OLAP aplikacije. U svakom slučaju, povećanje RAM-a bi trebalo ubrzati SQL Server.

SQL Server: Korisničke veze

Budući da broj korisnika SQL Servera utiče na njegove performanse, preporučuje se praćenje brojača korisničkih veza (SQL Server General Statistics Object: User Connections counter). Prikazuje broj korisničkih veza, a ne broj korisnika koji su povezani na SQL Server u datom trenutku.

Ako je ovaj brojač veći od 255, trebali biste povećati konfiguracijski parametar "Maximum Worker Threads", koji je zadana vrijednost 255. Ako broj veza premašuje broj dostupnih radničkih niti, SQL Server će početi dijeliti radne niti, što može negativno učinak učinka. Postavka ovog parametra bi trebala biti veća od maksimalnog broja veza koji se mogu postići na vašem serveru.

Šta je sledeće

Iako postoji mnogo više brojača od onih koje smo pokrili, potonji su ključni za praćenje koje se dešava tokom procesa revizije učinka. Kada završite analizu Performance Monitora, koristite preporuke date u ovoj seriji članaka da napravite potrebne promjene koje će učiniti da vaš SQL Server radi na način na koji bi trebao.

Svaki administrator baze podataka vjerovatno se morao suočiti s činjenicom da sve radi sporo ili uopće ne radi. Prva stvar koju treba da saznate je šta se trenutno dešava na SQL Serveru. Čini se da administrator ima toliko korisnih stvari u svom arsenalu: glupi Monitor aktivnosti, gomilu dinamičkih pogleda upravljanja (dmv), pohranjene procedure sp_who i sp_who2, naslijeđene iz dana SQL Servera 7 i SQL Servera 2000.
Ali hajde da shvatimo...

Alati za praćenje

Monitor aktivnosti
Čini se da je to odlična stvar, radi upravo ono što treba - prati aktivnost. Pokrećem težak računovodstveni izvještaj i vidim šta mi prikazuje Activity Monitor.
Snimci ekrana prikazuju monitor aktivnosti sa SQL Servera 2005:

I sa SQL Server Denali (2012) CTP 3.


Hmmm. Šta ako desetak ljudi vodi takve izvještaje? I to nije neuobičajeno... Biće prilično nezgodno shvatiti, iako je, naravno, napredak očigledan. U Denali Activity Monitor prikazuje mnogo više korisnih informacija (na primjer, na kojem se konkretnom resursu čeka čekanje), plus, možemo, na primjer, pokrenuti profiler za željenu sesiju direktno sa monitora i pratiti ga već u profileru , ali, dovraga, dodatno učitava i već preopterećen server. Osim toga, već postoji problem sa kočnicama, a nećemo vidjeti one zahtjeve koji su već počeli da se izvršavaju u trenutku kada je profiler pokrenut.
A to je upravo ono što želim da vidim – ko šta radi u ovom trenutku.

sp_who i sp_who2
Snimak ekrana prikazuje rezultat izvršavanja sp_who (gore) i sp_who2 (dolje), izvršenog prilikom pravljenja istog nesretnog izvještaja:


Da. Vrlo informativno. Gledajući sp_who možemo vidjeti samo da nešto radi. Naravno da se izvršava - zato gledamo, ali vidimo da se izvršava neka vrsta SELECT. Ili nekoliko SELECT-ova.
sp_who2 prikazuje više informacija. Sada možemo vidjeti koliko je procesorskog vremena potrošeno na sesiju (i zbrojiti ukupno vrijeme u koloni, naizgled), broj I/o operacija, naziv baze podataka u kojoj se sve ovo izvodi i ko je ovo sesija je blokirana (ako je blokirana).
Monitor aktivnosti, kao što vidimo, pruža više informacija.
DMV
Počevši od SQL Servera 2005, imamo novu mogućnost da dobijemo informacije o stanju servera - Dinamički prikazi upravljanja. MSDN kaže ovo: "Dinamički prikazi upravljanja i funkcije vraćaju podatke o zdravlju servera koji se mogu koristiti za praćenje zdravlja instance servera, dijagnosticiranje problema i podešavanje performansi."
Zaista, u SQL Serveru 2005 postoji skup pogleda koji se odnosi na izvršavanje upita u trenutnom trenutku (međutim, postoje i pogledi za gledanje „istorije“): evo ih i njihov broj se nastavlja povećavati od verzije do verzije!
Sigurno da iskusni administratori imaju gomilu skripti spremnih da dobiju informacije o trenutnom stanju servera, ali šta učiniti ako još nemate iskustva u radu sa DMV-om, ali već postoje problemi?

sp_WhoIsActive

Adam Machanic (SQL Server MVP i MCITP) je razvio i stalno poboljšava pohranjenu proceduru sp_WhoIsActive, koja se oslanja na te iste DMV-ove i prokleto je jednostavna za korištenje. Možete preuzeti najnoviju verziju sp_WhoIsActive. Sam Adam ima seriju članaka posvećenih sp_WhoIsActive, koja se sastoji od čak 30 (trideset!) komada, možete ga pročitati, ali ja ću se potruditi da vas zainteresujem za čitanje ovog materijala :).
Dakle, pretpostavićemo da ste preuzeli i pokrenuli ovu skriptu na jednom od test servera (na bilo kojoj verziji, od 2005 do Denali). Adam savjetuje da je pohranite u bazu podataka glavnog sistema kako bi se mogla pozvati u kontekstu bilo koje baze podataka, ali to nije potrebno, samo kada je pozivate u kontekstu druge baze podataka, morat ćete napisati ime u cijelosti - DB .schema.sp_whoIsActive.
Pa hajde da probamo. Snimak ekrana prikazuje rezultat njegovog izvršenja pri izradi istog izvještaja:

Rezultat upita exec sp_whoIsActive, nažalost, ne stane u jedan ekran, pa evo tekstualnog opisa izlaza pohranjene procedure pozvane bez parametara.
  • - za aktivni zahtjev prikazuje vrijeme izvršenja, za "sleeping" sesiju - vrijeme "sleep";
  • - zapravo, spid;
  • - prikazuje tekst zahteva koji se trenutno izvršava, ili tekst poslednjeg završenog zahteva ako sesija spava;
  • - pa, razumete;
  • - veoma interesantna kolumna. Izlazi u formatu (Ax: Bms/Cms/Dms)E. A je broj zadataka koji čekaju na resursu E. B/C/D je vrijeme čekanja u milisekundama. Ako postoji samo jedna sesija koja čeka da se resurs oslobodi (kao na snimku ekrana), njegovo vrijeme čekanja će biti prikazano, ako postoje 2 sesije, njihova vremena čekanja će biti prikazana u B/C formatu. Ako 3 ili više čekaju, videćemo minimalno, prosečno i maksimalno vreme čekanja na OVOM resursu u B/C/D formatu;
  • - za aktivni zahtjev - ukupno CPU vrijeme potrošeno na ovaj zahtjev, za sesiju mirovanja - ukupno CPU vrijeme za "cijeli život" ove sesije;
  • - za aktivni upit, ovo je broj operacija pisanja u TempDB tokom izvršenja upita; za spavajuću sesiju - ukupan broj zapisa u TempDB-u za cijeli životni vijek sesije;
  • - za aktivni zahtjev - broj stranica u TempDB-u dodijeljenih za ovaj zahtjev; za spavajuću sesiju - ukupan broj stranica u TempDB-u dodijeljenih tokom cijelog životnog vijeka sesije;
  • - ako nas iznenada neko blokira, pokazaće se spid (session_id) osobe koja nas je blokirala;
  • - za aktivni zahtjev - broj logičkih čitanja izvršenih prilikom izvršavanja ovog zahtjeva; za spavajuću sesiju - broj stranica pročitanih tokom čitavog trajanja ove sesije;
  • - sve je isto, ali o snimanju;
  • - za aktivni zahtjev - broj fizičkih čitanja izvršenih prilikom izvršavanja ovog zahtjeva; za seansu spavanja - tradicionalno, ukupan broj fizičkih očitavanja tokom čitavog trajanja sesije;
  • - za aktivni zahtjev - broj stranica od osam kilobajta korištenih prilikom izvršavanja ovog zahtjeva; za sesiju spavanja - koliko mu je ukupno memorijskih stranica dodijeljeno tokom cijelog životnog vijeka;
  • - status sesije - trčanje, spavanje, itd.;
  • - prikazuje broj transakcija otvorenih ovom sesijom;
  • - prikazuje, ako je moguće, napredak operacije (na primjer, BACKUP, RESTORE), nikada neće pokazati koliko je posto SELECT završeno.
Preostale kolone u standardni izlaz sp_WhoIsActive su malo interesantni i neću ih opisivati ​​- njihova svrha je, mislim, svima jasna (host_name, database_name, program_name, start_time, login_time, request_id, collection_time).

Pa šta? Ovo je sve?

Ne, to nije sve. Također ću govoriti o tome s kojim (s moje tačke gledišta najzanimljivijim i najkorisnijim) parametrima možete pozvati sp_WhoIsActive i šta će iz toga proizaći.
  • @help je užasno korisna opcija. Kada pozovemo sp_whoIsActive @help = 1, dobijamo informacije o SVIM parametrima i izlaznim kolonama na ekranu. Dakle, ako nešto ostane nejasno, uvijek možete pogledati "pomoć"
  • @filter_type i @filter - omogućavaju vam da filtrirate rezultat izvršenja. @filter_type može uzeti vrijednosti "session", "program", "database", "login" i "host". U parametru označavamo koji nas objekt odabranog tipa zanima. Na primjer, želimo vidjeti sve sesije koje se izvode u glavnoj bazi podataka, da bismo to učinili pozivamo exec sp_whoIsActive @filter_type = "database", = "master" . Možete koristiti "%" u parametru;
  • @not_filter_type i @not_filter - omogućavaju nam da filtriramo "obrnuto". To jest, na primjer, želimo vidjeti sve osim onih sesija koje imaju “master” u polju “database”, za to izvršavamo exec sp_WhoIsActive @not_filter_type = “database”, @not_filter = “master” . Pa, ili, želimo vidjeti šta svi korisnici osim korisnika sa rade... Može biti mnogo aplikacija. Parametar @not_filter dozvoljava upotrebu "%";
  • @show_system_spids = 1 - prikazaće informacije o sistemskim sesijama;
  • @get_full_inner_text = 1 - polje sql_text će sadržavati ne samo tekst trenutnog zahtjeva (izvoda) u grupi (batch), već i tekst cijele grupe;
  • @get_plans - će dodati kolonu sa planovima za izvršenje upita na izlaz;
  • @get_transaction_info = 1 - na izlaz će dodati broj i obim unosa u evidenciji transakcija, kao i vrijeme početka posljednje transakcije;
  • @get_locks = 1 - dodaće izlaznim informacijama o svim zaključavanjima primenjenim tokom izvršavanja zahteva;
  • @find_block_leaders = 1 - će pratiti lanac blokiranja i prikazati ukupan broj sesija koje čekaju da trenutna sesija ukloni blok;
  • @output_column_list = "[%]" - šta ako ne želite da vidite tempDB informacije u sp_whoIsActive izlazu? Ova opcija vam omogućava da kontrolišete šta ona daje;
  • @destination_table = "table_name" - pokušaće da ubaci rezultat izvršenja u tabelu, ali neće proveriti da li ova tabela postoji i da li ima dovoljno prava za umetanje u nju.

To je sada sve

Kao rezultat toga, imamo još jedan izuzetno zgodan i fleksibilan alat za praćenje trenutne aktivnosti na SQL Serveru. Za njegov normalan rad dovoljna je dozvola VIEW SERVER STATE i prava pristupa dmv-u.
Također je vrijedno dodati u slučaju kada se server može povezati samo preko