Momentan sunteți offline, așteptați să vă reconectați la internet

Resurse: Depanarea problemelor de performanţă a aplicaţiilor cu SQL Server

REZUMAT
Acest articol descrie etapă cu etapă cum se depanează problemele de performanţă ale SQL Server. Depanarea problemelor de performanţă implică utilizarea unei serii de paşi pentru a izola şi determina cauza funcţionării lente a unei aplicaţii. Printre cauzele posibile se numără:
  • Blocarea.
  • Probleme privind împărţirea resurselor de sistem.
  • Probleme de proiectare a aplicaţiei.
  • Un anumit set de interogări sau proceduri stocate cu timpi lungi de execuţie.
Acest articol descrie cum se determină sursa unei probleme de performanţă. De asemenea, face referire la alte articole din Baza de cunoştinţe Microsoft care tratează în detaliu anumite probleme specifice de performanţă, pentru depanare suplimentară.înapoi la început

SQL Profiler


SQL Profiler este un instrument puternic pentru depanarea problemelor de performanţă a aplicaţiilor SQL Server 7.0 sau versiuni mai recente. SQL Profiler vă permite să capturaţi cu uşurinţă toate evenimentele care se produc pe server în situaţii de încărcare tipică şi furnizează informaţii despre acestea. Dacă utilizaţi SQL Profiler împreună cu Microsoft Windows NT Performance Monitor şi cu unele interogări simple pentru a identifica dacă se produce blocarea, atunci veţi dispune de informaţiile necesare pentru a rezolva marea majoritate a problemelor de performanţă.

înapoi la început

Elemente de monitorizat

