Föråldrade funktioner att ta ur din verktygslåda – Del 2

I mitt förra inlägg illustrerade jag en anledning till att du bör sluta använda föråldrade systemtabeller som sysprocesses . Detta var inte av prestandaskäl, direkt, eller för att helt enkelt följa Microsofts dokumenterade bästa praxis, utan kretsade mer kring de beslut du kan fatta när du bara har tillgång till en del av datan.

Den här gången vill jag prata om en funktion som ingår i SQL Server-klientverktyg som vi inte borde använda nuförtiden – inte bara för att den är utfasad utan, ännu viktigare, för att den har potential att helt ta ner en server:

SQL Server Profiler

Sedan SQL Server 2012 (och, i mycket mindre utsträckning, sedan SQL Server 2008) har den mest kompletta och flexibla lösningen för att övervaka händelser på en SQL Server-instans varit Extended Events. Å andra sidan, sedan den först uppfanns (ungefär precis när jag började min karriär), har SQL Server Profiler varit ett av de mest produktiva sätten att av misstag få en server på knä.

För inte så länge sedan hände något sådant här oss. En utvecklare gjorde en ändring i sin applikation för att minska antalet tur- och returresor de gjorde. De körde applikationen lokalt och i vår utvecklingsmiljö, med hjälp av Profiler med ett filtrerat spår, för att bekräfta att deras ändringar fungerade som förväntat. Låt mig nu påminna dig om att den officiella dokumentationen för SQL Server Profiler innehåller följande varning:

Hur som helst, när de distribuerade den nya versionen av sin applikation till produktion och riktade in sig på produktionsservern med samma filtrerade spår, gick det inte så bra. Deras jokerteckenfilter på applikationsnamn tog inte hänsyn till de andra (liknande namngivna) applikationerna som också ansluter till denna server, och de började genast fånga mycket mer information än deras öppna Profiler-fönster kunde hantera. Detta resulterade i en katastrofal ökning av anslutningstiden för alla användare och applikationer som ansluter till den instansen. Det skulle vara en underdrift att säga att klagomål har lämnats in.

När den skyldige fastställdes, och vi fick ett svar från utvecklaren, kan du se att anslutningstiden gick tillbaka till det normala nästan omedelbart efter att de stoppade sin Profiler-spårning (klicka för att förstora):

En SQL Server Profiler-minikatastrof

Detta är definitivt ett scenario där det gamla "arbetade på min maskin"-satsen inte på något sätt betyder att det kommer att fungera bra på en upptagen produktionsserver. Och den här incidenten har lett till en aktiv konversation kring att ändra inloggningsutlösaren som redan finns på alla servrar i vår miljö för att helt enkelt blockera applikationsnamnet Profiler skickar i sin anslutningssträng.

Det här kanske inte är ett Profiler-problem. (Men det är det liksom.)

Jag är inte här för att föreslå att andra övervakningsverktyg, inklusive Extended Events, omöjligt kan användas på ett olämpligt sätt för att få ner en server på ett liknande (eller värre!) sätt. Det finns gott om möjligheter att oavsiktligt påverka en instans av SQL Server, på riktigt ogynnsamma sätt, utan att röra SQL Server Profiler.

Men Profiler är ökänt för den här typen av symptom på grund av hur det konsumerar data. Det är ett användargränssnitt med ett rutnät som presenterar nya rader när det tar emot dem; Tyvärr får det SQL Server att vänta medan det renderar dem innan det tillåter SQL Server att överföra fler rader. Det här beteendet liknar hur SQL Server Management Studio kan sakta ner frågor och orsaka höga ASYNC_NETWORK_IO väntar medan den försöker återge en stor mängd utdata till sitt eget nät. Det är en förenkling (och ska inte förväxlas med hur den underliggande SQL Trace kan fås att bete sig, vilket Greg Gonzalez (@SQLsensei) förklarar i "Don't Fear the Trace"), men det är precis vad som leder till den typ av scenario som visas ovan:den flaskhalsen har en kaskadeffekt på alla andra processer som försöker göra något i samma kodsökväg som det du spårar (inklusive försök att upprätta en anslutning).

Rädd för utökade evenemang?

Var inte det. Det är hög tid att vi alla lämnar Profiler och omfamnar nuet . Det finns ingen brist på tutorials och guider där ute, inklusive Microsofts egen QuickStart och flera artiklar här på den här webbplatsen.

Om du har befintliga spår du litar på, har Jonathan Kehayias (@SQLPoolBoy) ett riktigt praktiskt skript för att konvertera en befintlig spårning till utökade händelser. Du kan fortfarande gärna konfigurera det ursprungliga spåret med Profiler UI, om det är där du är mest bekväm; bara gör det utan att ansluta till en produktionsserver. Du kan läsa om det manuset här och se några av Jonathans andra artiklar om Extended Events här.

Om du har svårt med användarupplevelsen är du inte ensam, men det finns några svar:

• Erin Stellato (@erinstellato) har länge varit en spektakulär förespråkare för Extended Events, och undrar ofta högt varför folk är ovilliga att släppa taget om Profiler och SQL Trace i allmänhet. Hon har en viss insikt (och inspirerade till många kommentarer) i sitt inlägg från 2016, "Varför undviker DU utökade evenemang?"; kanske finns det någon insikt där om huruvida dina skäl för att avstå fortfarande (som) är giltiga 2021.
  
• Det finns en XEvent Profiler inbyggd i moderna versioner av SSMS, med ett motsvarande tillägg för Azure Data Studio. Även om de, förvirrande nog, kallade denna förlängning – av allt man kan tänka sig – SQL Server Profiler . Erin har också några tankar om det valet.
  
• Erik Darling (@erikdarlingdata) har skapat sp_HumanEvents för att ta bort en del av smärtan av att byta till Extended Events. En av mina favorit "stick to the point"-människor, Erik beskriver sp_HumanEvents enligt följande:"Om du vill ha ett smärtfritt sätt att profilera frågestatistik, väntestatistik, blockering, kompilering eller omkompilering med utökade händelser, är det här din enhörning."