Acesta este un produs software de la Sybase care funcționează împreună cu SQL Server și oferă o varietate de informații despre performanța serverului sub formă grafică. Aceste informații sunt extrem de utile în analizarea motivelor scăderii performanței sale.

versiunea 11.0.1 are o serie de noi caracteristici importante care disting semnificativ noua versiune de toate cele anterioare. 11.0.1 poate funcționa cu orice versiune de SQL Server de la 4.9.2 la System 11.

Cu toate acestea, unele dintre cele mai interesante tipuri de informații despre tiparele de utilizare a obiectelor bazei de date și interacțiunea serverului cu rețeaua sunt furnizate numai atunci când se monitorizează SQL Server System 10 și System 11. Desigur, datele despre performanța bufferelor cache numite sunt furnizat numai la monitorizarea performanței SQL Server System 11.

Pentru compatibilitate cu versiunile anterioare, 11.0.1 acceptă, de asemenea, un mod de transmitere a informațiilor statistice despre performanța serverului în fișiere care pot fi utilizate pentru comparare și analiză ulterioară. Această caracteristică este foarte utilă în practică, dar utilizarea ei complică procesul de instalare.

constă din două componente: un modul server care rulează pe aceeași mașină cu SQL Server pentru a oferi acces la zona de memorie partajată a serverului și un modul client care poate rula pe orice computer. Sarcina principală a modulului client este de a citi informațiile acumulate de modulul de server și de a le prezenta utilizatorului în formă grafică.

La pornire, trebuie să anulați verificarea memoriei serverului efectuată de comanda dbcc memusage, deoarece această comandă încetinește semnificativ serverul. Pentru a face acest lucru, la pornirea sqlmon (modul client), trebuie să specificați parametrul – nomem.

Configurația implicită permite conectarea simultană a până la cinci module client la un modul server. Cu alte cuvinte, un modul server poate fi conectat fie la cinci module client cu o fereastră pe fiecare client, fie la un client cu cinci ferestre deschise.

Numărul maxim de ferestre client deschise simultan este setat la pornirea modulului server.

Deci, pentru a accepta 20 de ferestre în fișierul de comandă pentru lansarea modulului server, trebuie să specificați parametrul p2 0. În acest caz, va trebui să schimbați adresa de la începutul zonei de memorie partajată a serverului folosind comanda buildmaster și alte acțiuni. Aceste acțiuni nu ar trebui să fie efectuate niciodată în timp ce SQL Server rulează. (Pentru detalii despre procesul de extindere a numărului de clienți concurenți acceptați, consultați manualul Server Supplement.)

are unele dezavantaje. De exemplu, o diagramă cu bare care arată numărul de operațiuni I/O în curs și alte caracteristici de performanță ale dispozitivelor server poate raporta date numai pe un număr limitat de dispozitive simultan.

Acest lucru este incomod atunci când monitorizați un server mare cu un număr mare de dispozitive server. În plus, utilizatorul nu poate selecta dispozitivele pentru care informațiile vor fi incluse în diagramă sau nu poate comuta între diferite seturi de dispozitive.

Tabelul text care apare pe ecran simultan cu diagrama conține o listă a tuturor dispozitivelor server, dar include doar numărul total de operațiuni I/O pentru fiecare dintre ele. Acest lucru este deosebit de dificil atunci când lucrați cu un server mare care are multe dispozitive server care acceptă segmente de baze de date pentru utilizatori pentru a-și îmbunătăți performanța. În acest caz, analiza funcționării tuturor segmentelor existente este imposibilă.

De asemenea, nu permite ca dinamica modificărilor indicatorilor de performanță să fie afișată pe ecran pentru o lungă perioadă de timp.

Este capabil să afișeze date pentru 60 de intervale consecutive de măsurare a performanței. În funcție de durata aleasă pentru fiecare interval, astfel de statistici pot acoperi o perioadă de timp destul de mare. Cu toate acestea, această tehnică nu face posibilă compararea datelor actuale cu indicatorii de acum o lună sau un an.

Desigur, imaginile ferestrelor programului pot fi scoase la o imprimantă, dar apoi va trebui să stocați seturi de fișiere sau munți de imprimări pentru a evalua performanța viitoare a serverului. În practică, un administrator de server va trebui adesea să reexamineze datele colectate în momente diferite ale ciclului de afaceri al unei companii, precum și informații de referință încrucișată în perioade similare în cicluri de afaceri succesive, pentru a obține o perspectivă asupra performanței reale a serverului.

Deoarece pornirea duce la o oarecare încetinire a serverului, înainte de a începe măsurătorile este necesar să se determine amploarea acestei încetiniri pentru o anumită platformă hardware și software. O modalitate bună de măsurare este să rulați un set standard de tranzacții de testare.

Poate fi folosit atât dacă este prezent sau nu pe mașina server. Chiar dacă nu există module client, modulul server al programului continuă să funcționeze și trebuie oprit cu o comandă separată.

vă permite să afișați mai multe ferestre grafice diferite, fiecare dintre acestea conținând informații despre un anumit aspect al funcționării serverului.

Fereastra principala
Acesta conține o listă de ferestre acceptate de program. Dacă, la lansarea sglmon, modulul client, parametrul – nomem nu a fost specificat, această fereastră va afișa și o diagramă circulară a utilizării memoriei mașinii server.

Buffer-uri cache (cache)
Această fereastră afișează grafice care caracterizează funcționarea procedurilor și a bufferelor cache de date. Prin controlul numărului de operațiuni I/O fizice și logice din memoria cache de date, utilizatorul poate determina cât de mult din pagina de date accesează serverul, folosind paginile aflate deja în buffer. Aceste statistici, obținute pentru buffer-ul de date și buffer-ul de procedură, ne permit să determinăm cantitatea totală de memorie necesară de buffer-urile cache ale serverului și raportul dintre bufferele cache de date și proceduri.

Cache pentru buffer de date, numai SQL Server System 11 (cache de date)
Fereastra raportează numărul de operațiuni I/O fizice și logice pentru fiecare dintre bufferele cache numite configurate pe server.

I/O disc
Aici puteți găsi grafice și tabele rezumative pentru numărul curent și total de accesări la disc. Acestea ajută la optimizarea distribuției sarcinii I/O între dispozitivele server existente. Când analizați informațiile de ieșire, este util să folosiți schema standard pentru selectarea numelor dispozitivelor server pe baza numelor secțiunilor corespunzătoare ale discurilor fizice, deoarece, în timp ce monitorizați cursul de schimb cu dispozitivele server, ar trebui să știți ce controler de disc. fiecare dintre aceste dispozitive este conectat.

Lucrul cu rețeaua, numai pentru SQL Server System 10 și 11 (Activitate în rețea)
Fereastra raportează informații statistice despre intrarea și ieșirea rețelei - dimensiunile pachetelor, volumele de trafic etc.

Blocarea accesului la obiecte, numai pentru SQL Server System 10 și 11 (Stare de blocare a obiectelor)
Aceasta afișează informații despre blocările de acces la tabelul de date, inclusiv o defalcare detaliată a tipurilor de blocare utilizate, numele proceselor care dețin blocarea etc.

I/O pagină obiect, numai Sistemul SQL Server 10 și 11 (I/O pagină obiect)
Fereastra conține informații despre intensitatea paginilor I/O ale unuia dintre tabelele de date ale serverului. Acordați atenție eficienței atunci când compilați o listă cu cele mai frecvent utilizate tabele de server. Acest tip de informații nu este returnat de sp_sysmon.

