Kuber kræver hyppig overvågning, da deres produktivitet falder ret ofte (opbremsninger under opbygning af forespørgsler, stigning i behandlingstid). For at finde ud af årsagen til faldet, skal vi overvåge vores system. Til dette bruger vi SQL Server Profiler. Microsoft planlægger dog at udelukke dette SQL-sporingsværktøj i efterfølgende versioner. Den største ulempe ved værktøjet er ressourceintensitet, og det bør køres på en produktionsserver omhyggeligt, da det kan forårsage et kritisk systemproduktivitetstab.
Extended Events er således et generelt hændelseshåndteringssystem til serversystemer. Dette system understøtter korrelationen af data fra SQL Server, hvilket gør det muligt at få SQL Server-tilstandsbegivenheder.
Systemarkitekturen er vist nedenfor:
Faktisk har vi en pakke, der indeholder begivenheder, mål, handlinger, typer, prædikater og kort. Sessioner, der indeholder hændelser, mål, handlinger, køres på serveren. Jeg vil ikke beskrive arkitekturen i detaljer, da hjælpen indeholder en eksplicit beskrivelse.
Lad os nu vende tilbage til vores SSAS. For at gøre alt mere levende, lad os overveje flere scenarier, som vi bruger til problemanalyse.
Første scenarie:Terningbehandlingsanalyse (Multidimensional kube)
Det er ofte tilfældet, når en terning bliver opdateret i meget lang tid under behandlingen, selvom datamængden er ret lav. For at finde ud af årsagen skal vi forstå, hvilken forespørgsel eller hvilket behandlingssted der forårsager afmatningen. Selvfølgelig kan vi køre behandling på produktion og se, hvad der foregår, men jeg er ikke sikker på, at dine brugere vil sætte pris på det. Her kommer Extended Events til hjælp. Lad os køre vores session og konfigurere dens lagring til en fil.
Lad os åbne SSMS og oprette forbindelse til SSAS, og derefter skifte til Management.
Lad os nu oprette en ny session:
- På fanen Generelt skal du angive et navn til vores session og indlæse en skabelon.
- Begivenheder fanen viser de begivenheder, der vil hjælpe os med at analysere problemerne. Fanen viser alle vores gamle venner fra Profiler. Lad os vælge følgende hændelser til behandlingsanalyse:CommandBegin , CommandEnd, Progr essReportBegin og ProgressReportEnd, ResourseUsage.
CommandBegin , CommandEnd vil vise begyndelsen og slutningen af kommandoudførelse under behandling.
Progr essReportBegin og ProgressReportEn give udvidet information om længden af hver hændelse og vise data læst, udførelse af SQL-forespørgsler, længde osv.
Resursbrug viser antallet af ressourcer, der blev brugt på at udføre en forespørgsel, en handling.
Når vi valgte begivenhederne, kan vi skifte til at konfigurere hver begivenhed og specificere, hvilke begivenheder der skal vises, og hvilke begivenheder der skal skjules (for eksempel kan vi skjule proces-id).
- Datalagring fanen. Her kan vi angive enten at vise hændelser i realtidstilstand eller skrive dem til en fil:
- event_file – gemmer hændelse til en fil til yderligere analyse. Angiv den maksimale filstørrelse og destinationssti. Hvis filstørrelsen overstiger den angivne størrelse, oprettes en ny fil. Vi kan også angive antallet af filer, der skal oprettes (maksimalt antal filer).
- event_stream – gør det muligt at se begivenheder i realtidstilstand.
- ring_buffer – angiver, at sessionsdata skal gemmes i hukommelsen, så længe serveren kører. I tilfælde af genindlæsning vil data blive slettet.
- Det Avancerede fanen tillader konfiguration af ressourcer (hukommelse, processor) for en given session.
Klik til sidst på OK og få sessionen. Lad os køre kubebehandling og se behandlingen efter begivenheder. Skift til livedatatilstand.
Øverst på det følgende skærmbillede kan vi se de begivenheder, der finder sted lige nu med vores instans. Detaljer om begivenhederne er vist nederst. Enhver værdi af begivenhedsdetaljerne kan tilføjes som en separat kolonne øverst. Højreklik på en valgt værdi af begivenhedsdetaljerne og se dem i en tabel.
I resultatet får vi følgende visning:
Derfor giver udvidede begivenheder mulighed for at analysere vores behandling i realtidstilstand. Vi kan forstå, hvor meget tid der bruges på behandlingen af hvert objekt, hvor mange ressourcer der bruges hvorefter. Dette hjælper med at drage konklusioner og finde svage punkter. Derudover overbelaster vi ikke systemet og får ikke produktivitetstab.
Du kan også oprette session via XMLA. Du kan hente scriptet på GitHub.
Stop og sletning af en session er muligt via både SSMS og XMLA.
- Via SSMS (i 2016 opstod fejlen dog, og jeg kunne ikke slette session via interface).
- XMLA-script – kan downloades her.
Dette er første del af artiklen om Extended Events for SSAS. I den anden del vil vi overveje et scenarie med forespørgselsproduktivitetsanalyse i kube, arbejde med sporingsfil og analysere filen via Power BI.
Jeg anbefaler også at tage et kig på følgende blogindlæg:
- Pinal Dave — SQL SERVER – SQL Profiler vs Extended Events
- Chris Web — Profilering, udvidede begivenheder og analysetjenester. Selvom forfatteren af artiklen siger, at Profiler næsten ikke bruges på produktionsservere, men bekræfter dets problemer med serverbelastning.
- Brent Ozar — SQL Server Extended Events