SQL Server har altid givet muligheden for at fange live-forespørgsler på ad hoc-basis i et format, der er nemt at forbruge, - først med ældre SQL Server Profiler, senere via udvidede hændelser i SSMS. Denne egenskab er værdifuld ved ydelsesjustering, da forespørgselshændelser inkluderer diskrete CPU- og IO-metrikker samt runtime-parametre, som er nøglen til fejlfinding af forespørgselsydeevneproblemer såsom parametersniffing. Yderligere indeholder forespørgselshændelser andre vigtige elementer såsom klientens værtsnavn, applikationsnavn, login, Windows-proces-id osv.
Du kan altid hente samlet ydeevnemålinger for normaliseret forespørgsler fra DMV'er eller Query Store, men de indeholder kun kompilerede parametre og ingen af de førnævnte elementer. Selvom dette er nyttigt, er det ikke det samme. Hvis du f.eks. har brug for at se den specifikke parameterkombination, der blev brugt af den forespørgsel, der udførte 2 milliarder læsninger eller finde den mest CPU-forbrugende applikation i løbet af de sidste 24 timer, er du uheldig.
Azure SQL Database understøttes ikke af legacy Profiler, og Microsoft deaktiverede XEvents-streamingudbyderen (sys.fn_MSxe_read_event_stream TVF) af pålidelighedsgrunde, så du kan ikke oprette en XE-session og "se live data" med SSMS. Query Performance Insights i Azure Portal er understøttet af Query Store, så du igen kun har de normaliserede forespørgsler og aggregerede ydeevnedata, ikke de faktiske forespørgselshændelser.
Så i et par år sad vi fast – den eneste mulighed for at profilere Azure SQL Database var manuelt at oprette en XEvents-sporing, der skriver til en ringbuffer eller filmål med Azure Storage, hvoraf ingen af dem er optimale. Brug af ringbufferen med T-SQL-forespørgsler kan være problematisk på grund af den 4MB-formaterede XML-grænse, som er dækket af Jonathan Kehayias her, og filmål kræver en del hoop-jumping og ekstra omkostninger. Begge kræver manuel forespørgsel i XE-dataene og er derfor ikke ligefrem "live" i traditionel forstand.
Indtast Ny SQL Server Profiler
Da jeg hørte om SQL Server Profiler-udvidelsen til Azure Data Studio, var jeg glad for at se Microsoft endelig levere en grafisk løsning til live forespørgselsfangst på Azure SQL Database. Desværre var min begejstring kortvarig af et par grunde.
For det første er det frygtede "Standard"-spor fra legacy Profiler tilsyneladende blevet brugt som model for ADS Profiler XE-sessionen til Azure SQL Database , med navnet ADS_Standard_Azure som standard. (XE-sessionerne, der bruges til fuld SQL Server, ligner hinanden.) Som jeg bloggede for flere år siden og stadig tror, er Standard-sporingen en primær årsag til, at ældre Profiler er så dårligt anset. Det indeholder flere ubrugelige og ufiltrerbare hændelser såsom SQL batchstart , login og log ud , og som et resultat tilføjer det ingen reel værdi til ydelsesjustering. Ydermere, med den synkrone rækkesæt-sporingsarkitektur, der bruges af ældre Profiler, kan den høje hændelsesvolumen påvirke ydeevnen på travle systemer. Af en eller anden grund forsvinder denne ting ikke!
| |
| Legacy Profiler "Standard" sporingshændelser |
ADS Profiler "ADS_Standard_Azure" XE-begivenheder |
For det andet bruger den en ringebuffer med en maksimal størrelse på 8MB eller 1000 hændelser, alt efter hvad der kommer først. Fordi login/logout-begivenhederne er små, vil du ofte ramme 1000 hændelser længe før du når grænsen på 8 MB, eller endda den 4 MB formaterede XML-grænse. Men med en moderat blanding af SQL-hændelser vil ringbuffer-XML stadig være 2 til 3MB ved 1000 hændelser i min test, og problemet er, at hele denne buffer trækkes over netværket hver gang Profiler-udvidelsen poller for at opdatere dens gitter , som er den længste af hvert 1. sekund eller varigheden af den forrige afstemning. XML'en parses derefter på klientsiden af ADS Profiler-udvidelsen for at bestemme, hvilke hændelser der er nye siden sidste afstemning, og de nye hændelser føjes til gitteret.
Ringbufferen fyldes næsten øjeblikkeligt på selv en moderat travl server, og nettoeffekten er, at du hurtigt vil trække>40 megabit pr. sekund på tværs af netværket fra din Azure SQL-database . Dette svarer til 300 megabyte i minuttet eller 18 gigabyte i timen!
Netværkshit fra ADS Profiler-udvidelsen (4-minutters rækkevidde)
Min oprindelige frygt var, at dette kunne føre til enorme udgangsgebyrer på den næste Azure-regning, men ved at se på vores egne Azure-abonnementer var vi ikke i stand til at bekræfte, at netværkstrafik for Azure SQL DB er opkrævet. SentryOnes Mike Wood (b|t), en Azure MVP, brugte uger på at finde svaret og fik endelig besked fra Microsoft om, at der i øjeblikket ikke opkræves gebyr for netværksudgang for Azure SQL DB, selvom dette kunne ændre sig til enhver tid. Alligevel virker det ikke ansvarligt at trække 18 GB forespørgselsdata ned i timen, og det kan helt sikkert lægge en dæmper på din næste Netflix binge-watching-session.
Selvom du kan indstille filtre gennem Profiler-brugergrænsefladen, som vil gøre dataene nemmere at gennemse, vil det ikke reducere netværkshittet, da de opererer på klientsiden.
En opdateret XE-session
En hurtig løsning til at reducere netværksbyrden ved ADS Profiler og gøre dataene meget mere forbrugbare til justering af forespørgselsydeevne er at opdatere ADS_Standard_Azure XE session. Nedenfor er et script, der vil:
- Slet de ubrugelige begivenheder:
- sqlserver.attention
- sqlserver.existing_connection
- sqlserver.login
- sqlserver.logout
- sqlserver.sql_batch_starting
- Indstil en tærskel for varighed> 1 sekund (1000000 mikrosekunder) for de resterende hændelser:
- sqlserver.rpc_completed
- sqlserver.sql_batch_completed
- Reducer ringbufferens maksimale størrelse fra 1000 til 10 hændelser
- Dette ville aldrig fungere med det originale spor, da 10 hændelser vil blive genereret i millisekunder, og ringbufferen ville genvindes for hurtigt, hvilket medfører, at de fleste hændelser går tabt. Men med 1-sekunds varighedsfilteret vil hændelsesflowet være meget lavere, og 10 hændelser burde fungere godt med det 1-sekunds polling-interval, der bruges af 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 anvendelse af scriptet til at opdatere XE-sessionen, vil brandslangen øjeblikkeligt blive reduceret til en strøm:
Reduceret netværkshit efter opdatering af ADS Profiler XE-sessionen
Endnu lettere vægtalternativer
SQL Sentry og dets SaaS-modstykke SentryOne Monitor er de eneste andre løsninger, jeg kender til at fange forespørgsler fra Azure SQL Database, og de gør det ved hjælp af en innovativ tilgang, der er betydeligt lettere end den ovenstående optimerede XE-session til ADS Profiler. Blandt andre avancerede funktioner kan du nemt samle efter klientens værtsnavn, applikation og login og automatisk indfange forespørgselsplaner til analyse med den integrerede Plan Explorer.
SentryOne Monitor, der viser registrerede forespørgsler og planer fra Azure SQL Database
Lukker
Microsoft har udtalt, at de vil fortsætte med at forbedre ADS Profiler-udvidelsen, og når de gør det, håber jeg, at de vil løse de problemer, der er beskrevet ovenfor. Jeg har logget problemet her. I mellemtiden vil det opdaterede script give en sikrere og mere båndbreddevenlig forespørgselsprofileringsoplevelse for Azure SQL Database.