Rezumatul performanței
Aceasta oferă o imagine de ansamblu a modului în care funcționează SQL Server - procentul din timpul CPU utilizat, numărul de tranzacții procesate pe secundă, volumul de trafic de rețea, I/O disc și utilizarea blocării.

Tendință de performanță
Fereastra prezintă grafice continue ale indicatorilor de performanță ai serverului afișați în fereastra Rezumatul performanței în funcție de timp.

Activitate de proces de server (Activitate de proces)
Fereastra vă permite să selectați unul sau mai multe procese server și să monitorizați utilizarea CPU și volumele I/O pentru fiecare proces.

Detaliu proces
Fereastra conține informații detaliate despre procesul de server selectat.

Lista de procese
Fereastra conține o listă a tuturor proceselor de server disponibile în prezent, cu o indicație a stării acestora. Foarte similar cu emiterea comenzii server sp_who.

Utilizarea activității de blocare a procesului
Fereastra oferă informații despre utilizarea lacăturilor de către procesul de server pe care l-ați selectat.

Utilizarea activității de procedură stocată
Fereastra conține informații despre execuția procedurilor stocate și timpul de rulare al fiecărei proceduri.

Activitatea de tranzacție
În fereastră, puteți vedea o diagramă cu bare care arată numărul de tranzacții în curs de procesare, defalcate pe diferite tipuri de tranzacții. Puteți vedea, de exemplu, ce parte a tranzacțiilor poate fi finalizată folosind mecanismul de actualizare în loc.

26.12.2006 Kevin Kline

Care este ultima întrebare pe care ar dori să i se pună un DBA? Probabil un mesaj de la utilizator despre deteriorarea aplicației sau o întrebare despre ce s-a întâmplat cu baza de date. Trebuie să lăsăm totul deoparte și să intrăm în „modul de urgență”, întrebându-ne cât va dura acest lucru. Întrucât una dintre principalele responsabilități ale unui administrator de baze de date este să asigure funcționarea de înaltă calitate a bazelor de date industriale, tot ce rămâne este să remedieze problema cât mai repede posibil. De regulă, nu există timp pentru a afla cauza eșecului.

Gata cu locurile de muncă în grabă - doar observație sistematică

Dar acesta este singurul lucru care se poate face? Există capacitatea de a efectua monitorizarea proactivă a performanței, o procedură simplă de management care utilizează determinarea liniei de bază a sistemului, evaluarea comparativă și monitorizarea continuă. În acest articol, voi vorbi despre cum să utilizați monitorizarea proactivă și despre cum să creați un sistem de monitorizare gratuit folosind Windows System Monitor.

Monitorizare proactiva

Monitorizarea proactivă a performanței este un sistem simplu care vă ajută să rezolvați problemele înainte ca acestea să devină critice. Unii oameni probabil folosesc deja monitorizarea excepțiilor, unde creează procese automate care observă doar anomalii, dar nu oferă informații aprofundate sau capacitatea de a preveni problemele. Monitorizarea proactivă a performanței, pe de altă parte, oferă utilizatorului tot felul de informații despre mediul de lucru și aplicații, atât pe termen scurt, cât și pe termen lung. Sunt luate contoare de performanță a bazei de date, sunt stabilite valorile de referință și monitorizarea activă este menținută.

După cum sugerează și numele, monitorizarea proactivă a performanței necesită acțiuni. Este nevoie de puțin timp pentru instalare și ceva timp pentru a înțelege cum funcționează bazele de date și aplicațiile. Pentru ca monitorizarea proactivă a performanței să fie eficientă, mesajele trebuie revizuite, astfel încât datele bogate colectate să poată fi valorificate.

Parametri de bază, standard, monitor

Să începem prin a defini câțiva termeni. Parametri de bază (linie de bază) este un set de parametri care reflectă comportamentul serverului și al aplicației în condiții normale. Parametrii de bază au fost obținuți ca medii pe baza rezultatelor mai multor măsurători efectuate în aceleași condiții; sunt repere pentru comparație.

Benchmark arată performanța sistemului la un anumit nivel de încărcare a serverului, ceea ce vă permite să comparați performanța unui server industrial la acest nivel și să determinați performanța serverului, cu cât sunt mai mari sau mai scăzute decât în ​​mod normal (adică atunci când serverul funcționează slab). La fel ca parametrii de bază, valorile de referință sunt luate într-un mediu controlat, valorile cheie sunt determinate în raport cu indicatorii predefiniți. Dacă trebuie să vedeți cum se comportă serverul și aplicația la mai multe niveluri sau tipuri de încărcare, atunci obțineți de obicei mai multe valori de referință (în raport cu parametrii de bază)

Monitorizarea- aceasta este o monitorizare planificată în timp real a serverului în condiții predefinite (seturi de condiții definite pentru investigații ulterioare sau avertismente). De exemplu, dacă doriți să știți cât timp durează o aplicație de afaceri critică să ruleze cu succes, cât durează o copie de rezervă sau când sunt atinse anumite etape de performanță, acele evenimente specifice sunt monitorizate.

Acum să trecem la monitorizarea proactivă. Puteți utiliza produse terțe sau o soluție gratuită care utilizează System Monitor. Soluțiile de la terți pot simplifica procesul de configurare a monitorizării proactive și pot avea caracteristici diferite decât le poate oferi o soluție gratuită încorporată. Dar înainte de a începe, vă voi arăta cum să începeți cu monitorizarea proactivă folosind System Monitor.

Pasul 1: Definiți liniile de bază ale performanței.

La prima etapă de asigurare a modului de monitorizare proactivă se stabilește un set de parametri de bază pentru funcționarea serverului de baze de date. Acest agregat indică performanța serverului în condiții normale, ajută la documentarea și înțelegerea tuturor proceselor de fundal semnificative și, de asemenea, ajută la identificarea situațiilor care nu necesită intervenție, astfel încât să poată fi ignorate în viitor. Cu alte cuvinte, administratorii bazelor de date pot defini opțiuni pentru a ignora mesajele de sistem, deoarece în caz contrar se generează un număr mare de notificări false.

Pentru a arăta clar calitatea operațiunii, cele mai bune linii de bază folosesc câteva grafice (ideal unul), astfel încât să puteți vedea dintr-o privire cum funcționează serverul. Odată ce parametrii de bază au fost determinați, trebuie să faceți următoarele. Mai întâi, selectați opțiunea de a salva datele de performanță în jurnalul de sistem sau de a le afișa în timp real. Este ideal să aveți ambele: jurnalele vă permit să vă uitați înapoi la citiri în orice moment pentru a analiza cum era performanța când nu monitorizați direct sistemul. Monitorizarea în timp real nu ocupă spațiu pe disc sau resurse de server, dar necesită 100% din atenția dumneavoastră asupra sistemului. În al doilea rând, trebuie să determinați intervalul la care va fi efectuată monitorizarea, ținând cont de costurile de performanță ale colectării datelor și ale operațiunilor de I/O de date și să estimați costul spațiului necesar. Cu cât intervalul este mai lung, cu atât este mai mare probabilitatea ca datele de performanță de interes să nu fie obținute. În cele din urmă, alegeți monitorizarea locală sau la distanță. Monitorizarea locală, în care procesul de monitorizare folosește un server monitorizat, adaugă CPU și disc overhead la server. Monitorizarea de la distanță, care utilizează un server separat, poate elimina aceste probleme, dar crește foarte mult volumul de lucru în rețea.

