Veraltete Funktionen, die Sie aus Ihrer Toolbox herausnehmen sollten – Teil 2

In meinem letzten Beitrag habe ich einen Grund aufgezeigt, warum Sie aufhören sollten, veraltete Systemtabellen wie sysprocesses zu verwenden . Dies geschah nicht direkt aus Leistungsgründen oder um einfach den dokumentierten Best Practices von Microsoft zu folgen, sondern drehte sich mehr um die Entscheidungen, die Sie möglicherweise treffen, wenn Sie nur Zugriff auf einige der Daten haben.

Dieses Mal möchte ich über eine Funktion sprechen, die in SQL Server-Client-Tools enthalten ist und die wir heutzutage nicht mehr verwenden sollten – nicht nur, weil sie veraltet ist, sondern, was noch wichtiger ist, weil sie das Potenzial hat, einen Server vollständig herunterzufahren:

SQL Server Profiler

Seit SQL Server 2012 (und in viel geringerem Umfang seit SQL Server 2008) sind Extended Events die umfassendste und flexibelste Lösung für die Überwachung von Ereignissen auf einer SQL Server-Instanz. Auf der anderen Seite war der SQL Server Profiler seit seiner ersten Erfindung (ungefähr zu der Zeit, als ich meine Karriere begann) eine der produktivsten Möglichkeiten, einen Server versehentlich in die Knie zu zwingen.

Vor nicht allzu langer Zeit ist uns so etwas passiert. Ein Entwickler hat eine Änderung an seiner Anwendung vorgenommen, um die Anzahl der Roundtrips zu reduzieren. Sie haben die Anwendung lokal und in unserer Entwicklungsumgebung ausgeführt, indem sie Profiler mit einer gefilterten Ablaufverfolgung verwendet haben, um zu bestätigen, dass ihre Änderungen wie erwartet funktionieren. Lassen Sie mich Sie an dieser Stelle daran erinnern, dass die offizielle Dokumentation für SQL Server Profiler die folgende Warnung enthält:

Jedenfalls lief es nicht so gut, als sie die neue Version ihrer Anwendung in der Produktion bereitstellten und den Produktionsserver mit derselben gefilterten Ablaufverfolgung anvisierten. Ihr Wildcard-Filter für den Anwendungsnamen berücksichtigte nicht die anderen (ähnlich benannten) Anwendungen, die ebenfalls eine Verbindung zu diesem Server herstellten, und sie begannen sofort, viel mehr Informationen zu erfassen, als ihr geöffnetes Profiler-Fenster verarbeiten konnte. Dies führte zu einem katastrophalen Anstieg der Verbindungszeit für alle Benutzer und Anwendungen, die sich mit dieser Instanz verbinden. Es wäre eine Untertreibung zu sagen, dass Beschwerden eingereicht wurden.

Als der Übeltäter ermittelt wurde und wir eine Antwort vom Entwickler erhielten, können Sie sehen, dass sich die Verbindungszeit fast sofort wieder normalisierte, nachdem sie ihre Profiler-Verfolgung beendet hatten (zum Vergrößern klicken):

Ein Mini-Desaster von SQL Server Profiler

Dies ist definitiv ein Szenario, bei dem die alte Aussage „auf meinem Rechner funktioniert“ keineswegs bedeutet, dass es auf einem ausgelasteten Produktionsserver gut funktioniert. Und dieser Vorfall hat zu einer lebhaften Diskussion über die Änderung des Anmelde-Triggers geführt, der bereits auf allen Servern in unserer Umgebung vorhanden ist, um einfach den Anwendungsnamen zu blockieren, der vom Profiler in seiner Verbindungszeichenfolge übergeben wird.

Vielleicht ist das kein Profiler-Problem. (Aber irgendwie ist es das.)

