SQL Server har alltid gett möjligheten att fånga live-frågor på ad hoc-basis i ett lättanvänt raduppsättningsformat – först med äldre SQL Server Profiler, senare via Extended Events i SSMS. Denna förmåga är värdefull vid prestandajustering eftersom frågehändelser inkluderar diskreta CPU- och IO-mått samt körtidsparametrar, som är nyckeln för att felsöka frågeprestandaproblem som parametersniffning. Vidare innehåller frågehändelser andra viktiga element som klientens värdnamn, applikationsnamn, inloggning, Windows process-ID, etc.
Du kan alltid hämta samlad prestandamått för normaliserade frågor från DMVs eller Query Store, men de innehåller bara kompilerade parametrar och ingen av de tidigare nämnda elementen. Även om detta är användbart, är det inte samma sak. Om du till exempel behöver se den specifika parameterkombinationen som används av den frågan som gjorde 2 miljarder läsningar eller hitta den mest CPU-krävande applikationen under de senaste 24 timmarna, har du ingen tur.
Azure SQL Database stöds inte av äldre Profiler, och Microsoft inaktiverade XEvents-strömningsleverantören (sys.fn_MSxe_read_event_stream TVF) av tillförlitlighetsskäl, så du kan inte snurra upp en XE-session och "titta på livedata" med SSMS. Query Performance Insights i Azure Portal stöds av Query Store, så du har återigen bara de normaliserade frågorna och aggregerade prestandadata, inte de faktiska frågehändelserna.
Så under några år var vi fast – det enda alternativet för att profilera Azure SQL Database var att manuellt skapa en XEvents-spårning som skriver till en ringbuffert eller filmål med Azure Storage, varken är optimal. Att använda ringbufferten med T-SQL-frågor kan vara problematiskt på grund av den formaterade XML-gränsen på 4 MB som täcks av Jonathan Kehayias här, och filmål kräver en hel del hophoppning och extra kostnader. Båda kräver manuell sökning av XE-data och är därför inte exakt "live" i traditionell mening.
Ange Ny SQL Server Profiler
När jag fick reda på SQL Server Profiler-tillägget för Azure Data Studio var jag glad över att se Microsoft äntligen leverera en grafisk lösning för livefrågefångst i Azure SQL Database. Tyvärr var min upphetsning kortvarig av ett par anledningar.
För det första har det fruktade "Standard"-spåret från äldre Profiler uppenbarligen använts som modell för ADS Profiler XE-sessionen för Azure SQL Database , med namnet ADS_Standard_Azure som standard. (XE-sessionerna som används för fullständig SQL Server är liknande.) Som jag bloggade för flera år sedan och fortfarande tror, är standardspåret en primär orsak till att äldre Profiler är så dåligt ansedd. Den innehåller flera värdelösa och ofiltrerbara händelser som SQL batchstart , logga in och logga ut , och som ett resultat tillför det inget verkligt värde för prestandajustering. Dessutom, med den synkrona raduppsättningsspårningsarkitekturen som används av äldre Profiler, kan den höga händelsevolymen påverka prestandan på upptagna system. Av någon anledning kommer den här saken inte att försvinna!
| |
| Legacy Profiler "Standard" spårningshändelser |
ADS Profiler “ADS_Standard_Azure” XE-händelser |
För det andra använder den en ringbuffert med en maxstorlek på 8MB eller 1000 händelser, beroende på vad som kommer först. Eftersom inloggnings-/utloggningshändelserna är små, kommer du ofta att nå 1000 händelser långt innan du når gränsen på 8 MB, eller till och med den formaterade XML-gränsen på 4 MB. Men med en måttlig blandning av SQL-händelser kommer ringbufferten XML fortfarande att vara 2 till 3MB vid 1000 händelser i mina tester, och problemet är att hela denna buffert dras över nätverket varje gång Profiler-tillägget pollar för att uppdatera dess rutnät , vilket är den längsta av var 1:e sekund eller varaktigheten av föregående omröstning. XML tolkas sedan på klientsidan av ADS Profiler-tillägget för att avgöra vilka händelser som är nya sedan den senaste omröstningen, och de nya händelserna läggs till i rutnätet.
Ringbufferten fylls nästan omedelbart på även en måttligt upptagen server, och nettoeffekten är att du snabbt kommer att dra>40 megabit per sekund över nätverket från din Azure SQL-databas . Detta översätts till 300 megabyte per minut, eller 18 gigabyte per timme!
Nätverksträff från ADS Profiler-tillägget (4-minutersintervall)
Min första rädsla var att detta kunde leda till enorma utträdesavgifter på nästa Azure-faktura, men när vi tittade på våra egna Azure-prenumerationer kunde vi inte bekräfta att nätverkstrafik för Azure SQL DB debiteras. SentryOnes Mike Wood (b|t), en Azure MVP, tillbringade veckor med att försöka hitta svaret och fick till slut besked från Microsoft att det faktiskt inte debiteras för Azure SQL DB för nätavgång för närvarande, även om detta kan ändras när som helst. Ändå verkar det inte vara ansvarsfullt att dra ner 18 GB frågedata per timme, och det kan säkert lägga en dämpning på din nästa Netflix-session för binge-watching.
Även om du kan ställa in filter via Profiler UI som gör data lättare att granska, kommer det inte att minska nätverksträffen eftersom de fungerar på klientsidan.
En uppdaterad XE-session
En snabb lösning för att minska nätverksbördan för ADS Profiler och göra data mycket mer förbrukningsbara för justering av frågeprestanda är att uppdatera ADS_Standard_Azure XE-session. Nedan är ett skript som kommer:
- Ta bort de värdelösa händelserna:
- sqlserver.attention
- sqlserver.existing_connection
- sqlserver.login
- sqlserver.logout
- sqlserver.sql_batch_starting
- Ställ in en tröskel för varaktighet> 1 sekund (1000000 mikrosekunder) för de återstående händelserna:
- sqlserver.rpc_completed
- sqlserver.sql_batch_completed
- Minska ringbuffertens maxstorlek från 1000 till 10 händelser
- Detta skulle aldrig fungera med den ursprungliga spårningen eftersom 10 händelser kommer att genereras på millisekunder och ringbufferten skulle återvinnas för snabbt vilket gör att de flesta händelser går förlorade. Men med 1-sekunds varaktighetsfiltret blir händelseflödet mycket lägre, och 10 händelser bör fungera bra med 1-sekunds avfrågningsintervallet som används av ADS Profiler.
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
DROP EVENT sqlserver.attention,
DROP EVENT sqlserver.existing_connection,
DROP EVENT sqlserver.login,
DROP EVENT sqlserver.logout,
DROP EVENT sqlserver.rpc_completed,
DROP EVENT sqlserver.sql_batch_completed,
DROP EVENT sqlserver.sql_batch_starting
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
ADD EVENT sqlserver.rpc_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000)))),
ADD EVENT sqlserver.sql_batch_completed(
ACTION(package0.event_sequence,sqlserver.client_app_name,sqlserver.client_pid,sqlserver.database_id,sqlserver.query_hash,sqlserver.session_id,sqlserver.username)
WHERE (([package0].[equal_boolean]([sqlserver].[is_system],(0))) AND ([duration] >= (1000000))))
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
DROP TARGET package0.ring_buffer
GO
ALTER EVENT SESSION [ADS_Standard_Azure] ON DATABASE
ADD TARGET package0.ring_buffer(SET max_events_limit=(10),max_memory=(51200))
GO Efter att ha applicerat skriptet för att uppdatera XE-sessionen kommer brandslangen omedelbart att reduceras till en rännil:
Minskad nätverksträff efter uppdatering av ADS Profiler XE-sessionen
Ännu lättare viktalternativ
SQL Sentry och dess SaaS-motsvarighet SentryOne Monitor är de enda andra lösningarna jag känner till för att fånga frågor från Azure SQL Database, och de gör det med ett innovativt tillvägagångssätt som är betydligt lättare än den ovan optimerade XE-sessionen för ADS Profiler. Bland andra avancerade funktioner kan du enkelt aggregera efter klientens värdnamn, applikation och inloggning och automatiskt fånga frågeplaner för analys med den integrerade Plan Explorer.
SentryOne Monitor som visar infångade frågor och planer från Azure SQL Database
Stänger
Microsoft har sagt att de kommer att fortsätta att förbättra ADS Profiler-tillägget, och när de gör det hoppas jag att de kommer att ta itu med problemen som beskrivs ovan. Jag har loggat problemet här. Under tiden kommer det uppdaterade skriptet att ge en säkrare och mer bandbreddsvänlig frågeprofileringsupplevelse för Azure SQL Database.