sql >> Database teknologi >  >> RDS >> Sqlserver

Forespørgselsprofilering 101 — Ja, det kan virkelig forbedre din SQL Server-ydeevne

Forespørgselsprofilering er, hvordan du finder ud af, hvad der foregår inde i den sorte boks med SQL Server-ydeevne.

Brugerne har det nemt. DBA'er gør det ikke.

Tænk på de nemme muligheder, brugere har, når en databaseapplikation kører dårligt:

  • Hent kaffe og vent.
  • Fornærme computeren.
  • Klag til andre brugere.
  • Send en fejlmelding.

Er det ikke Rileys liv sammenlignet med de muligheder, du har som DBA?

  • Se efter blokerede sessioner.
  • Tjek hitforhold for buffercache.
  • Mål maksimal I/O-vent.
  • Undersøg sidens forventede levetid.
  • Se, om indekser mangler eller skal genopbygges.
  • Se efter låse/deadlocks.
  • Tjek CPU-brug.
  • Gennemgå applikationsloggen for meddelelser, der mangler hukommelse.
  • Sørg for, at tempdb-databasen er konfigureret korrekt.

Det kan være et hvilket som helst af disse softwareproblemer, og de fører dig normalt til løsningen med at optimere en forespørgsel eller ændre din konfiguration. Eller det kan være et hardwareproblem, og løsningen er at købe mere hukommelse eller processorkraft.

Fordi databaseapplikationer for det meste handler om at udføre en masse SQL-forespørgsler, har ydeevneproblemer mange steder at gemme sig i SQL Server. Hvis du er en bruger, kan du sige:"Åh, godt, problemet må være inde i den sorte boks et eller andet sted. Ikke mit job.”

Men som DBA har du ikke den luksus. Du skal åbne den sorte boks, kravle ind, finde rodet og ordne det.

Forespørgselsprofilering 101 med overvågning af SQL-serverens ydeevne

Generelt er dit mål med overvågning af serverydeevne at holde øje med, hvordan dine SQL-forespørgsler klarer sig over tid og over væksten i transaktionsvolumen på din SQL Server. Du kan nå det mål på flere måder.

Kig på forklaringsplanen

Forklaringsplanen viser, hvad SQL Server vil gøre ved udførelse af forespørgslen, inklusive de tabeller, den vil forbinde, typen af ​​joinforbindelse, den vil udføre, antallet af rækker, den vil røre ved, og de indekser, den vil bruge.

Hvad kan forklaringsplanen fortælle dig? For det første kan du se, hvordan du forbedrer selve forespørgslen ved for eksempel at fjerne en NESTED LOOP JOIN, som en af ​​databaseudviklerne tilføjede mod en enorm tabel. Eller du kan ud fra forklaringsplanen finde ud af, at du skal oprette eller genopbygge et indeks for en bestemt tabel.

Forklaringsplanen er et godt udgangspunkt for forespørgselsprofilering, selv før du rent faktisk udfører de mistænkelige forespørgsler.

Udfør forespørgslen

For at udføre forespørgslerne og se, hvilke ressourcer de påvirker under kørsel, opretter du først spor for at markere hændelser, efterhånden som de opstår. Med spor kan du fange data og holde øje med, om der opstår fejl. Et profileringsværktøj gemmer de data, sporene har fanget, og viser dem på en måde, der gør det nemmere for dig at finde og fejlfinde problematiske forespørgsler.

Kombinationen af ​​sporene og profileringsværktøjet kan besvare mange spørgsmål:

  • Hvilke forespørgsler bruger mest hukommelse?
  • Hvor lang tid tager hver forespørgsel at udføre?
  • Hvilke låse indstiller SQL Server for hver forespørgsel?
  • Hvilke forespørgsler kan SQL Server udføre fra buffercachen? Hvor ofte skal den til disken?
  • Hvor mange rækker undersøger hver forespørgsel?
  • Hvor mange anmodninger pr. minut opfylder databasen?

Du får den mest nøjagtige læsning ved at udføre forespørgslen på dine produktionsdatabaser, men det kan også forsinke behandlingen af ​​dine kunder og brugere i den virkelige verden. Hvis du kan, test først på udviklings- eller testforekomster, hvor du ikke konkurrerer om hukommelse eller I/O med din produktionsinstans.

Når vi taler om kunder og brugere, så er dit mål med forespørgselsprofilering at gøre dem glade. Profilering kan nemt afdække snesevis af problemer i din database, men grunden til, at du har åbnet den sorte boks, er for at løse de mest smertefulde problemer. Efter at have fanget data fra en dag eller to med normal brug, kan du finde de problemer med SQL-serverens ydeevne, der giver dine brugere de største problemer. Måske bremser et manglende indeks hentning af registreringer, eller for mange indekser bremser postindsættelse og databaseopdateringer. Måske samler en ofte brugt forespørgsel information, som ingen længere bekymrer sig om.

Brug profileringsværktøjer klogt

Profileringsværktøjer redder dig fra den kedelige proces med manuelt at opsætte hver hændelse, filter og procedure kræver alt, hvad du ønsker at spore. Med så meget, der foregår inde i den sorte boks af SQL Server-ydeevne, kan du nemt fange for mange data til at se skoven for træerne.

Gode ​​værktøjer giver dig mulighed for omhyggeligt at vælge, hvad du sporer, så du for eksempel ikke fanger hundredvis af Lock:Acquired-begivenheder og unødigt fylder din skærm med dem. Men hvis du har brug for at undersøge en hyppigt forekommende hændelse, skal du bruge filtre som applikationsnavn eller tabelnavn.

I stedet for at skrive sporingsdata til en tabel i en database, kan du overveje at gemme dem i sin egen, separate fil. Det forhindrer overhead af sporet fra at blive en byrde for SQL Server og potentielt skævvridende resultater. Hvis dit profileringsværktøj foretrækker data hentet fra en tabel, kan du importere dataene fra filen til tabellen senere.

Forbedre overvågningen af ​​din SQL Server-ydelse med forespørgselsprofilering

Dine brugere holder sig væk fra den sorte boks med SQL Server-ydeevne, men det behøver du ikke. Forespørgselsprofilering er, hvordan du åbner boksen, finder ud af, hvad der foregår indeni og begynder at fejlfinde.

Men vent ikke, indtil du har problemer med at bruge det. Forespørgselsprofilering er mere som at tjekke olien end at udskifte motoren. Det hjælper med de sædvanlige DBA-opgaver med at opdatere forældede forespørgsler og ændre design, så dine databaser holder trit med ændringer i virksomheden.


  1. Hvordan arbejder man med PGpoint for Geolocation ved hjælp af PostgreSQL?

  2. Opsætning af fremmednøgle med anden datatype

  3. Neo4j - Opret et indeks ved hjælp af Cypher

  4. En løsning til:Markører understøttes ikke på en tabel, som har et klynget kolonnelagerindeks