I løbet af overvågning af ydeevne eller fejlfinding af et problem som f.eks. systemets langsomhed, kan det være nødvendigt at finde eller fange forespørgsler, der har høj varighed, høj CPU eller genererer betydelig I/O under udførelsen. Du kan bruge DMV'erne eller Query Store til at få oplysninger om forespørgselsydeevne, men oplysningerne i begge kilder er samlet. DMV'erne repræsenterer kun gennemsnitlig CPU, I/O, varighed osv. for en forespørgsel, så længe den har været i cachen. Query Store giver også gennemsnitlige metrics for adskillige ressourcer, men det er aggregeret over et defineret tidsrum (f.eks. 30 minutter eller en time). Der er selvfølgelig 3. parts overvågningsløsninger, der er mere end i stand til at give dig alt dette og mere (som SentryOne), men til dette indlæg ville jeg fokusere på native værktøjer.
Hvis du ønsker at forstå forespørgselsydeevne for individuelle udførelser for at lokalisere den nøjagtige forespørgsel eller sæt forespørgsler, som kan være et problem, er den nemmeste mulighed at bruge udvidede hændelser. Og en af de hurtigste måder at komme i gang på er at bruge XEvent Profiler, som er tilgængelig via SQL Server Management Studio (starter i version 17.3):
XEvent Profiler i SSMS
Grundlæggende brug
Der er to muligheder for XEvent Profiler:Standard og TSQL. For at bruge en af dem skal du blot dobbeltklikke på navnet. Bag kulisserne oprettes en internt defineret begivenhedssession (hvis den ikke allerede eksisterer) og startes, og Live Data Viewer åbner straks med fokus. Bemærk, at når du har startet sessionen, vil den også vises under Ledelse | Udvidede arrangementer | Sessioner. Hvis du antager, at du har aktivitet mod serveren, bør du begynde at få indgange vist i fremviseren om fem sekunder eller mindre.
Live Data Viewer (efter dobbeltklik for at starte standardsession)
Standard- og TSQL-sessionerne deler nogle begivenheder, hvor standarden har flere i alt. Her er en liste over begivenhederne for hver:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Hvis du ønsker at forstå information om udførelse af forespørgsler, såsom hvor lang tid det tog forespørgslen at køre, eller hvor meget I/O den forbrugte, så er Standard en bedre mulighed på grund af de to afsluttede hændelser. For begge sessioner er det eneste filter at ekskludere systemforespørgsler for batch-, rpc- og opmærksomhedshændelser.
Visning og lagring af data
Hvis vi starter Standard-sessionen og kører nogle forespørgsler, ser vi begivenheden, forespørgselsteksten og andre nyttige oplysninger som cpu_time, logical_reads og varighed i fremviseren. En af fordelene ved at bruge rpc_completed og sql_batch_completed er, at inputparameteren dukker op. I et tilfælde, hvor der er en lagret procedure, som har store variationer i ydeevne, kan indfangning af inputparameteren være yderst nyttig, da vi kan matche en udførelse, der tager længere tid, med en specifik værdi, der sendes ind i den lagrede procedure. For at finde sådan en parameter skal vi sortere data ud fra varighed, hvilket vi ikke kan, når datafeedet er aktivt. For at udføre enhver form for analyse skal datafeedet stoppes.
Stop datafeedet i Live Viewer
Nu hvor mine forespørgsler ikke længere ruller forbi i en sløring, kan jeg klikke på varighedskolonnen for at sortere mine begivenheder. Første gang jeg klikker, vil det sortere i stigende rækkefølge, og fordi jeg er doven og ikke vil rulle i bunden, klikker jeg igen for at sortere i faldende rækkefølge.
Begivenheder sorteret i faldende varighed
Nu kan jeg se alle de begivenheder, jeg har fanget, i rækkefølge af højeste varighed til laveste. Hvis jeg ledte efter en specifik lagret procedure, der var langsom, kunne jeg enten rulle ned, indtil jeg finder den (hvilket kunne være smertefuldt), eller jeg kunne gruppere eller filtrere dataene. Gruppering er nemmere her, fordi jeg kender navnet på den lagrede procedure.
Objektnavnet vises i den øverste del af fremviseren, men ved at klikke på en hvilken som helst rpc_completed hændelse vises alle elementer, der er fanget i ruden Detaljer. Højreklik på objektnavn, som vil fremhæve det, og vælg Vis kolonne i tabel.
Tilføj objektnavn til datafremviser
I den øverste rude kan jeg nu højreklikke på objektnavn og vælge Grupper efter denne kolonne. Hvis jeg udvider begivenhederne under usp_GetPersonInfo og derefter sorterer igen efter varighed, ser jeg nu, at udførelsen med PersonID=3133 havde den højeste varighed.
Begivenheder grupperet efter objektnavn, usp_GetPersonInfo sorteret efter varighed faldende
For at filtrere dataene:Brug enten knappen Filtre…, menupunktet (Udvidede hændelser | Filtre…), eller CTRL + R for at få et vindue frem for at reducere resultatsættet baseret på de forskellige viste felter. I dette tilfælde filtrerede vi på object_name =usp_GetPersonInfo, men du kunne også filtrere på felter som server_principal_name eller client_app_name, efterhånden som disse blev indsamlet.
Det er værd at påpege, at hverken Standard- eller TSQL-sessionen skriver ud til en fil. Faktisk er der intet mål for nogen af begivenhedssessionerne (hvis du ikke vidste, at du kan oprette en begivenhedssession uden et mål, nu ved du det). Hvis du vil gemme disse data til yderligere analyse, skal du gøre et af følgende:
- Stop datafeedet, og gem outputtet til en fil via menuen Udvidede hændelser (Eksporter til | XEL-fil...)
- Stop datafeedet, og gem outputtet til en tabel i en database via menuen Udvidede hændelser (Eksporter til | Tabel...)
- Rediger begivenhedssessionen, og tilføj begivenhedsfilen som et mål.
Mulighed 1 er min anbefaling, da den opretter en fil på disk, som du kan dele med andre og gennemgå senere i Management Studio for yderligere analyse. I Management Studio har du mulighed for at filtrere data fra, der ikke er relevante, sortere efter en eller flere kolonner, gruppere dataene og udføre beregninger (f.eks. gennemsnit). Du kan gøre dette, hvis dataene er en tabel, men du skal skrive TSQL; at analysere dataene i brugergrænsefladen er nemmere og hurtigere.
Ændring af XEvent Profiler-sessionerne
Du kan ændre standard- og TSQL-begivenhedssessionerne, og de ændringer, du foretager, vil fortsætte gennem genstart af forekomster. Men hvis begivenhedssessionerne droppes (efter du har foretaget ændringer), vil de nulstilles til standardindstillingerne. Hvis du finder dig selv løbende at foretage de samme ændringer, foreslår jeg, at du skriver ændringerne ud og opretter en ny begivenhedssession, der også vil vare ved på tværs af genstarter. Som et eksempel, hvis vi ser på outputtet, der er fanget indtil nu, kan vi se, at både adhoc-forespørgsler og lagrede procedurer er blevet udført. Og selvom det er fantastisk, at jeg kan se de forskellige inputparametre for de lagrede procedurer, kan jeg ikke se de individuelle udsagn, der udføres med dette sæt af hændelser. For at få disse oplysninger skal jeg tilføje begivenheden sp_statement_completed.
Forstå, at både Standard- og TSQL-begivenhedssessionerne er designet til at være lette. Statement_completed-hændelserne udløses oftere end batch- og rpc-hændelser, så der kan være mere overhead, når disse hændelser er en del af en hændelsessession. Når jeg bruger erklæringsbegivenheder, i høj grad anbefaler at inkludere yderligere prædikater. Som en påmindelse filtrerer rpc- og batchhændelser kun systemforespørgsler fra – der er intet andet prædikat. Generelt anbefaler jeg også yderligere prædikater for disse begivenheder, især for en stor arbejdsbyrde.
Hvis du er bekymret for, om kørsel af Standard- eller TSQL-sessionerne vil forårsage et præstationshit på dit system, skal du forstå, at Live Data Viewer vil afbryde forbindelsen, hvis det skaber for meget overhead på systemet. Dette er en stor sikkerhed, men jeg ville stadig være betænksom, når jeg bruger disse begivenhedssessioner. Jeg tror, de er et fantastisk første skridt til fejlfinding, især for dem, der er nye til SQL Server eller Extended Events. Men hvis du har Live Data Viewer åben, og du går væk fra din maskine, fortsætter begivenhedssessionen med at køre . Stop eller lukning af Live Data Viewer vil stoppe begivenhedssessionen, hvilket er det, jeg anbefaler, når du er færdig med din dataindsamling eller fejlfinding.
For begivenhedssessioner, som du ønsker at køre i en længere periode, skal du oprette separate begivenhedssessioner, der skriver ud til event_file-målet og har passende prædikater. Hvis du har brug for mere information om at komme i gang med Extended Events, så tjek den session, jeg holdt på SQLBits sidste år om migrering fra Profiler til Extended Events.