1. Configuraţi SQL Profiler pentru a captura o urmă. Pentru aceasta, parcurgeţi următorii paşi:
  1. Deschideţi SQL Profiler.
  2. În meniul Tools, faceţi clic pe Options.
  3. Asiguraţi-vă că sunt selectate opţiunile All Event Classes şi All Data Columns.
  4. Faceți clic pe OK.
  5. Creaţi o urmă nouă.
  6. În meniul File, indicaţi spre New, apoi faceţi clic pe Trace.
  7. Pe fila General, specificaţi un nume de urmă şi un fişier în care să se captureze datele.
  8. Pe fila Events, adăugaţi următoarele tipuri de eveniment la urmă:

    HeadingEvent to addDescription
    CursorsCursorPrepareAcest eveniment indică faptul că un cursor dintr-o instrucţiune SQL a fost pregătit utilizând ODBC, OLEDB sau DB-Library.
    Error and WarningMissing Column StatisticsAcest eveniment indică dacă statisticile de coloane, care pot să fie utile pentru Optimizer, nu au fost disponibile. Coloana Text afişează lista de coloane cu statistici lipsă. Acest eveniment, împreună cu un eveniment Misc: Auto-UpdateStats, indică faptul că s-a declanşat opţiunea Auto Create Statistics.
    Misc.AttentionAcest eveniment indică faptul că s-a trimis un semnal de atenţie de către un client.
    Misc.Auto-UpdateStatsAcest eveniment indică faptul că s-a declanşat opţiunea Auto Update Statistics.
    Misc.Exec Prepared SQLAcest eveniment indică faptul că ODBC, OLE DB, sau DB-Library au executat o instrucţiune sau mai multe instrucţiuni Transact-SQL pregătite anterior.
    Misc.Execution PlanAcest eveniment afişează arborele de plan al instrucţiunii Transact-SQL care s-a executat.
    Misc.Prepare SQLAcest eveniment indică faptul că o aplicaţie ODBC, OLE DB sau DB-Library a pregătit o instrucţiune sau mai multe instrucţiuni Transact-SQL pentru utilizare.
    Misc.Unprepare SQLAcest eveniment indică faptul că o aplicaţie ODBC, OLE DB sau DB-Library a eliminat pregătirea unei instrucţiuni sau a mai multor instrucţiuni Transact-SQL pentru utilizare.
    SessionsConnectAcest eveniment indică faptul că s-a creat o conexiune nouă.
    SessionsDisconnectAcest eveniment indică faptul că un client s-a deconectat.
    SessionsExisting ConnectionAcest eveniment indică faptul că a existat o conexiune când s-a pornit o urmă SQL Profiler.
    Stored ProceduresSP: CompletedAcest eveniment arată când s-a terminat execuţia unei proceduri stocate.
    Stored ProceduresSP: RecompileAcest eveniment arată că o procedură stocată s-a recompilat în timpul execuţiei.
    Stored ProceduresSP: StartingAcest eveniment arată când a început execuţia unei proceduri stocate.
    Stored ProceduresSP: StmtCompletedAcest eveniment arată când s-a terminat execuţia unei instrucţiuni dintr-o procedură stocată.
    TSQL:SQL:BatchCompletedAcest eveniment arată că s-a terminat un batch Transact-SQL. Coloana Text arată instrucţiunea care a fost executată.
    TSQL:SQL:StmtCompletedAcest eveniment arată că s-a terminat o instrucţiune Transact-SQL. Coloana Text afişează instrucţiunea executată.
    TSQL:RPC:CompletedAcest eveniment arată că s-a terminat o apelare de procedură la distanţă (RPC).
  9. Dacă aplicaţia primeşte erori de expirare, nu mai răspunde (se blochează) sau manifestă alte evenimente care determină ca instrucţiunile problemă să nu se termine deloc, includeţi şi următoarele evenimente:

    TSQL:SQL:BatchStartingAcest eveniment arată că s-a pornit un batch Transact-SQL. Coloana Text afişează instrucţiunea în execuţie.
    TSQL:SQL:StmtStartingAcest eveniment arată că s-a pornit o instrucţiune Transact-SQL. Coloana Text afişează instrucţiunea în execuţie.
    TSQL:RPC:StartingAcest eveniment arată începutul unei apelări de procedură la distanţă (RPC).
    Stored ProceduresSP: StmtStartingAcest eveniment arată când începe execuţia unei instrucţiuni dintr-o procedură stocată.


    Astfel, vă va ajuta să vă asiguraţi că aveţi posibilitatea să vedeţi instrucţiunea care se executa când s-a produs eroarea
  10. În fila Data Columns, asiguraţi-vă că sunt incluse următoarele coloane:

    Pentru SQL Server 2000

    Start Time

    End Time

    LoginSid

    SPID

    Event Class

    TextData

    IntegerData

    BinaryData

    Duration

    CPU

    Reads

    Writes

    Application Name

    NT User Name

    DBUserName


    Pentru SQL Server 7.0

    Start Time

    End Time

    Connection ID

    SPID

    Event Class

    Text

    Integer Data

    Binary Data

    Duration

    CPU

    Reads

    Writes

    Application Name

    NT User Name

    SQL User Name

Pentru informaţii despre utilizarea SQL Profiler, consultaţi SQL Server 7.0 şi SQL Server 2000 Books Online.


2. Utilizarea Performance Monitor pentru a captura contoarele Windows NT şi SQL Server. Pentru aceasta, parcurgeţi următorii paşi:
  1. Porniţi Windows NT Performance Monitor.
  2. În meniul View, faceţi clic pe Log.
  3. În meniul Options, faceţi clic pe Log.
  4. Specificaţi un nume de fişier şi o locaţie pentru înregistrarea în jurnal a contoarelor de performanţă. Aveţi posibilitatea să actualizaţi intervalul după cum este necesar:
  5. În meniul Edit, faceţi clic pe Add To Log.
  6. Adăugaţi toate obiectele. Atât obiectele Windows NT, cât şi obiectele SQL Server.
  7. Pentru porni jurnalul, în meniul Options, faceţi clic pe Log, apoi pe butonul Start Log.

Pentru informaţii suplimentare, faceţi clic pe următorul număr de articol pentru a vedea articolul în Baza de cunoştinţe Microsoft:
150934 Cum se creează un jurnal de monitorizare a performanţelor pentru depanarea NT (articolul poate să fie în limba engleză)