Enumeră valorile sau contoarele System Monitor pe care vă recomandăm să le folosiți pentru a vă determina valoarea de bază. Nu pot spune care este valoarea „corectă” în contextul unei anumite aplicații, deoarece variază de la sistem la sistem. Utilizați media diferitelor linii de bază pentru a seta performanța normală a liniei de bază și indicați că aceasta este opțiunea corectă pentru sistemul utilizat.

Definirea setărilor de bază cu ajutorul monitorului de sistem

Acum, în scopul colectării parametrilor de bază, să apelăm System Monitor. Să deschidem Panoul de control, Instrumente administrative, Performanță. Faceți dublu clic pe Jurnalele de performanță și alertele din panoul din stânga. Să facem clic dreapta pe Counter Logs și să selectăm New Log Settings. Introduceți un nume pentru grafic, apoi faceți clic pe OK. În caseta de dialog Selectați contoare, selectați primul contor, apoi faceți clic pe Adăugare. Repetați acești pași până când toate contoarele au fost adăugate, apoi faceți clic pe Închidere.

Mai întâi, încercați intervalul implicit de 15 secunde. Sau selectați un interval diferit făcând clic pe Proprietăți (sau utilizați comanda rapidă de la tastatură Ctrl + Q), apoi introduceți o valoare etichetată Sample automat la fiecare: _ secunde. Intervalele mai lungi ocupă mai puțin spațiu, dar oferă date mai puțin detaliate.

Selectați tabelul Fișiere jurnal și determinați unde vor fi stocate datele. Puteți vizualiza datele ulterior utilizând vizualizarea Vizualizare date fișier jurnal. System Monitor va arăta ca în figura 1 când colectează date de performanță de bază. Se poate observa că o mulțime de date pot fi colectate prin monitorizarea mai multor contoare în același timp, așa că ar trebui să selectați cu atenție contoare pentru linia principală.

Pasul 2: Setarea valorilor de referință

Odată ce linia de bază a performanței unui server a fost stabilită, puteți începe să setați benchmark-uri, ceea ce face mai ușor să înțelegeți performanța serverului atunci când rulați în mai multe situații predefinite.

Pentru standarde, se utilizează același mod de monitorizare ca și pentru determinarea parametrilor de bază. Puteți utiliza propria dvs. soluție sau unul dintre instrumentele obișnuite din industrie, cum ar fi TPC-C sau SAP, dar cele mai bune rezultate pentru calcularea valorilor de referință sunt obținute prin dezvoltarea de scripturi personalizate comune care sunt configurate să utilizeze un anumit server de bază de date și aplicațiile acestuia. .

Vă puteți crea propriul script utilizând suita de scripturi T-SQL, utilitarele osql sau Query Analyzer, SQL Profiler și System Monitor. Dezvoltarea scripturilor de testare a încărcării în T-SQL durează de obicei câteva zile. Poate fi necesar și mai mult timp pentru a colecta datele de execuție a testului de încărcare și pentru a analiza datele rezultate.

Odată ce ați stabilit o linie de bază a performanței serverului sub sarcini de lucru predefinite, puteți ști la ce să vă așteptați de la sistem. Utilizați datele colectate în obținerea valorilor de referință pentru a forma baza pentru monitorizarea de rutină. De exemplu, serverul s-a dovedit a fi capabil să livreze până la 249 de tranzacții pe secundă înainte de a începe să încetinească. În acest caz, puteți seta o notificare cu prioritate scăzută când serverul atinge aproximativ 200 TPS și o notificare cu prioritate ridicată când serverul ajunge la 235 TPS. Această metodă va permite administratorului să afle despre posibilele probleme cu serverul și să ia măsurile necesare înainte ca utilizatorii să observe ceva. Și fără situații critice. Acum este posibil.

Pasul 3: Monitorizare programată

Poate cea mai importantă componentă a unui regim de monitorizare proactivă este monitorizarea planificată. Fără acesta, nu puteți monitoriza performanța bazei de date sau nu puteți detecta probleme de performanță.

Puteți crea un instrument de monitorizare SQL Server ieftin folosind o combinație de Agent SQL Server și Monitor de sistem. Agentul SQL Server vă permite să determinați ce eveniment a cauzat apariția unei erori pe monitor, să determinați cine primește notificări despre evenimente și să trimiteți automat o notificare când are loc un eveniment de eroare.

Instalarea Agentului SQL Server poate consuma mult timp și poate fi complexă, așa că va trebui să consultați secțiunea Alerte în SQL Server pentru mai multe informații. Cărți online (BOL). Agentul SQL Server monitorizează de obicei mesajele de eroare ale serverului de baze de date și nu monitorizează execuția.

Pentru a monitoriza performanța serverului, utilizați System Monitor pentru a monitoriza contoarele curente (setați frecvența de interogare la 15 minute).

Memorie-Pagini/sec

Interfață de rețea-octeți total/sec

Transferuri fizice disc-disc/sec

Procesor-% Procesor Time

SQLServer: Metode de acces - Scanări complete/sec

SQLServer:Buffer Manager-Buffer Cache Hit Ratio

SQLServer:Bază de date Aplicație Bază de date-Tranzacții/sec

SQLServer: Statistici generale-Conexiuni utilizator

SQLServer:Latches-Timp mediu de așteptare pentru blocare

SQLServer:Blocare-Timp mediu de așteptare

SQLServer:Locks-Lock Timeouts/sec

SQLServer:Locuri-număr de blocaje/sec

SQLServer: Manager de memorie-Acordări de memorie în așteptare

Setați valoarea pentru fiecare contor între valorile de bază și valorile de referință afișate prin testare. De exemplu, puteți seta o notificare când contorul atinge 75% din cea mai mare valoare de încărcare și un mesaj de avertizare când trece de 90%.

Pentru a efectua alerte, puteți utiliza instrumente gratuite, cum ar fi Alerte și notificări SQL Server, System Monitor sau puteți cumpăra Microsoft Operations Manager (MOM) sau alte instrumente. Recomand să setați alerte pentru cel puțin următoarele situații:

• erori care afectează funcționarea, în special erori cu un scor de severitate de la 19 la 25
• blocare
• Utilizarea procesorului
• utilizarea discului
• scanare (SQLServer:Metode de acces)

Alarmele pot fi trimise pentru a notifica administratorii prin e-mail, pager sau rețea. Puteți seta alerte automate pentru următoarele surse de mesaje:

• Jurnalul SQL Server
• Jurnalul agentului SQL
• Jurnalul de aplicații Windows, securitate și sistem
• Jurnalul de execuție a jobului SQL Server

În cele din urmă, trebuie să vă asigurați că propriile aplicații înregistrează corect erorile și, de asemenea, răspund la mesajele de eroare de la alte aplicații dezvoltate.

Monitorizarea proactivă a performanței SQL Server înseamnă stabilirea parametrilor de performanță de bază atât pentru server, cât și pentru aplicație; stabilirea unor benchmark-uri care simulează comportamentul serverului în funcție de un scenariu predeterminat în utilizare și efectuarea unei monitorizări programate, în mod ideal declanșând alerte atunci când este detectată o problemă. Indiferent dacă utilizați instrumente gratuite sau încorporate, fie că alegeți soluții terțe, controlul vă asigură că obțineți informațiile de care aveți nevoie atunci când aveți nevoie despre modul în care rulează aplicațiile dvs. pe SQL Server.

Tabelul 1. Obiecte și contoare System Monitor pentru determinarea parametrilor de bază

