Kuber kräver frekvent övervakning eftersom deras produktivitet minskar ganska ofta (avmattningar under frågebyggnad, ökning av bearbetningstiden). För att ta reda på orsaken till minskningen måste vi övervaka vårt system. För detta använder vi SQL Server Profiler. Microsoft planerar dock att utesluta detta SQL-spårningsverktyg i efterföljande versioner. Den största nackdelen med verktyget är resursintensitet, och det bör köras på en produktionsserver noggrant, eftersom det kan orsaka en kritisk systemproduktivitetsförlust.
Extended Events är alltså ett allmänt händelsehanteringssystem för serversystem. Detta system stöder korrelationen av data från SQL Server vilket gör det möjligt att få SQL Server-tillståndshändelser.
Systemarkitekturen visas nedan:
Faktum är att vi har ett paket som innehåller händelser, mål, åtgärder, typer, predikat och kartor. Sessioner som innehåller händelser, mål, åtgärder körs på servern. Jag kommer inte att beskriva arkitekturen i detalj eftersom hjälpen innehåller en explicit beskrivning.
Låt oss nu återgå till vår SSAS. För att göra allt mer levande, låt oss överväga flera scenarier som vi använder för problemanalys.
Första scenariot:Kubbearbetningsanalys (Multidimensional Cube)
Det är ofta fallet när en kub uppdateras under mycket lång tid under bearbetningen, även om datavolymen är ganska låg. För att ta reda på orsaken måste vi förstå vilken fråga eller vilken plats för bearbetning som orsakar nedgången. Naturligtvis kan vi köra bearbetning på produktion och se vad som händer, men jag är inte säker på att dina användare kommer att uppskatta det. Här kommer Extended Events till hjälp. Låt oss köra vår session och konfigurera hur den sparas till en fil.
Låt oss öppna SSMS och ansluta till SSAS och sedan byta till Management.
Låt oss nu skapa en ny session:
- På fliken Allmänt, ange ett namn för vår session och ladda en mall.
- Händelserna fliken visar händelserna som hjälper oss att analysera problemen. Fliken visar alla våra gamla vänner från Profiler. Låt oss välja följande händelser för bearbetningsanalys:CommandBegin , CommandEnd, Progr essReportBegin och ProgressReportEnd, ResourseUsage.
CommandBegin , CommandEnd kommer att visa början och slutet av kommandoexekveringen under bearbetning.
Progr essReportBegin och ProgressReportEn tillhandahålla utökad information om längden på varje händelse och visa data som lästs, körning av SQL-frågor, längd etc.
Resursanvändning visar antalet resurser som spenderades på att köra en fråga, en åtgärd.
När vi valde händelserna kan vi byta till att konfigurera varje händelse och ange vilka händelser som måste visas och vilka händelser som måste döljas (till exempel kan vi dölja process-id).
- Datalagring flik. Här kan vi specificera att antingen visa händelser i realtidsläge eller skriva dem till en fil:
- event_file – spara händelse till en fil för vidare analys. Ange maximal filstorlek och destinationssökväg. Om filstorleken överstiger den angivna storleken skapas en ny fil. Vi kan också ange antalet filer som måste skapas (maximalt antal filer).
- event_stream – möjliggör visning av händelser i realtidsläge.
- ring_buffert – anger att sessionsdata måste lagras i minnet så länge servern körs. Vid omladdning kommer data att tas bort.
- Det Avancerade fliken tillåter konfigurering av resurser (minne, processor) för en given session.
Klicka slutligen på OK och få sessionen. Låt oss köra kubbearbetning och se bearbetningen efter händelser. Växla till livedataläget.
Överst på följande skärmdump kan vi se händelserna som äger rum just nu med vår instans. Detaljer om händelserna visas längst ner. Alla värden på händelsedetaljerna kan läggas till som en separat kolumn högst upp. Högerklicka på ett valt värde i händelseinformationen och visa dem i en tabell.
I resultatet får vi följande vy:
Därför tillåter utökade händelser att analysera vår bearbetning i realtidsläge. Vi kan förstå hur mycket tid som läggs på bearbetningen av varje objekt, hur många resurser som används varpå. Detta hjälper till att dra slutsatser och hitta svaga punkter. Dessutom överbelastar vi inte systemet och får ingen produktivitetsförlust.
Du kan också skapa session via XMLA. Du kan hämta skriptet på GitHub.
Stoppa och radera en session är möjlig via både SSMS och XMLA.
- Via SSMS (men 2016 inträffade felet och jag misslyckades med att ta bort sessionen via gränssnittet).
- XMLA-skript – kan laddas ner här.
Detta är den första delen av artikeln om Extended Events för SSAS. I den andra delen kommer vi att överväga ett scenario med frågeproduktivitetsanalys i kub, arbeta med spårningsfil och analysera filen via Power BI.
Jag rekommenderar också att du tar en titt på följande blogginlägg:
- Pinal Dave — SQL SERVER – SQL Profiler vs Extended Events
- Chris Web — Profiler, utökade evenemang och analystjänster. Även om författaren till artikeln säger att Profiler nästan inte används på produktionsservrar, men bekräftar dess problem med serverbelastning.
- Brent Ozar — SQL Server Extended Events