Verwenden von SQL Profiler für eine Datenbank, die sich in der Produktion befindet

Als Entwickler benutze ich SQL Profiler ziemlich oft. Es ist ein gutes Debugging-Tool, um zu verfolgen, was mein Code tut, und um Leistungsprobleme zu analysieren.

Aber ich habe es immer in meiner Entwicklungsumgebung und auf sehr kontrollierte Weise verwendet.

• Starten Sie meine Anwendung und bringen Sie sie in einen bestimmten Zustand
• Starten Sie eine Ablaufverfolgung im Profiler
• Führen Sie eine bestimmte Abfolge von Aktionen für meine Anwendung aus
• Beenden Sie die Ablaufverfolgung und überprüfen Sie die Ergebnisse.

Kann der SQL Profiler praktisch in einer produktiven Umgebung eingesetzt werden?

Meine erste Sorge ist, dass es die Leistung verschlechtern würde.

Meine zweite Sorge ist, dass Sie die interessanten Aktionen nicht selbst auslösen, weil sie in Produktion sind. Sie müssten den Profiler längere Zeit laufen lassen und dann die Ergebnisse analysieren. Würde die Ergebnismenge zu unhandlich werden? (Verbraucht zu viel Speicherplatz und ist zu schwer abzufragen).

Verwendet jemand den SQL Profiler in der Produktion?

Die Verwendung von SQL Server Profiler (GUI-Tool) zum Nachverfolgen eines Produktionsservers ist keine gute Idee. Aber es kommt auf die Belastung an. Verwenden Sie stattdessen die serverseitige SQL-Ablaufverfolgung (siehe sp_trace_XXX- Prozeduren). Auch ich habe Artikel gefunden:

Performance Auswirkungen: Profiler Tracing vs. Server Side SQL Tracing ,

Automatisieren der serverseitigen Ablaufverfolgung in SQL Server

Vermeiden Sie Probleme mit dem Profiler

Vielleicht wird es interessiert und nützlich sein.

Online buchen sagt:

• Führen Sie Profiler remote statt direkt auf dem Server aus
• Vermeiden Sie das Einbeziehen von Ereignissen, die häufig auftreten (z. B. Sperre: Erworben), sofern dies nicht unbedingt erforderlich ist
• Schließen Sie nur die benötigten Ereignisklassen ein
• Geben Sie einschränkende Filter an, um die Anzahl der Ereignisse zu verringern
• Vermeiden Sie redundante Daten (zB SQL: BatchStarting und SQL: BatchCompleted)
• Vermeiden Sie es, mit Profiler große Traces zu erstellen. Ziehen Sie stattdessen einen serverseitigen SQL-Trace in Betracht
• Begrenzen Sie die Größe der serverseitigen Tracedatei und verwalten Sie die Speichernutzung

Ich benutze SQL Profiler die ganze Zeit gegen die Produktion. Bei korrekter Ausführung (Filtern, damit Sie eine sehr kleine Datenmenge zurückerhalten) auf einem Server ist das Risiko minimal. Alles aufzuspüren wäre nutzlos.

1. Ja, die Überwachung erfordert einige Ressourcen. Wenn Sie es auf einem überlasteten Server ausführen, wird es möglicherweise beendet.

2. Sie überwachen tatsächlich die tatsächliche Belastung: Ihre Aktionen können durch den Lärm dieser Belastung verloren gehen.

Wir lassen es manchmal auf Produktion laufen. Hauptsächlich mit einem Textfilter für bestimmten Code oder mit CPU / Duration-Filtern, um länger laufende Abfragen abzufangen. Und wir versuchen nicht, XML-Ausführungspläne oder ähnliches zu erfassen

Der Schlüssel ist zu wissen, wonach Sie suchen: Wir neigen nicht dazu, es laufen zu lassen und alles einzufangen.

Wenn Sie in diesem Fall die Ergebnisse einiger Aktionen sehen möchten, können Sie dies außerhalb der Geschäftszeiten tun?

Der Profiler wirkt sich immer auf die Leistung aus.

Wenn Sie SQL Server 2008R2 + verwenden, können Sie erweiterte Ereignisse verwenden. Dies liefert einen Großteil der Informationen, die Sie im Profiler sehen, mit einem Bruchteil der Leistungseinbußen.

Einführung in die Onlinedokumentation http://technet.microsoft.com/en-us/library/bb630354(v=sql.105).aspx

Diese Funktion wurde in SQL Server 2012 umfassend aktualisiert und enthält jetzt eine grafische Benutzeroberfläche in SSMS.