I samband med att övervaka prestanda eller felsöka ett problem som att systemet är långsamt, kan det vara nödvändigt att hitta eller fånga frågor som har lång varaktighet, hög CPU eller genererar betydande I/O under körning. Du kan använda DMV:er eller Query Store för att få information om frågeprestanda, men informationen i båda källorna är sammanställd. DMV:erna representerar genomsnittlig CPU, I/O, varaktighet etc. för en fråga bara så länge den har legat i cachen. Query Store tillhandahåller också genomsnittliga mätvärden för många resurser, men det är aggregerat över ett definierat tidsfönster (t.ex. 30 minuter eller en timme). Det finns naturligtvis tredjepartsövervakningslösningar som mer än kan ge dig allt detta och mer (som SentryOne), men för det här inlägget ville jag fokusera på inbyggda verktyg.
Om du vill förstå frågeprestanda för individuella körningar för att lokalisera den exakta frågan eller uppsättningen av frågor som kan vara ett problem, är det enklaste alternativet att använda Extended Events. Och ett av de snabbaste sätten att komma igång är att använda XEvent Profiler, som är tillgänglig via SQL Server Management Studio (från och med version 17.3):
XEvent Profiler i SSMS
Grundläggande användning
Det finns två alternativ för XEvent Profiler:Standard och TSQL. För att använda någon av dem, dubbelklicka bara på namnet. Bakom kulisserna skapas en internt definierad händelsesession (om den inte redan finns) och startas, och Live Data Viewer öppnas omedelbart med fokus. Observera att när du har startat sessionen kommer den också att visas under Ledning | Utökade evenemang | Sessioner. Förutsatt att du har aktivitet mot servern bör du börja se poster i visningsprogrammet om fem sekunder eller mindre.
Live Data Viewer (efter att ha dubbelklickat för att starta standardsessionen)
Standard- och TSQL-sessionerna delar vissa händelser, där standarden har fler totalt. Här är en lista över händelserna för varje:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Om du vill förstå information om körning av frågor, till exempel hur lång tid det tog att köra frågan, eller hur mycket I/O den förbrukade, är Standard ett bättre alternativ på grund av de två avslutade händelserna. För båda sessionerna är det enda filtret att utesluta systemfrågor för batch-, rpc- och uppmärksamhetshändelser.
Visa och spara data
Om vi startar standardsessionen och kör några frågor ser vi händelsen, frågetexten och annan användbar information som cpu_time, logical_reads och varaktighet i visningsprogrammet. En av fördelarna med att använda rpc_completed och sql_batch_completed är att indataparametern dyker upp. I ett fall där det finns en lagrad procedur som har stora variationer i prestanda kan det vara extremt användbart att fånga indataparametern eftersom vi kan matcha en exekvering som tar längre tid med ett specifikt värde som skickas in i den lagrade proceduren. För att hitta en sådan parameter behöver vi sortera data baserat på varaktighet, vilket vi inte kan göra när dataflödet är aktivt. För att utföra någon form av analys måste dataflödet stoppas.
Stoppa dataflödet i Live Viewer
Nu när mina frågor inte längre rullar förbi i en oskärpa kan jag klicka på kolumnen varaktighet för att sortera mina händelser. Första gången jag klickar kommer det att sorteras i stigande ordning, och eftersom jag är lat och inte vill rulla längst ned klickar jag igen för att sortera i fallande ordning.
Händelser sorterade i fallande varaktighet
Nu kan jag se alla händelser jag har fångat i ordning av högsta varaktighet till lägsta. Om jag letade efter en specifik lagrad procedur som var långsam, kunde jag antingen scrolla ner tills jag hittar den (vilket kan vara smärtsamt), eller så kan jag gruppera eller filtrera data. Gruppering är lättare här, eftersom jag känner till namnet på den lagrade proceduren.
Objektnamnet visas i den övre delen av visningsprogrammet, men om du klickar på en rpc_completed-händelse visas alla element som fångats i detaljrutan. Högerklicka på objektnamn, vilket kommer att markera det, och välj Visa kolumn i tabell.
Lägg till objektnamn i datavisaren
I den övre rutan kan jag nu högerklicka på objektnamn och välja Gruppera efter denna kolumn. Om jag utökar händelserna under usp_GetPersonInfo och sedan sorterar igen efter varaktighet ser jag nu att exekveringen med PersonID=3133 hade den högsta varaktigheten.
Händelser grupperade efter objektnamn, usp_GetPersonInfo sorterade efter varaktighet fallande
För att filtrera data:Använd antingen knappen Filter..., menyalternativet (Utökade händelser | Filter...), eller CTRL + R för att få fram ett fönster för att minska resultatuppsättningen baserat på de olika fälten som visas. I det här fallet filtrerade vi på object_name =usp_GetPersonInfo, men du kan också filtrera på fält som server_principal_name eller client_app_name, eftersom de samlades in.
Det är värt att påpeka att varken Standard- eller TSQL-sessionen skriver ut till en fil. Faktum är att det inte finns något mål för någon av evenemangssessionerna (om du inte visste att du kan skapa en evenemangssession utan ett mål, nu vet du det). Om du vill spara denna data för vidare analys måste du göra något av följande:
- Stoppa dataflödet och spara utdata till en fil via menyn Extended Events (Exportera till | XEL-fil...)
- Stoppa dataflödet och spara utdata till en tabell i en databas via menyn Utökade händelser (Exportera till | Tabell...)
- Ändra händelsesessionen och lägg till händelsefilen som mål.
Alternativ 1 är min rekommendation, eftersom det skapar en fil på disk som du kan dela med andra och granska senare i Management Studio för vidare analys. Inom Management Studio har du möjlighet att filtrera bort data som inte är relevant, sortera efter en eller flera kolumner, gruppera data och utföra beräkningar (t.ex. medelvärden). Du kan göra detta om data är en tabell, men du måste skriva TSQL; att analysera data i användargränssnittet är enklare och snabbare.
Ändra XEvent Profiler-sessioner
Du kan ändra standard- och TSQL-händelssessionerna och ändringarna du gör kommer att bestå genom omstarter av instanser. Men om händelsesessionerna avbryts (efter att du har gjort ändringar) kommer de att återställas till standardinställningarna. Om du märker att du ständigt gör samma ändringar, föreslår jag att du skriver ut ändringarna och skapar en ny händelsesession som också kommer att fortsätta under omstarter. Som ett exempel, om vi tittar på utdata som fångats hittills, kan vi se att både adhoc-förfrågningar och lagrade procedurer har exekverats. Och även om det är bra att jag kan se de olika inmatningsparametrarna för de lagrade procedurerna, ser jag inte de individuella satserna som körs med denna uppsättning händelser. För att få den informationen måste jag lägga till händelsen sp_statement_completed.
Förstå att både standard- och TSQL-evenemangssessionerna är designade för att vara lätta. Händelserna statement_completed kommer att aktiveras oftare än batch- och rpc-händelserna, så det kan bli mer overhead när dessa händelser är en del av en händelsesession. När jag använder uttalandehändelser är jag mycket rekommenderar att du inkluderar ytterligare predikat. Som en påminnelse filtrerar rpc- och batchhändelserna bara bort systemfrågor – det finns inget annat predikat. I allmänhet rekommenderar jag också ytterligare predikat för dessa händelser, särskilt för en hög volym arbetsbelastning.
Om du är orolig för huruvida körning av Standard- eller TSQL-sessionerna kommer att orsaka en prestandaträff på ditt system, förstå att Live Data Viewer kopplas från om det skapar för mycket overhead på systemet. Detta är en stor säkerhet, men jag skulle ändå vara omtänksam när jag använder dessa evenemangssessioner. Jag tror att de är ett fantastiskt första steg för felsökning, särskilt för dem som är nya med SQL Server eller Extended Events. Men om du har Live Data Viewer öppen och du går bort från din maskin, fortsätter händelsesessionen att köras . Om du stoppar eller stänger Live Data Viewer stoppas händelsesessionen, vilket är vad jag rekommenderar när du är klar med din datainsamling eller felsökning.
För händelsesessioner som du vill köra under en längre tid, skapa separata händelsesessioner som skriver ut till event_file-målet och har lämpliga predikat. Om du behöver mer information om att komma igång med Extended Events kolla in sessionen jag gav på SQLBits förra året om migrering från Profiler till Extended Events.