Obiect și contor	Descriere
Memorie-Pagini/sec	Numărul de pagini citite sau scrise pe disc pe secundă. Acest contor este un indicator principal al tipurilor de erori cauzate de întârzierile sistemului sau problemele de performanță
Interfață de rețea-octeți total/sec	Numărul de octeți care trec prin interfața de rețea pe secundă. Când acest contor scade sau are tendințe în acest fel, indică faptul că problemele de rețea pot afecta aplicația
Transferuri fizice-disc/sec	Estimarea operațiunilor de citire/scriere pe disc. Setați un contor pentru fiecare disc fizic de pe server
Procesor-% Procesor Time	Procentul de timp pe care procesorul îl petrece executând un fir de lucru. Acest contor acționează ca indicator principal al activității procesorului. Dacă toate procesoarele care rulează pe SQL Server arată o utilizare de 100%, este probabil ca interogările utilizatorilor finali să fie ignorate
SQLServer: Metode de acces - Scanări complete/sec	Scanări nelimitate de tabel sau index pe secundă. Scăderea acestui contor este în bine, deoarece vizualizările cauzează adesea lipsa de resurse și probleme de stocare în cache
SQLServer:Buffer Manager-Buffer Cache Hit Ratio	Procentul de pagini care nu au necesitat citiri pe disc. Cu cât numărul lor este mai mare, cu atât se efectuează mai puține I/O pe disc. Pe un sistem bine reglat, această valoare ar trebui să fie de 80 sau mai mare.
SQLServer:Bază de date-Creșteri de jurnal	Cât de mult a crescut fișierul tranzacției pentru o anumită bază de date? Pe un sistem bine reglat, acest contor ar trebui să fie scăzut, probabil mai puțin de unul la câteva zile
SQLServer:Bază de date Aplicație Bază de date-Procent Jurnal utilizat	Procentul de spațiu liber din fișierul jurnal. Acest contor variază conform planificării, dar nu ar trebui să ajungă la 100
SQLServer:Bază de date Aplicație Bază de date-Tranzacții/sec	Numărul de tranzacții confirmate în baza de date. Acest contor este omis din standarde uneori. Urmăriți când tranzacțiile încep în coadă, acesta este un indiciu că I/O pe disc poate fi lentă
SQLServer:Latches-Timp mediu de așteptare pentru blocare	Timpul mediu pe care o cerere persistă înainte de a fi completată. Această valoare a contorului poate fi mare atunci când serverul se confruntă cu o dispută pentru resurse, în special pentru memorie sau I/O
SQLServer:Blocare-Timp mediu de așteptare, Așteptări de blocare/sec, Număr de blocaje/sec	Blocările temporare dețin resursele SQL Server. Urmăriți o tendință ascendentă a acestor contoare legate de blocare, care indică o posibilă problemă de performanță
SQLServer: Statistici generale-Conexiuni utilizator	Numărul de conexiuni ale utilizatorilor la serverul bazei de date. Verificați dacă există modificări vizibile ale valorii acestui contor. Ele pot indica probleme de rețea și pot indica încărcări și încetiniri
SQLServer: Manager de memorie-Acordări de memorie în așteptare	Numărul curent de procese care așteaptă să fie alocat spațiu de memorie. O valoare ridicată sau în creștere poate indica o capacitate insuficientă de memorie
SQLServer:User Settable-Query (o interogare de urmărire)	Un contor specializat, cunoscut și sub numele de index de interogare. Acest contor este o interogare generată de utilizator care indică viteza sau eficiența generală a sistemului. Pentru a seta această valoare, aplicația apelează sp_user_counter1 și returnează o valoare numerică.

Orice administrator de baze de date a trebuit probabil să se ocupe de faptul că totul funcționează lent sau nu funcționează deloc. Primul lucru pe care trebuie să-l aflați este ce se întâmplă de fapt pe SQL Server în acest moment. S-ar părea că administratorul are atât de multe lucruri utile în arsenalul său: un monitor de activitate prost, o grămadă de vizualizări de management dinamic (dmv), proceduri stocate sp_who și sp_who2, moștenite din zilele SQL Server 7 și SQL Server 2000.
Dar hai să ne dăm seama...

Instrumente de monitorizare

Monitor de activitate

S-ar părea un lucru grozav, face exact ceea ce trebuie să facă - monitorizează activitatea. Lansez un raport contabil greu și văd ce îmi arată Monitorul de activitate.
Capturile de ecran arată un monitor de activitate din SQL Server 2005:

și din SQL Server Denali (2012) CTP 3.


Hmmm. Ce se întâmplă dacă o duzină de oameni lansează astfel de rapoarte? Și acest lucru nu este neobișnuit... Va fi destul de incomod să-ți dai seama, deși, desigur, progresul este evident. În Denali Activity Monitor afișează informații mult mai utile (de exemplu, despre ce resursă specifică are loc așteptarea), plus, putem, de exemplu, să lansăm un profiler pentru sesiunea dorită direct de pe monitor și să îl urmărim deja în profiler , dar, la naiba, se încarcă în plus și un server deja supraîncărcat. În plus, există deja o problemă cu frânele și nu vom vedea acele solicitări care începuseră deja să fie executate la momentul lansării profilelor.
Și asta este exact ceea ce vreau să văd - cine ce face acum.

sp_who și sp_who2

Captura de ecran arată rezultatul executării sp_who (sus) și sp_who2 (jos), executate în timp ce construim același raport nefast:


Da. Foarte informativ. Privind la sp_who, putem vedea doar că ceva rulează. Desigur, este executat - de aceea ne uităm, dar vedem că se execută un fel de SELECT. Sau mai multe SELECT-uri. Grozav.
sp_who2 afișează mai multe informații. Acum putem vedea cât timp a petrecut procesorul de către sesiune (și adunăm timpul total într-o coloană, aparent), numărul de operații de i/o, numele bazei de date în care sunt efectuate toate acestea și de către cine. sesiunea este blocată (dacă este blocată).
Monitorul de activitate, după cum vedem, oferă mai multe informații.

DMV

Începând cu SQL Server 2005, avem o nouă capacitate de a obține informații despre starea serverului - Dynamic Management Views. MSDN spune acest lucru: „Vizualizările și funcțiile de gestionare dinamică returnează date despre starea serverului care pot fi utilizate pentru a monitoriza starea de sănătate a unei instanțe de server, pentru a diagnostica probleme și pentru a regla performanța.”
Într-adevăr, în SQL Server 2005 există un set de vederi legate de executarea interogărilor în momentul actual (există totuși și vizualizări pentru vizualizarea „istoric”): iată-le. Și numărul lor continuă să crească de la versiune la versiune!
Cu siguranță, administratorii experimentați au o grămadă de scripturi pregătite pentru a obține informații despre starea actuală a serverului, dar ce să faceți dacă nu aveți încă experiență de lucru cu DMV, dar există deja probleme?

sp_WhoIsActive

Adam Machanic (SQL Server MVP și MCITP) a dezvoltat și îmbunătățește constant procedura stocată sp_WhoIsActive, care se bazează pe aceleași DMV-uri și este al naibii de ușor de utilizat. Puteți descărca cea mai recentă versiune de sp_WhoIsActive. Adam insusi are o serie de articole dedicate lui sp_WhoIsActive, formate din pana la 30 (treizeci!) de bucati, o puteti citi, dar voi incerca sa va interesez sa cititi acest material :).
Deci, vom presupune că ați descărcat și rulat acest script pe unul dintre serverele de testare (pe orice versiune, din 2005 până la Denali). Adam sfătuiește să-l stocați în baza de date a sistemului master, astfel încât să poată fi apelat în contextul oricărei baze de date, dar acest lucru nu este necesar, doar când îl apelați în contextul unei alte baze de date, va trebui să scrieți numele în întregime - DB .schema.sp_whoIsActive.
Deci hai să încercăm. Captura de ecran arată rezultatul execuției sale în timpul construirii aceluiași raport:

