Verouderde functies om uit uw gereedschapskist te halen - Deel 2

In mijn laatste bericht heb ik één reden geïllustreerd waarom je zou moeten stoppen met het gebruik van verouderde systeemtabellen zoals sysprocesses . Dit was niet rechtstreeks om prestatieredenen, of om simpelweg de gedocumenteerde best practices van Microsoft te volgen, maar draaide meer om de beslissingen die u zou kunnen nemen als u slechts toegang heeft tot een deel van de gegevens.

Deze keer wil ik het hebben over een functie in SQL Server-clienthulpprogramma's die we tegenwoordig niet zouden moeten gebruiken - niet alleen omdat het verouderd is, maar, belangrijker nog, omdat het de potentie heeft om een ​​server volledig uit te schakelen:

SQL Server Profiler

Sinds SQL Server 2012 (en in veel mindere mate sinds SQL Server 2008) is Extended Events de meest complete en flexibele oplossing voor het bewaken van gebeurtenissen op een SQL Server-instantie. Aan de andere kant, sinds het voor het eerst werd uitgevonden (ongeveer rond de tijd dat ik mijn carrière begon), is SQL Server Profiler een van de meest productieve manieren geweest om een ​​server per ongeluk op de knieën te krijgen.

Niet zo lang geleden is ons zoiets overkomen. Een ontwikkelaar heeft een wijziging aangebracht in hun applicatie om het aantal retourvluchten te verminderen. Ze voerden de applicatie lokaal en in onze ontwikkelomgeving uit, gebruikmakend van Profiler met een gefilterde tracering, om te bevestigen dat hun wijzigingen werkten zoals verwacht. Ik wil u er op dit punt aan herinneren dat de officiële documentatie voor SQL Server Profiler de volgende waarschuwing bevat:

Hoe dan ook, toen ze de nieuwe versie van hun applicatie in productie brachten en zich met hetzelfde gefilterde spoor op de productieserver richtten, ging het niet zo goed. Hun wildcard-filter op applicatienaam hield geen rekening met de andere (gelijknamige) applicaties die ook verbinding maakten met deze server, en ze begonnen onmiddellijk veel meer informatie vast te leggen dan hun open Profiler-venster aankon. Dit resulteerde in een catastrofale stijging van de verbindingstijd voor alle gebruikers en applicaties die verbinding maakten met die instantie. Het zou een understatement zijn om te zeggen dat er klachten zijn ingediend.

Toen de boosdoener werd vastgesteld en we een reactie kregen van de ontwikkelaar, kun je zien dat de verbindingstijd bijna onmiddellijk weer normaal werd nadat ze hun Profiler-tracering hadden gestopt (klik om te vergroten):

Een miniramp met SQL Server Profiler

Dit is zeker een scenario waarin de oude "werkte op mijn machine"-statement op geen enkele manier betekent dat het goed zal werken op een drukke productieserver. En dit incident heeft geleid tot een actief gesprek over het wijzigen van de aanmeldingstrigger die al bestaat op alle servers in onze omgeving om eenvoudig de toepassingsnaam te blokkeren die Profiler in de verbindingsreeks doorgeeft.

Misschien is dit geen Profiler-probleem. (Maar dat is het eigenlijk wel.)

Ik ben hier niet om te suggereren dat andere monitoringtools, waaronder Extended Events, onmogelijk op ongepaste wijze kunnen worden gebruikt om een ​​server op een vergelijkbare (of slechtere!) manier uit de lucht te halen. Er zijn tal van mogelijkheden om per ongeluk een exemplaar van SQL Server te beïnvloeden, op zeer nadelige manieren, zonder SQL Server Profiler aan te raken.

Maar Profiler is berucht om dit soort symptomen vanwege de manier waarop het verbruikt gegevens. Het is een gebruikersinterface met een raster dat nieuwe rijen presenteert als het ze ontvangt; helaas laat het SQL Server wachten terwijl het ze weergeeft voordat SQL Server meer rijen kan verzenden. Dit gedrag is vergelijkbaar met hoe SQL Server Management Studio query's kan vertragen en hoge ASYNC_NETWORK_IO kan veroorzaken wacht terwijl het probeert een grote hoeveelheid uitvoer naar zijn eigen raster te renderen. Dat is een vereenvoudiging (en niet te verwarren met de manier waarop de onderliggende SQL Trace kan worden gemaakt om zich te gedragen, wat Greg Gonzalez (@SQLsensei) uitlegt in "Don't Fear the Trace"), maar het is precies wat leidt tot het type scenario dat hierboven wordt getoond:dat knelpunt heeft een trapsgewijze effect op alle andere processen die iets proberen te doen in hetzelfde codepad als wat u traceert (inclusief proberen een verbinding tot stand te brengen).

Bang voor langdurige evenementen?

Wees niet. Het wordt hoog tijd dat we Profiler allemaal afschaffen en het heden omarmen . Er is geen tekort aan tutorials en handleidingen, waaronder Microsoft's eigen QuickStart en verschillende artikelen hier op deze site.

Als je bestaande sporen hebt waarop je vertrouwt, heeft Jonathan Kehayias (@SQLPoolBoy) een heel handig script om een ​​bestaand spoor naar Extended Events te converteren. U kunt nog steeds gerust het originele spoor configureren met de gebruikersinterface van Profiler, als u zich daar het prettigst bij voelt; doe het alstublieft zonder verbinding te maken met een productieserver. Je kunt hier over dat script lezen en enkele van Jonathans andere Extended Events-artikelen hier bekijken.

Als je moeite hebt met de gebruikerservaring, ben je niet de enige, maar er zijn enkele antwoorden:

• Erin Stellato (@erinstellato) is al lang een spectaculaire pleitbezorger voor Extended Events en vraagt ​​zich vaak hardop af waarom mensen terughoudend zijn om Profiler en SQL Trace in het algemeen los te laten. Ze heeft enig inzicht (en inspireerde veel reacties) in haar post uit 2016, "Waarom vermijd je uitgebreide evenementen?"; misschien is daar enig inzicht in of je redenen om het uit te houden anno 2021 nog steeds (zoals) gelden.
  
• Er is een XEvent Profiler ingebouwd in moderne versies van SSMS, met een equivalente extensie voor Azure Data Studio. Maar verwarrend genoeg noemden ze deze extensie - van alle dingen die je je maar kunt voorstellen - SQL Server Profiler . Erin heeft ook een paar gedachten over die keuze.
  
• Erik Darling (@erikdarlingdata) heeft sp_HumanEvents gemaakt om een ​​deel van de pijn weg te nemen van het overschakelen naar Extended Events. Erik beschrijft sp_HumanEvents als volgt:"Als u een probleemloze manier wilt om querystatistieken te profileren, wachtstatistieken, blokkeren, compileren of opnieuw compileren met Extended Events, dan is dit uw eenhoorn."