3. Verificaţi dacă s-au produs blocări.

Pentru a vedea dacă se produc blocări, executaţi procedura de sistem stocată sp_who:
exec sp_who
Aceste rezultate vor conţine o coloană blk. Examinaţi rezultatele pentru orice intrări diferite de zero care indică faptul că se produce o blocare. Executaţi această procedură periodic în intervalul de timp când se produce încetinirea performanţelor.

Notă Executarea procedurii de sistem stocate sp_who este o verificare pentru a vedea dacă există elemente blocate. De obicei, aceste informaţii nu sunt suficiente pentru a depana complet o problemă de blocare. Pentru informaţii suplimentare, faceţi clic pe următorul număr de articol pentru a vedea articolul în Baza de cunoştinţe Microsoft:
251004 INF: Cum se monitorizează blocarea SQL Server 7.0 (articolul poate să fie în limba engleză)

înapoi la început

Executaţi aplicaţia în condiţii de încărcare tipică

Ideal ar fi să capturaţi SQL Profiler, Performance Monitor şi rezultatele blocării în aceeaşi perioadă de timp. Perioada de timp trebuie să cuprindă momentul când se schimbă performanţele aplicaţiei, de la normal la lent. Combinaţia acestor informaţii vă va ajuta să aveţi o imagine mai clară a locului în care se produce încetinirea performanţelor.

înapoi la început