Rezultatul interogării exec sp_whoIsActive, din păcate, nu se încadrează într-un singur ecran, așa că aici este o descriere text a rezultatului unei proceduri stocate numită fără parametri.

• - pentru o cerere activă arată timpul de execuție, pentru o sesiune „sleeping” - timpul „sleep”;
• - de fapt, spid;
• - afișează textul cererii în curs de execuție sau textul ultimei solicitări finalizate dacă sesiunea este în stare de repaus;
• - Ei bine, înțelegi;
• - o rubrică foarte interesantă. Este scos în format (Ax: Bms/Cms/Dms)E. A este numărul de sarcini care așteaptă pe resursa E. B/C/D este timpul de așteptare în milisecunde. Dacă există o singură sesiune care așteaptă ca o resursă să fie eliberată (ca în captură de ecran), timpul de așteptare al acesteia va fi afișat, dacă sunt 2 sesiuni, timpii lor de așteptare vor fi afișați în format B/C. Dacă 3 sau mai multe așteaptă, vom vedea timpul minim, mediu și maxim de așteptare pe ACEASTA resursă în format B/C/D;
• - pentru o cerere activă - timpul total de CPU petrecut de această solicitare, pentru o sesiune de inactivitate - timpul total de CPU pe „întreaga viață” a acestei sesiuni;
• - pentru o interogare activă, acesta este numărul de operații de scriere în TempDB în timpul execuției interogării; pentru o sesiune de dormit - numărul total de înregistrări în TempDB pentru întreaga durată de viață a sesiunii;
• - pentru o cerere activă - numărul de pagini din TempDB alocat pentru această solicitare; pentru o sesiune de dormit - numărul total de pagini din TempDB alocate pe toată durata de viață a sesiunii;
• - dacă brusc suntem blocați de cineva, va afișa spid (session_id) persoanei care ne-a blocat;
• - pentru o cerere activă - numărul de citiri logice efectuate la executarea acestei solicitări; pentru o sesiune de dormit - numărul de pagini citite pe toată durata de viață a acestei sesiuni;
• - totul este la fel, dar despre înregistrare;
• - pentru o cerere activă - numărul de citiri fizice efectuate la executarea acestei solicitări; pentru o sesiune de somn - în mod tradițional, numărul total de lecturi fizice pe întreaga durată a sesiunii;
• - pentru o cerere activă - numărul de pagini de opt kilobyte utilizate la executarea acestei solicitări; pentru o sesiune de dormit - câte pagini de memorie i-au fost alocate pe toată durata de viață;
• - starea sesiunii - alergare, dormit etc.;
• - arata numarul de tranzactii deschise de aceasta sesiune;
• - arată, dacă este posibil, progresul operațiunii (de exemplu, BACKUP, RESTORE), nu va arăta niciodată câte procente din SELECT este finalizată.

Coloanele rămase în ieșire standard sp_WhoIsActive sunt de puțin interes și nu le voi descrie - scopul lor, cred, este clar pentru toată lumea (host_name, database_name, program_name, start_time, login_time, request_id, collection_time).

Si ce? Asta este tot?

Nu, asta nu e tot. Voi vorbi și despre ce parametri (cei mai interesanți și mai folositori, din punctul meu de vedere) puteți apela sp_WhoIsActive și ce va rezulta din asta.

• @help este o opțiune teribil de utilă. Când apelăm sp_whoIsActive @help = 1 , obținem informații despre TOȚI parametrii și coloanele de ieșire pe ecran. Deci, dacă ceva rămâne neclar, poți oricând să te uiți la „ajutor”
• @filter_type și @filter - vă permit să filtrați rezultatul execuției. @filter_type poate lua valorile „session”, „program”, „database”, „login” și „host”. În parametrul @filter indicăm ce obiect de tipul selectat ne interesează. De exemplu, dorim să vedem toate sesiunile rulând în baza de date master, pentru a face acest lucru numim exec sp_whoIsActive @filter_type = "database", @filter = "master" . Parametrul @filter permite utilizarea lui „%”;
• @not_filter_type și @not_filter - ne permit să filtram „în sens invers”. Adică, de exemplu, vrem să vedem totul, cu excepția acelor sesiuni care au „master” în câmpul „database”, pentru aceasta executăm exec sp_WhoIsActive @not_filter_type = „database”, @not_filter = „master” . Ei bine, sau vrem să vedem ce fac toți utilizatorii, cu excepția utilizatorului sa... Pot exista multe aplicații. Parametrul @not_filter permite utilizarea lui „%”;
• @show_system_spids = 1 - va afișa informații despre sesiunile de sistem;
• @get_full_inner_text = 1 - câmpul sql_text va conține nu doar textul cererii (instrucțiuni) curente în lot (lot), ci și textul întregului lot;
• @get_plans - va adăuga o coloană cu planuri de execuție a interogării la ieșire;
• @get_transaction_info = 1 - va adăuga la ieșire numărul și volumul de intrări din jurnalele de tranzacții, precum și ora de începere a ultimei tranzacții;
• @get_locks = 1 - va adăuga la ieșire informații despre toate blocările aplicate în timpul executării cererii;
• @find_block_leaders = 1 - va urmări lanțul de blocare și va afișa numărul total de sesiuni care așteaptă ca sesiunea curentă să elimine blocajul;
• @output_column_list = "[%]" - ce se întâmplă dacă nu doriți să vedeți informații tempDB în ieșirea sp_whoIsActive? Această opțiune vă permite să controlați ceea ce iese;
• @destination_table = "table_name" - va încerca să insereze rezultatul execuției într-un tabel, dar nu va verifica dacă acest tabel există și dacă există suficiente drepturi de inserat în el.

Asta e tot acum

Drept urmare, avem un alt instrument extrem de convenabil și flexibil pentru monitorizarea activității curente pe SQL Server. Pentru funcționarea sa normală sunt suficiente permisiunea VIEW SERVER STATE și drepturile de acces la dmv.
De asemenea, merită adăugat în cazul în care serverul poate fi conectat numai prin intermediul

Lista de verificare a auditului de performanță

Introduceți rezultatele în tabelul de mai sus.

Utilizarea Performance Monitor pentru a identifica blocajele hardware SQL Server

Cel mai bun loc pentru a începe auditarea performanței SQL Server este cu Monitorul de performanță (Monitor de sistem). Monitorizarea câtorva contoare cheie pe o perioadă de 24 de ore vă va oferi o idee destul de bună despre orice probleme majore de hardware care afectează performanța SQL Server.

În mod ideal, ar trebui să utilizați monitorul de performanță pentru a crea un fișier jurnal cu citirile cheie ale contorului pentru o perioadă de 24 de ore. Veți selecta o perioadă „tipică” de 24 de ore pentru crearea fișierului jurnal. De exemplu, alegeți o zi obișnuită a săptămânii, nu sfârșitul săptămânii sau o vacanță.

După ce ați înregistrat 24 de ore de date din Monitorul de performanță într-un fișier jurnal, afișați contoarele recomandate în modul Grafic Monitor de performanță, apoi înregistrați valorile medii, minime și maxime în tabelul de mai sus. Odată ce ați făcut acest lucru, comparați rezultatele cu rezultatele analizei de mai jos. Această comparație vă va oferi posibilitatea de a identifica eventualele blocaje hardware care vă afectează SQL Server.