Ich bin nicht hier, um vorzuschlagen, dass andere Überwachungstools, einschließlich Extended Events, möglicherweise nicht unangemessen verwendet werden können, um einen Server auf ähnliche (oder schlimmere!) Weise herunterzufahren. Es gibt viele Möglichkeiten, eine Instanz von SQL Server versehentlich auf wirklich nachteilige Weise zu beeinflussen, ohne den SQL Server Profiler zu berühren.

Aber Profiler ist berüchtigt für diese Art von Symptom wegen der Art und Weise, wie es verbraucht Daten. Es ist eine Benutzeroberfläche mit einem Raster, das neue Zeilen anzeigt, sobald es sie empfängt; Leider lässt es SQL Server warten, während es sie rendert, bevor es SQL Server erlaubt, weitere Zeilen zu übertragen. Dieses Verhalten ähnelt dem, wie SQL Server Management Studio Abfragen verlangsamen und hohe ASYNC_NETWORK_IO verursachen kann wartet, während es versucht, eine große Ausgabemenge an sein eigenes Grid zu rendern. Das ist eine Vereinfachung (und ist nicht zu verwechseln mit dem Verhalten des zugrunde liegenden SQL-Trace, das Greg Gonzalez (@SQLsensei) in „Don't Fear the Trace“ erklärt), aber genau das führt dazu die oben gezeigte Art von Szenario:Dieser Engpass hat einen kaskadierenden Effekt auf alle anderen Prozesse, die versuchen, irgendetwas im selben Codepfad wie das, was Sie verfolgen, zu tun (einschließlich des Versuchs, eine Verbindung herzustellen).

Angst vor längeren Ereignissen?

Sei nicht. Es ist höchste Zeit, dass wir alle Profiler loswerden und die Gegenwart annehmen . Es gibt keinen Mangel an Tutorials und Leitfäden, darunter Microsofts eigener QuickStart und mehrere Artikel direkt hier auf dieser Website.

Wenn Sie vorhandene Ablaufverfolgungen haben, auf die Sie sich verlassen können, hat Jonathan Kehayias (@SQLPoolBoy) ein wirklich praktisches Skript zum Konvertieren einer vorhandenen Ablaufverfolgung in erweiterte Ereignisse. Sie können die ursprüngliche Spur immer noch mit der Profiler-Benutzeroberfläche konfigurieren, wenn Sie sich dort am wohlsten fühlen. tun Sie es einfach, ohne sich mit einem Produktionsserver zu verbinden. Sie können über dieses Skript hier lesen und einige von Jonathans anderen Artikeln zu erweiterten Ereignissen hier sehen.

Wenn Sie Schwierigkeiten mit der Benutzererfahrung haben, sind Sie nicht allein, aber es gibt einige Antworten:

• Erin Stellato (@erinstellato) ist seit langem eine spektakuläre Verfechterin von Extended Events und fragt sich oft laut, warum die Leute nur ungern Profiler und SQL Trace im Allgemeinen loslassen. Sie hat einige Einblicke (und inspirierte viele Kommentare) in ihrem Beitrag von 2016, „Warum vermeiden Sie erweiterte Ereignisse?“; vielleicht gibt es dort ein wenig Aufschluss darüber, ob Ihre Gründe für das Durchhalten auch im Jahr 2021 noch (noch) gültig sind.
  
• In moderne Versionen von SSMS ist ein XEvent-Profiler integriert, mit einer entsprechenden Erweiterung für Azure Data Studio. Verwirrenderweise nannten sie diese Erweiterung – aus allem, was man sich nur vorstellen kann – SQL Server Profiler . Erin hat auch ein paar Gedanken zu dieser Wahl.
  
• Erik Darling (@erikdarlingdata) hat sp_HumanEvents erstellt um den Wechsel zu erweiterten Ereignissen etwas zu erleichtern. Erik, einer meiner liebsten „Bleib-bei-dem-Punkt“-Leute, beschreibt sp_HumanEvents wie folgt:"Wenn Sie Abfragemetriken, Wartestatistiken, Blockierungen, Kompilierungen oder Neukompilierungen mit erweiterten Ereignissen problemlos profilieren möchten, ist dies Ihr Einhorn."