Interpretarea rezultatelor

  1. Verificaţi dacă s-au produs blocări.

    În cazul în care coloana blk din rezultatul sp_who nu este zero, acest lucru indică faptul că se produce o blocare în sistem. Dacă procesele se blochează între ele, procesele care sunt blocate pot genera timpi mai mari de execuţie. Pentru informaţii suplimentare, faceţi clic pe următorul număr de articol pentru a vedea articolul în Baza de cunoştinţe Microsoft:
    224453 INF: Înţelegerea şi rezolvarea problemelor de blocare din SQL Server 7.0 sau 2000 (articolul poate să fie în limba engleză)
  2. Examinaţi rezultatul SQL Profiler.

    Vizualizarea eficientă a datelor SQL Profiler este foarte importantă pentru rezolvarea problemelor de performanţă. Cel mai important lucru de reţinut este că nu trebuie să verificaţi tot ce aţi capturat. Fiţi selectiv. SQL Profiler furnizează capacităţi pentru a vă ajuta să vizualizaţi eficient datele capturate. În filele Properties (faceţi clic pe Properties în meniul File), SQL Profiler vă permite să limitaţi datele afişate, prin eliminarea coloanelor de date sau de evenimente, prin gruparea (sortarea) după coloane de date şi prin aplicarea de filtre. Aveţi posibilitatea să căutaţi valori specifice în toată urma sau numai într-o anumită coloană (în meniul Edit, faceţi clic pe Find). De asemenea, aveţi posibilitatea să salvaţi datele SQL Profiler într-un tabel SQL Server (în meniul File, indicaţi spre Save As, faceţi clic pe Trace Table), apoi executaţi interogări SQL pe acesta.

    Reţineţi că filtrarea se poate efectua numai pentru un fişier de urmă salvat anterior. Dacă efectuaţi aceşti paşi pentru o urmă activă, riscaţi să pierdeţi datele care s-au capturat de la pornirea urmei. Salvaţi mai întâi urma activă într-un fişier sau într-un tabel (în meniul File, faceţi clic pe Save As) apoi redeschideţi-o (în meniul File, faceţi clic pe Open) înainte să continuaţi. Când lucraţi cu un fişier de urmă salvat, filtrarea nu elimină permanent datele care se filtrează; ele doar nu se afişează. Aveţi posibilitatea să adăugaţi şi să eliminaţi coloane de evenimente şi date pentru a restrânge căutările dvs.

    Primul pas în examinarea fişierelor de urmă SQL Profiler pentru cazuri de performanţă este să determinaţi unde pe server se produc diferitele tipuri de evenimente.

    Gruparea urmei în funcţie de clasa evenimentului:

    a. În meniul File, faceţi clic pe Properties.

    b. În fila Data Columns, utilizaţi butonul UP pentru a muta Event Class sub titlul Groups, apoi butonul DOWN pentru a elimina toate celelalte coloane de sub titlul Groups.

    c. Faceţi clic pe OK.

    Gruparea după coloana cu clasa evenimentelor afişează ce tipuri de evenimente se produc pe SQL Server şi cât de frecvent. Căutaţi în această coloană următoarele evenimente:

    SP:RECOMPILE

    Acest eveniment arată că o procedură stocată s-a recompilat în timpul execuţiei. Mai multe evenimente de recompilare arată că SQL Server consumă resursele la compilarea de interogări în loc de executarea de interogări.

    Pentru informaţii suplimentare privind recompilarea procedurilor stocate, faceţi clic pe următorul număr de articol pentru a vedea articolul în Baza de cunoştinţe Microsoft:
    243586 INF: Depanarea problemelor privind recompilarea procedurilor stocate (articolul poate să fie în limba engleză)


    Attention

    Un semnal de atenţie indică faptul că s-a revocat o interogare de către un client. Acest lucru se datorează de obicei uneia dintre următoarele două cauze:

    Utilizatorul a revocat explicit interogarea sau a închis aplicaţia.

    - sau -

    S-a depăşit un timp de expirare de interogare.

    Dacă vedeţi semnalele de atenţie, acest lucru poate indica faptul că anumite interogări se execută lent.

    Pentru informaţii suplimentare, faceţi clic pe următorul număr de articol pentru a vedea articolul în Baza de cunoştinţe Microsoft:
    243589 Resurse: Depanarea interogărilor care se execută lent în SQL Server versiunea 7.0 sau o versiune mai recentă (articolul poate să fie în limba engleză)
    Pentru a vă ajuta să identificaţi interogarea care a primit semnalul de atenţie, revizuiţi urma astfel încât să nu fie grupată după coloane de date şi filtraţi după ID-ul de proces de sistem care a primit semnalul (în fila Filters, setaţi SPID = x). Evenimentele SQL:StmtStarting, SQL:BatchStarting sau SP:StmtStarting care se află imediat înaintea semnalului de atenţie reprezintă interogarea care a expirat sau care a fost revocată. Aveţi posibilitatea să căutaţi în coloana Event Class pentru a găsi cu uşurinţă evenimentul Attention (în meniul Edit, faceţi clic pe Find).

    PREPARE SQL şi EXEC PREPARED SQL

    Evenimentul Prepare SQL indică faptul că o aplicaţie ODBC, OLE DB sau DB-Library a pregătit pentru utilizare o instrucţiune sau mai multe instrucţiuni Transact-SQL. Evenimentul Exec Prepared SQL indică faptul că aplicaţia a utilizat o instrucţiune pregătită existentă pentru a executa o comandă.

    Comparaţi numărul de aparţii al celor două evenimente. În mod ideal, o aplicaţie trebuie să pregătească o instrucţiune SQL o dată şi să o execute de mai multe ori. Acest lucru economiseşte costul de compilare în Optimizer a unui nou plan la fiecare execuţie a instrucţiunii. De aceea, numărul de evenimente Exec Prepared SQL ar trebui să fie mult mai mare decât numărul de evenimente Prepare SQL. Dacă numărul de evenimente Prepare SQL este aproximativ egal cu numărul de evenimente Exec Prepared SQL, acest lucru poate indica faptul că aplicaţia nu utilizează bine modelul pregătire/executare. Se recomandă să nu pregătiţi o instrucţiune care va fi executată doar o singură dată. Pentru mai multe informaţii despre pregătirea instrucţiunilor SQL, consultaţi subiectul „Preparing SQL Statements” în SQL Server 7.0 Books Online.

    Dacă numărul de evenimente Exec Prepared SQL nu este de aproximativ trei până la cinci ori mai mare decât numărul de evenimente Prepare SQL, acest lucru poate indica faptul că aplicaţia nu utilizează bine modelul pregătire/executare. Pentru informaţii suplimentare, faceţi clic pe următorul număr de articol pentru a vedea articolul în Baza de cunoştinţe Microsoft:
    243588 Resurse: Depanarea problemelor privind funcţionarea interogărilor ad-hoc (articolul poate să fie în limba engleză)

    În SQL Server 2000, se vor elimina operaţiunile dus-întors excesive pentru pregătire/executare, astfel încât rata de 3-5 să nu fie aşa de necesară. Însă, poate fi încă o regulă bună să încercaţi să reutilizaţi planul pregătit de mai multe ori.

    Missing Column Statistics

    Acest eveniment arată că nu au fost disponibile informaţiile statistice pe care Optimizer ar fi avut posibilitatea să le utilizeze pentru a genera un plan mai bun de interogare. Acest lucru arată că interogarea nu are indexuri utile pentru cel puţin unul dintre tabelele implicate. Pe lângă lipsa unui index util, SQL Server nu are nici măcar date statistice despre coloanele implicate, pentru a lua o decizie în cunoştinţă de cauză pentru un plan de interogare. Drept urmare, planul de interogare generat poate să nu fie cel optim. Dacă vedeţi aceste evenimente, căutaţi în interogare şi în planul de executare generat şi vedeţi următorul articol în Baza de cunoştinţe Microsoft pentru paşi de a îmbunătăţi performanţele acestei interogări:
    243589 Resurse: Depanarea interogărilor care se execută lent în SQL Server versiunea 7.0 sau o versiune mai recentă (articolul poate să fie în limba engleză)

    Când vizualizaţi evenimentele Missing Column Statistics, concentraţi-vă mai întâi pe cele care se produc în asociere cu interogări de execuţie lungă. Unele evenimente pot fi generate şi rezolvate automat de SQL Server cu porniri automate şi pot să nu necesite intervenţia utilizatorului. De aceea, cea mai bună strategie este să vă concentraţi mai întâi pe interogările cu durată lungă, după cum se arată mai târziu în acest articol, şi să notaţi dacă există evenimente Missing Column Statistics asociate.

    Dacă nu vedeţi instanţe ale acestor clase de evenimente, următorul pas este să determinaţi unde se consumă timp.

    Grupaţi rezultatul urmei în funcţie de durată:

    a. În meniul File, faceţi clic pe Properties.

    În fila Data Columns, utilizaţi butonul UP pentru a muta Duration sub titlul Groups, apoi butonul DOWN pentru a elimina toate celelalte coloane de sub titlul Groups.

    c. În fila Events, eliminaţi toate grupurile, cu excepţia TSQL şi Stored Procedures.

    d. Faceţi clic pe OK.

    Grupând după durată, aveţi posibilitatea să vedeţi cu uşurinţă care instrucţiuni, fişiere batch sau proceduri SQL se execută cel mai lent. Este foarte important să vă uitaţi nu numai la ora când apare problema, ci să şi vă faceţi o impresie despre cum arată performanţele bune, pentru a avea un grad de comparaţie. Aveţi posibilitatea să filtraţi după timpul de începere pentru a împărţi urma în secţiuni când performanţa era bună şi o secţiune separată pentru performanţa lentă. Căutaţi interogările cu cea mai lungă durată atunci când performanţele sunt bune. Acestea sunt, cel mai probabil, sursa problemei. Dacă performanţa generală a sistemului este lentă, chiar şi interogările bune pot să afişeze durate lungi în timp ce aşteaptă resurse de sistem.

    Dacă vedeţi un număr mic de interogări cu durate mari, consultaţi următorul articol din Baza de cunoştinţe Microsoft:
    243589 Resurse: Depanarea interogărilor care se execută lent în SQL Server versiunea 7.0 sau o versiune mai recentă (articolul poate să fie în limba engleză)
    Dacă vedeţi că durata interogărilor individuale este mică, dar că există câteva interogări şi contorul SQL Compilations/sec din rezultatele Performance Monitor (descris mai jos) este mare, consultaţi următorul articol din Baza de cunoştinţe Microsoft:
    243588 Resurse: Depanarea problemelor privind funcţionarea interogărilor ad-hoc (articolul poate să fie în limba engleză)
    Examinaţi restul de coloane de date:

    Aveţi posibilitatea să obţineţi informaţii suplimentare privind natura unei probleme de performanţă dacă vizualizaţi şi celelalte coloane de date din rezultatele urmei. Iată câteva lucruri de luat în considerare:

    Dacă gradul de utilizare CPU este ridicat, grupaţi după CPU pentru a vedea care interogări utilizează cel mai mult timp CPU. Căutaţi în coloana Text pentru „hash” sau „merge”, pentru a găsi ce plan de execuţie de interogări utilizează aceste tipuri de asociere. Acestea consumă mai multe resurse de memorie şi CPU decât o asociere de buclă imbricată, care consumă de obicei resurse IO.

    Dacă intrările şi ieşirile de disc constituie zona de blocaj, grupaţi după citiri şi scrieri. Vizualizaţi câmpurile Application Name, NT User Name şi SQL User Name pentru a izola sursa unei interogări cu timp mare de execuţie.

    Coloana de date întregi a evenimentului excepţie va indica orice erori care au fost returnate clientului. Aveţi posibilitatea să găsiţi textul mesajului de eroare căutând după număr în SQL Server 7.0 Books Online.

    Câmpul Connection ID este util pentru a vă asigura că priviţi aceleaşi sesiuni pentru un anumit client. Un SPID nu poate garanta aceasta, deoarece este posibil ca un utilizator să se fi deconectat şi să se fi conectat alt utilizator, care a primit acelaşi SPID.

    Avantajele acestor câmpuri pot varia în funcţie de scenariu, dar ele trebuie să fie examinate în cazul în care câmpurile evidente de mai sus din acest articol nu oferă un răspuns.
  3. Examinaţi rezultatele din Performance Monitor.

    Performance Monitor vă va afişa zonele de blocaj din sistem. Este posibil ca SQL Server şi aplicaţia să funcţioneze după cum este aşteptat, dar computerul nu are suficientă putere, memorie şi alte resurse. Sau, unele contoare pot indica probleme în legătură cu modul în care funcţionează aplicaţia şi SQL Server. Verificaţi cel puţin următoarele contoare:

  • Object: Process

    Counter: Processor

    Instance: SQL Server

  • Object: Processor

    Counter: %Processor Time

    Instance: Check each processor instance

  • Object: Physical Disk

    Counter: Avg. Disk Queue Length

    Instance: Check each physical disk instance

  • Object: SQL Server:SQL Statistics

    Counter: SQL Compilations/sec
Căutaţi tendinţe în intervalul de timp în care performanţele au devenit lente: ce a crescut mai întâi? Computerul este limitat în privinţa puterii de procesare sau a scrierilor/citirilor pe disc? Aceste informaţii, împreună cu rezultatele din Profiler afişate mai sus în acest articol, vă vor ajuta să restrângeţi zonele cu probleme. Problemele de grad de folosire ridicată a procesorului pot indica un număr mare de recompilări de proceduri stocate, compilări de interogări ad-hoc sau utilizarea intensivă a asocierilor „hash” şi „merge”. Articolele la care se face referire mai sus trebuie să fie consultate pentru a determina metoda corectă de acţionare. Lungimile mari ale cozii de disc pot indica nevoia de mai multă memorie de sistem sau nevoia unui subsistem de disc îmbunătăţit.

înapoi la început
BOL slow down worse perf mon perfmon tshoot trouble shoot troubleshooting tshooting machine
Proprietăți

ID articol: 224587 - Ultima examinare: 12/29/2007 11:20:00 - Revizie: 4.1

  • Microsoft SQL Server 7.0 Standard Edition
  • kbhowto kbhowtomaster kbinfo kbproductlink KB224587
Feedback