Cum se interpretează contoarele cheie ale monitorului de performanță

Mai jos discutăm câteva contoare de bază de monitorizare a performanței, valorile lor recomandate și câteva opțiuni care ar trebui să ajute la identificarea și rezolvarea problemelor hardware. Trebuie remarcat faptul că am limitat numărul de contoare de monitor de performanță luate în considerare. Acest lucru se face deoarece scopul acestui articol este de a detecta probleme simple și evidente de pierdere a productivității. O discuție despre multe alte contoare de monitorizare a performanței poate fi găsită în altă parte pe acest site web.

Memorie: pagini/secunde

Acest contor măsoară numărul de pagini pe secundă care sunt eliminate de pe RAM pe disc sau care sunt citite în RAM de pe disc. Cu cât are loc mai multe schimburi de pagini, cu atât mai mult I/O încarcă experiențele de server, ceea ce, la rândul său, poate afecta negativ performanța SQL Server. Scopul dvs. este să încercați să mențineți schimbarea paginilor la minimum fără a o elimina.

Presupunând că SQL Server este singura aplicație principală care rulează pe serverul dvs., acest număr ar trebui să fie în mod ideal între zero și 20. Este foarte probabil să vedeți valori aberante cu mult peste 20, ceea ce este destul de normal. Cheia aici este să mențineți cursul mediu de schimb al paginii sub 20.

Dacă serverul dvs. are o medie de peste 20 de pagini pe secundă, unul dintre cele mai probabile motive pentru aceasta este lipsa memoriei RAM necesare. În general, cu cât este mai multă RAM disponibilă, cu atât ar trebui efectuate mai puține schimburi de pagini.

În cele mai multe cazuri, pe un server fizic dedicat SQL Server cu RAM adecvată, schimbul mediu de pagini va fi mai mic de 20. RAM adecvată pentru SQL Server poate fi determinată de următorul criteriu: serverul trebuie să aibă un raport de accesare a cache-ului tampon (Buffer Hit Cache Ratio) 99% sau mai mare. Acest contor este descris mai târziu în acest articol. Dacă aveți un server SQL care are acest raport la 99% sau mai mare pe o perioadă de 24 de ore, dar obțineți o rată medie de schimb a paginii de peste 20 în aceeași perioadă de timp, acest lucru poate indica că rulați alte aplicații pe un server fizic altul decât SQL Server. Dacă acesta este cazul, în mod ideal ar trebui să eliminați aceste aplicații, permițând SQL Server să fie singura aplicație principală de pe serverul fizic.

Dacă serverul dvs. SQL nu rulează alte aplicații și schimburile de pagini depășesc 20 în medie pe o perioadă de 24 de ore, poate însemna că ați modificat setările de memorie SQL Server. SQL Server trebuie configurat astfel încât opțiunea „Configurare dinamică a memoriei SQL Server” să fie setată și setarea „Memorie maximă” să fie setată la cea mai mare setare. Pentru a funcționa optim, SQL Server ar trebui să aibă voie să ia atâta RAM cât are nevoie pentru propriile nevoi, fără a fi nevoit să concureze pentru RAM cu alte aplicații.

Memorie: spațiu disponibil

O altă modalitate de a afla dacă serverul dvs. SQL are suficientă memorie RAM fizică este să verificați contorul obiectului de memorie: octeți disponibili. Valoarea acestuia trebuie să fie mai mare de 5 MB. În caz contrar, serverul dvs. SQL are nevoie de mai multă memorie RAM fizică. Pe un server specializat pentru SQL Server, acesta din urmă încearcă să păstreze 4-10MB de memorie fizică liberă. RAM-ul fizic rămas este utilizat de sistemul de operare și de SQL Server. Când cantitatea de memorie disponibilă este aproape de 5 MB sau mai mică, este cel mai probabil ca SQL Server să se confrunte cu supraîncărcare din cauza memoriei reduse. Dacă acesta este cazul, trebuie să creșteți cantitatea de memorie RAM fizică a serverului, să reduceți sarcina pe server sau să modificați setările de configurare a memoriei SQL Server în consecință.

Disc fizic: % de funcționare a discului

Acest contor arată cât de ocupat este matricea de discuri fizice (nu o partiție logică sau un disc individual din matrice). Oferă o măsură relativă bună a cât de ocupate sunt matricele dvs. de discuri.

Ca regulă generală, contorul de timp pe disc ar trebui să indice mai puțin de 55%. Dacă citirile contorului depășesc 55% pentru perioade continue (mai mult de 10 minute în timpul celor 24 de ore de monitorizare), atunci serverul SQL poate întâmpina probleme I/O. Dacă vedeți acest comportament doar ocazional în timpul celor 24 de ore de monitorizare, nu mi-aș face prea multe griji, dar dacă s-ar întâmpla frecvent (să zicem, de câteva ori pe oră), atunci aș începe să caut modalități de a crește performanța I/O pe server sau reduceți încărcarea serverului. Unele modalități de a crește I/O disc sunt adăugarea de noi discuri la matrice (dacă este posibil), înlocuirea discurilor cu altele mai rapide, adăugarea cache pe placa controlerului (dacă este posibil), utilizarea diferitelor versiuni de RAID sau instalarea unui controler mai rapid. .

Înainte de a utiliza acest contor sub NT 4.0, trebuie să îl activați manual, introducând următoarele în linia de comandă: „diskperf-y”. După aceasta, va trebui să reporniți serverul. Astfel, trebuie să activați imediat contoarele de disc în Windows NT 4.0. Dacă utilizați Windows 2000, acest contor este activat în mod implicit.

Disc fizic: lungime medie a cozii de disc

Pe lângă monitorizarea valorii contorului „Physical Disk: Disk Uptime”, este de asemenea recomandabil să monitorizați valoarea contorului de lungime medie a cozii de disc (Avg. Disk Queue Length). Dacă această valoare depășește 2 pentru perioade continue (mai mult de 10 minute în timpul perioadei de monitorizare de 24 de ore) pentru fiecare unitate din matrice, atunci matricea poate fi un blocaj de performanță a sistemului. Similar cu cronometrul de disc, dacă acest lucru se întâmplă ocazional în timpul perioadei de monitorizare de 24 de ore, nu mi-ar face griji prea mult, dar dacă se întâmplă frecvent, atunci aș începe să caut modalități de a crește performanța I/O a serverului, așa cum este descris. de mai sus.

Va trebui să calculați această cifră deoarece Performance Monitor nu știe câte discuri fizice sunt în matricea dvs. De exemplu, dacă aveți o matrice de 6 discuri fizice și lungimea medie a cozii este de 10 pentru acea matrice, atunci coada medie reală de disc pe disc este 1,66 (10/6=1,66), care se încadrează cu mult în limita recomandată de 2- cu-1 disc fizic.

Înainte de a utiliza acest contor sub NT 4.0, asigurați-vă că îl activați manual tastând „diskperf-y” la linia de comandă NT și apoi reporniți serverul. Prin urmare, este necesar să activați contoarele de disc imediat după instalarea Windows NT 4.0. Dacă utilizați Windows 2000, acest contor va fi activat în mod implicit.

Utilizați ambele contoare descrise mai sus pentru a afla exact dacă serverul dvs. întâmpină probleme I/O. De exemplu, dacă vedeți multe perioade de timp în care timpul de funcționare al discului este mai mare de 55% și când lungimea medie a cozii de disc este mai mare de 2 pe disc fizic, puteți fi sigur că serverul are o problemă I/O.

