it-swarm-eu.dev

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

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

Aber ich habe es immer bei mir benutzt entwicklung Umwelt und auf sehr kontrollierte Weise.

  • 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
  • Stoppen Sie die Ablaufverfolgung und überprüfen Sie die Ergebnisse.

Kann der SQL Profiler praktisch in einer Produktionsumgebung verwendet werden?

Meine erste Sorge ist, dass dies die Leistung beeinträchtigen würde.

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

Verwendet jemand den SQL Profiler in der Produktion?

sql-serverprofiler
28
Andrew Shepherd

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

Auswirkungen auf die Leistung: Profiler-Tracing vs. serverseitige 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 es, häufig auftretende Ereignisse (z. B. Sperren: Erworben) einzuschließen, sofern dies nicht unbedingt erforderlich ist
  • Schließen Sie nur die erforderlichen Ereignisklassen ein
  • Geben Sie Begrenzungsfilter an, um die Anzahl der Ereignisse zu verringern
  • Vermeiden Sie redundante Daten (z. B. SQL: BatchStarting und SQL: BatchCompleted).
  • Vermeiden Sie es, mit Profiler große Traces auszuführen. Betrachten Sie stattdessen einen serverseitigen SQL-Trace
  • Begrenzen Sie die Größe der serverseitigen Tracedatei und verwalten Sie die Speicherplatznutzung
19
garik

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.

21
mrdenny

  1. Ja, für die Überwachung sind einige Ressourcen erforderlich. Wenn Sie es auf einem überlasteten Server ausführen, kann es zerstört werden.

  2. Sie überwachen tatsächlich die reale Last: Ihre Aktionen können durch das Geräusch dieser Last verloren gehen.

Wir betreiben es manchmal in der Produktion. Hauptsächlich mit einem Textfilter für bestimmten Code oder mit CPU-/Dauerfiltern, um länger laufende Abfragen abzufangen. Und wir versuchen nicht, XML-Ausführungspläne oder solche Fehler zu erfassen

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

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

7
gbn

Der Profiler führt immer eine Auswirkung auf die Leistung ein.

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 des Leistungseinbruchs.

Online-Einführung in Bücher 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.

2
James Anderson