Forældede funktioner til at tage ud af din værktøjskasse – Del 2

I mit sidste indlæg illustrerede jeg en grund til, at du bør stoppe med at bruge forældede systemtabeller som sysprocesses . Dette var ikke af præstationsmæssige årsager, direkte eller for blot at følge Microsofts dokumenterede bedste praksis, men drejede sig mere om de beslutninger, du måtte træffe, når du kun har adgang til nogle af dataene.

Denne gang vil jeg gerne tale om en funktion inkluderet i SQL Server-klientværktøjer, som vi ikke burde bruge i disse dage - ikke kun fordi den er forældet, men, endnu vigtigere, fordi den har potentialet til fuldstændig at fjerne en server:

SQL Server Profiler

Siden SQL Server 2012 (og i meget mindre grad siden SQL Server 2008) har den mest komplette og fleksible løsning til overvågning af hændelser på en SQL Server-instans været Extended Events. På den anden side, siden det først blev opfundet (omtrent lige omkring det tidspunkt, hvor jeg startede min karriere), har SQL Server Profiler været en af ​​de mest produktive måder til ved et uheld at bringe en server i knæ.

For ikke så længe siden skete noget som dette for os. En udvikler lavede en ændring af deres applikation for at reducere antallet af rundrejser, de foretog. De kørte applikationen lokalt og i vores udviklingsmiljø ved at bruge Profiler med et filtreret spor for at bekræfte, at deres ændringer fungerede som forventet. Lad mig på dette tidspunkt minde dig om, at den officielle dokumentation for SQL Server Profiler indeholder følgende advarsel:

I hvert fald, da de implementerede den nye version af deres applikation til produktion og målrettede produktionsserveren med det samme filtrerede spor, gik det ikke så godt. Deres jokertegn-filter på applikationsnavn tog ikke hensyn til de andre (tilsvarende navngivne) applikationer, der også oprettede forbindelse til denne server, og de begyndte straks at fange meget mere information, end deres åbne Profiler-vindue kunne håndtere. Dette resulterede i en katastrofal stigning i forbindelsestid for alle brugere og applikationer, der opretter forbindelse til den instans. Det ville være en underdrivelse at sige, at der blev indgivet klager.

Da den skyldige blev fastslået, og vi fik et svar fra udvikleren, kan du se, at forbindelsestiden faldt tilbage til normal næsten umiddelbart efter, at de stoppede deres Profiler-sporing (klik for at forstørre):

En SQL Server Profiler-minikatastrofe

Dette er helt sikkert et scenarie, hvor den gamle "arbejdede på min maskine"-erklæring ikke på nogen måde betyder, at den vil fungere godt på en travl produktionsserver. Og denne hændelse har ført til en aktiv samtale omkring ændring af logon-triggeren, der allerede findes på tværs af alle serverne i vores miljø, for blot at blokere applikationsnavnet, Profiler passerer i sin forbindelsesstreng.

Måske er dette ikke et Profiler-problem. (Men det er det sådan set.)

Jeg er ikke her for at foreslå, at andre overvågningsværktøjer, inklusive udvidede begivenheder, umuligt kan bruges uhensigtsmæssigt til at bringe en server ned på en lignende (eller værre!) måde. Der er masser af muligheder for utilsigtet at påvirke en forekomst af SQL Server på virkelig ugunstige måder uden at røre ved SQL Server Profiler.

Men Profiler er berygtet for denne type symptomer på grund af den måde, den forbruger på data. Det er en brugergrænseflade med et gitter, der præsenterer nye rækker, efterhånden som den modtager dem; Desværre får det SQL Server til at vente, mens det gengiver dem, før det tillader SQL Server at transmittere flere rækker. Denne adfærd ligner, hvordan SQL Server Management Studio kan bremse forespørgsler og forårsage høj ASYNC_NETWORK_IO venter, mens den forsøger at levere en stor mængde output til sit eget net. Det er en forenkling (og skal ikke forveksles med den måde, den underliggende SQL Trace kan fås til at opføre sig på, hvilket Greg Gonzalez (@SQLsensei) forklarer i "Don't Fear the Trace"), men det er præcis det, der fører til den type scenarie vist ovenfor:den flaskehals har en kaskadeeffekt på alle andre processer, der forsøger at gøre noget i den samme kodesti som det, du sporer (inklusive forsøg på at etablere en forbindelse).

Brygt for forlængede begivenheder?

Vær det ikke. Det er på høje tid, at vi alle dropper Profiler og omfavner nutiden . Der er ingen mangel på tutorials og guider derude, inklusive Microsofts egen QuickStart og adskillige artikler lige her på denne side.

Hvis du har eksisterende spor, du stoler på, har Jonathan Kehayias (@SQLPoolBoy) et virkelig praktisk script til at konvertere et eksisterende spor til udvidede begivenheder. Du kan stadig være velkommen til at konfigurere det originale spor med Profiler UI, hvis det er der, du er mest komfortabel; Bare gør det uden at oprette forbindelse til en produktionsserver. Du kan læse om det script her og se nogle af Jonathans andre Extended Events-artikler her.

Hvis du har det svært med brugeroplevelsen, er du ikke alene, men der er nogle svar:

• Erin Stellato (@erinstellato) har længe været en spektakulær fortaler for Extended Events, og undrer sig ofte højt over, hvorfor folk er tilbageholdende med at give slip på Profiler og SQL Trace generelt. Hun har en vis indsigt (og inspireret til en masse kommentarer) i hendes indlæg fra 2016, "Hvorfor undgår DU udvidede arrangementer?"; måske er der en vis indsigt der i, om dine grunde til at holde ud stadig (som) er gyldige i 2021.
  
• Der er en XEvent Profiler indbygget i moderne versioner af SSMS med en tilsvarende udvidelse til Azure Data Studio. Selvom de til forveksling kaldte denne udvidelse – af alle de ting, man overhovedet kunne forestille sig – SQL Server Profiler . Erin har også et par tanker om det valg.
  
• Erik Darling (@erikdarlingdata) har oprettet sp_HumanEvents at tage noget af smerten ud af at skifte til udvidede begivenheder. En af mine yndlings "hold til sagen"-folk, Erik beskriver sp_HumanEvents som følger:"Hvis du vil have en smertefri måde at profilere forespørgselsmetrics, ventestatistikker, blokering, kompilering eller genkompilere med udvidede begivenheder, er dette din enhjørning."