Procesor: timp CPU %

Obiectul procesor: Contorul % Timp procesor este disponibil pentru fiecare CPU și estimează utilizarea fiecărui procesor individual. Un contor similar este disponibil și pentru întregul set de procesoare centrale (număr total). Acesta este un contor cheie pentru monitorizarea utilizării CPU. Dacă timpul total de încărcare a procesorului pentru acest contor depășește 80% pentru perioade continue (mai mult de 10 minute în timpul unei perioade de monitorizare de 24 de ore), atunci puteți considera CPU-ul ca fiind blocajul sistemului. Dacă aceste perioade de sarcină grea apar ocazional și crezi că poți trăi cu ea, atunci totul este bine. Dar dacă apar frecvent, ar trebui să luați în considerare opțiuni pentru a reduce încărcarea serverului, cum ar fi achiziționarea de procesoare mai rapide, instalarea mai multor procesoare sau achiziționarea de procesoare care au un cache L2 mai mare încorporat.

Sistem: Lungimea cozii CPU

Împreună cu contorul de timp al procesorului, ar trebui să monitorizați și contorul Procesor Queue Length. Dacă această rată depășește 2 per CPU pentru perioade continue (mai mult de 10 minute în timpul perioadei de monitorizare de 24 de ore), atunci este probabil un blocaj al sistemului. De exemplu, dacă serverul dvs. are 4 procesoare, lungimea cozii CPU nu trebuie să depășească un total de 8.

Dacă lungimea cozii CPU depășește în mod regulat valoarea maximă recomandată, dar utilizarea CPU nu este atât de mare (ceea ce este cazul obișnuit), atunci luați în considerare reducerea valorii parametrului de configurare „max. fire de lucru” SQL Server. Un posibil motiv pentru lungimea mare a cozii CPU este prezența unui număr excesiv de fire de lucru care își așteaptă rândul. Reducerea numărului acestora, ceea ce faceți cu acest parametru, vă obligă să utilizați poolingul de fire (dacă nu este deja cazul) sau să îi creșteți rolul.

Utilizați ambele contoare descrise împreună pentru a determina cu precizie dacă există o problemă cu procesorul. Dacă ambii indicatori depășesc valorile recomandate pentru aceleași perioade continue de timp, puteți fi sigur că CPU este punctul slab al sistemului.

Buffer SQL Server: Rata de accesare a memoriei cache

Acest contor (SQL Server Buffer: Buffer Cache Hit Ratio) arată cât de des SQL Server accesează tamponul, mai degrabă decât hard disk-ul pentru a prelua date. În aplicațiile OLTP, acest raport ar trebui să depășească 90% și, în mod ideal, să fie mai mare de 99%. Dacă rata de accesare a memoriei cache a memoriei tampon este sub 90%, ar trebui să ieșiți și să cumpărați mai multă memorie RAM astăzi. Dacă acest raport este între 90% și 99%, atunci ar trebui să vă gândiți serios să cumpărați mai multă RAM, deoarece cu cât vă apropiați de 99%, cu atât mai repede va rula SQL Server. În unele cazuri, dacă baza de date este foarte mare, nu veți putea ajunge aproape de 99% chiar dacă puneți cantitatea maximă de RAM pe server. Atunci tot ce poți face este să adaugi cât mai multă memorie și să accepți status quo-ul.

În aplicațiile OLAP, raportul poate fi mult mai mic datorită naturii aplicației OLAP. Oricum, creșterea memoriei RAM ar trebui să accelereze SQL Server.

SQL Server: Conexiuni utilizator

Deoarece numărul de utilizatori ai SQL Server îi afectează performanța, se recomandă monitorizarea contorului de conexiuni utilizator (Obiect de statistică generală SQL Server: contor de conexiuni utilizator). Acesta arată numărul de conexiuni de utilizatori, nu numărul de utilizatori care sunt conectați la SQL Server la un moment dat.

Dacă acest contor este mai mare de 255, ar trebui să creșteți parametrul de configurare „Maximum Worker Threads”, care este implicit la 255. Dacă numărul de conexiuni depășește numărul de fire de lucru disponibile, atunci SQL Server va începe să partajeze fire de lucru, ceea ce poate afecta negativ performanța de impact. Setarea acestui parametru ar trebui să fie mai mare decât numărul maxim de conexiuni care pot fi atinse pe serverul dumneavoastră.

Ce urmeaza

Deși există mult mai multe contoare decât cele pe care le-am acoperit, acestea din urmă sunt cheie pentru monitorizarea care are loc în timpul procesului de audit al performanței. După ce ați finalizat analiza Monitorului de performanță, utilizați recomandările furnizate în această serie de articole pentru a face modificările necesare care vor face ca SQL Server să funcționeze așa cum ar trebui.

Orice administrator de baze de date a trebuit probabil să se ocupe de faptul că totul funcționează lent sau nu funcționează deloc. Primul lucru pe care trebuie să-l aflați este ce se întâmplă de fapt pe SQL Server în acest moment. S-ar părea că administratorul are atât de multe lucruri utile în arsenalul său: un monitor de activitate prost, o grămadă de vizualizări de management dinamic (dmv), proceduri stocate sp_who și sp_who2, moștenite din zilele SQL Server 7 și SQL Server 2000.
Dar hai să ne dăm seama...

Instrumente de monitorizare

Monitor de activitate

S-ar părea un lucru grozav, face exact ceea ce trebuie să facă - monitorizează activitatea. Lansez un raport contabil greu și văd ce îmi arată Monitorul de activitate.
Capturile de ecran arată un monitor de activitate din SQL Server 2005:

Și din SQL Server Denali (2012) CTP 3.


Hmmm. Ce se întâmplă dacă o duzină de oameni lansează astfel de rapoarte? Și acest lucru nu este neobișnuit... Va fi destul de incomod să-ți dai seama, deși, desigur, progresul este evident. În Denali Activity Monitor afișează informații mult mai utile (de exemplu, despre ce resursă specifică are loc așteptarea), plus, putem, de exemplu, să lansăm un profiler pentru sesiunea dorită direct de pe monitor și să îl urmărim deja în profiler , dar, la naiba, se încarcă în plus și un server deja supraîncărcat. În plus, există deja o problemă cu frânele și nu vom vedea acele solicitări care începuseră deja să fie executate la momentul lansării profilelor.
Și asta este exact ceea ce vreau să văd - cine ce face acum.

sp_who și sp_who2

Captura de ecran arată rezultatul executării sp_who (sus) și sp_who2 (jos), executate în timp ce construim același raport nefast:


Da. Foarte informativ. Privind la sp_who, putem vedea doar că ceva rulează. Desigur, este executat - de aceea ne uităm, dar vedem că se execută un fel de SELECT. Sau mai multe SELECT-uri. Grozav.
sp_who2 afișează mai multe informații. Acum putem vedea cât timp a petrecut procesorul de către sesiune (și adunăm timpul total într-o coloană, aparent), numărul de operații de i/o, numele bazei de date în care sunt efectuate toate acestea și de către cine. sesiunea este blocată (dacă este blocată).
Monitorul de activitate, după cum vedem, oferă mai multe informații.

DMV

Începând cu SQL Server 2005, avem o nouă capacitate de a obține informații despre starea serverului - Dynamic Management Views. MSDN spune acest lucru: „Vizualizările și funcțiile de gestionare dinamică returnează date despre starea serverului care pot fi utilizate pentru a monitoriza starea de sănătate a unei instanțe de server, pentru a diagnostica probleme și pentru a regla performanța.”
Într-adevăr, în SQL Server 2005 există un set de vederi legate de executarea interogărilor în momentul actual (există totuși și vizualizări pentru vizualizarea „istoric”): iată-le. Și numărul lor continuă să crească de la versiune la versiune!
Cu siguranță, administratorii experimentați au o grămadă de scripturi pregătite pentru a obține informații despre starea actuală a serverului, dar ce să faceți dacă nu aveți încă experiență de lucru cu DMV, dar există deja probleme?

sp_WhoIsActive

Adam Machanic (SQL Server MVP și MCITP) a dezvoltat și îmbunătățește constant procedura stocată sp_WhoIsActive, care se bazează pe aceleași DMV-uri și este al naibii de ușor de utilizat. Puteți descărca cea mai recentă versiune de sp_WhoIsActive. Adam insusi are o serie de articole dedicate lui sp_WhoIsActive, formate din pana la 30 (treizeci!) de bucati, o puteti citi, dar voi incerca sa va interesez sa cititi acest material :).
Deci, vom presupune că ați descărcat și rulat acest script pe unul dintre serverele de testare (pe orice versiune, din 2005 până la Denali). Adam sfătuiește să-l stocați în baza de date a sistemului master, astfel încât să poată fi apelat în contextul oricărei baze de date, dar acest lucru nu este necesar, doar când îl apelați în contextul unei alte baze de date, va trebui să scrieți numele în întregime - DB .schema.sp_whoIsActive.
Deci hai să încercăm. Captura de ecran arată rezultatul execuției sale în timpul construirii aceluiași raport:

Rezultatul interogării exec sp_whoIsActive, din păcate, nu se încadrează într-un singur ecran, așa că aici este o descriere text a rezultatului unei proceduri stocate numită fără parametri.

• - pentru o cerere activă arată timpul de execuție, pentru o sesiune „sleeping” - timpul „sleep”;
• - de fapt, spid;
• - afișează textul cererii în curs de execuție sau textul ultimei solicitări finalizate dacă sesiunea este în stare de repaus;
• - Ei bine, înțelegi;
• - o rubrică foarte interesantă. Este scos în format (Ax: Bms/Cms/Dms)E. A este numărul de sarcini care așteaptă pe resursa E. B/C/D este timpul de așteptare în milisecunde. Dacă există o singură sesiune care așteaptă ca o resursă să fie eliberată (ca în captură de ecran), timpul de așteptare al acesteia va fi afișat, dacă sunt 2 sesiuni, timpii lor de așteptare vor fi afișați în format B/C. Dacă 3 sau mai multe așteaptă, vom vedea timpul minim, mediu și maxim de așteptare pe ACEASTA resursă în format B/C/D;
• - pentru o cerere activă - timpul total de CPU petrecut de această solicitare, pentru o sesiune de inactivitate - timpul total de CPU pe „întreaga viață” a acestei sesiuni;
• - pentru o interogare activă, acesta este numărul de operații de scriere în TempDB în timpul execuției interogării; pentru o sesiune de dormit - numărul total de înregistrări în TempDB pentru întreaga durată de viață a sesiunii;
• - pentru o cerere activă - numărul de pagini din TempDB alocat pentru această solicitare; pentru o sesiune de dormit - numărul total de pagini din TempDB alocate pe toată durata de viață a sesiunii;
• - dacă brusc suntem blocați de cineva, va afișa spid (session_id) persoanei care ne-a blocat;
• - pentru o cerere activă - numărul de citiri logice efectuate la executarea acestei solicitări; pentru o sesiune de dormit - numărul de pagini citite pe toată durata de viață a acestei sesiuni;
• - totul este la fel, dar despre înregistrare;
• - pentru o cerere activă - numărul de citiri fizice efectuate la executarea acestei solicitări; pentru o sesiune de somn - în mod tradițional, numărul total de lecturi fizice pe întreaga durată a sesiunii;
• - pentru o cerere activă - numărul de pagini de opt kilobyte utilizate la executarea acestei solicitări; pentru o sesiune de dormit - câte pagini de memorie i-au fost alocate pe toată durata de viață;
• - starea sesiunii - alergare, dormit etc.;
• - arata numarul de tranzactii deschise de aceasta sesiune;
• - arată, dacă este posibil, progresul operațiunii (de exemplu, BACKUP, RESTORE), nu va arăta niciodată câte procente din SELECT este finalizată.

Coloanele rămase în ieșire standard sp_WhoIsActive sunt de puțin interes și nu le voi descrie - scopul lor, cred, este clar pentru toată lumea (host_name, database_name, program_name, start_time, login_time, request_id, collection_time).

Si ce? Asta este tot?

Nu, asta nu e tot. Voi vorbi și despre ce parametri (cei mai interesanți și mai folositori, din punctul meu de vedere) puteți apela sp_WhoIsActive și ce va rezulta din asta.

• @help este o opțiune teribil de utilă. Când apelăm sp_whoIsActive @help = 1 , obținem informații despre TOȚI parametrii și coloanele de ieșire pe ecran. Deci, dacă ceva rămâne neclar, poți oricând să te uiți la „ajutor”
• @filter_type și @filter - vă permit să filtrați rezultatul execuției. @filter_type poate lua valorile „session”, „program”, „database”, „login” și „host”. În parametru indicăm ce obiect de tipul selectat ne interesează. De exemplu, vrem să vedem toate sesiunile rulând în baza de date master, pentru a face acest lucru numim exec sp_whoIsActive @filter_type = "database", = "master" . Puteți utiliza „%” în parametru;
• @not_filter_type și @not_filter - ne permit să filtram „în sens invers”. Adică, de exemplu, vrem să vedem totul, cu excepția acelor sesiuni care au „master” în câmpul „database”, pentru aceasta executăm exec sp_WhoIsActive @not_filter_type = „database”, @not_filter = „master” . Ei bine, sau vrem să vedem ce fac toți utilizatorii, cu excepția utilizatorului sa... Pot exista multe aplicații. Parametrul @not_filter permite utilizarea lui „%”;
• @show_system_spids = 1 - va afișa informații despre sesiunile de sistem;
• @get_full_inner_text = 1 - câmpul sql_text va conține nu doar textul cererii (instrucțiuni) curente în lot (lot), ci și textul întregului lot;
• @get_plans - va adăuga o coloană cu planuri de execuție a interogării la ieșire;
• @get_transaction_info = 1 - va adăuga la ieșire numărul și volumul de intrări din jurnalele de tranzacții, precum și ora de începere a ultimei tranzacții;
• @get_locks = 1 - va adăuga la ieșire informații despre toate blocările aplicate în timpul executării cererii;
• @find_block_leaders = 1 - va urmări lanțul de blocare și va afișa numărul total de sesiuni care așteaptă ca sesiunea curentă să elimine blocajul;
• @output_column_list = "[%]" - ce se întâmplă dacă nu doriți să vedeți informații tempDB în ieșirea sp_whoIsActive? Această opțiune vă permite să controlați ceea ce iese;
• @destination_table = "table_name" - va încerca să insereze rezultatul execuției într-un tabel, dar nu va verifica dacă acest tabel există și dacă există suficiente drepturi de inserat în el.

Asta e tot acum

Drept urmare, avem un alt instrument extrem de convenabil și flexibil pentru monitorizarea activității curente pe SQL Server. Pentru funcționarea sa normală sunt suficiente permisiunea VIEW SERVER STATE și drepturile de acces la dmv.
De asemenea, merită adăugat în cazul în care serverul poate fi conectat numai prin intermediul