Vor kurzem erfuhr ich mit etwas Überraschung, dass in einer der Abteilungen einer großen Firma, in der ich arbeite, die Ausführung von SQL Profiler während der Arbeitszeiten verboten ist.
Ich weiß nicht, wie sie es schaffen, Leistungsprobleme zu analysieren, die genau während der Arbeitszeiten auftreten. Schließlich geben die Performance-Views oft kein genaues Bild, besonders wenn eine oder zwei Prozeduren/Abfragen laufen, ohne den Server übermäßig zu belasten. Eine winzige Abfrage, die mehrmals pro Stunde ausgeführt wird und 10 Sekunden anstelle einer benötigt (aber etwas sehr Wichtiges für den Kunden sehr nervig) wird sicher nicht in den DMV-Views erfasst. Und ein Select mit CROSS APPLY über die Textabfragen belastet den Server erheblich.
Ich finde es jedoch interessant zu verstehen, woher diese Angst kommt. In einigen Firmen SQL Profiler ist es ein Arbeitswerkzeug, in anderen wird es wie Feuer gefürchtet (eine Zeit lang habe ich im Consulting gearbeitet und konnte vergleichen). Ich bin mir fast sicher, dass es so war:
Houston, wir haben ein Problem. Die Datenbank reagiert langsam. Kümmere dich darum.
Hier sind so viele Häkchen... Was brauche ich?
Na gut, ich setze alle Häkchen und entscheide dann.
Was bleibt im Kopf der oberen Leitung? Jemand hat es gestartet SQL Profiler und alles ist zum Stillstand gekommen. Und dann erzählen sie sich das beim Golfspiel.
Übrigens verleiht der Versuch, solche ‘wir schreiben alles’ Traces nicht in eine Datei, sondern in eine Datenbank auf demselben Server – einmal war ich Zeuge eines solchen Falls.
Wie laufen die Dinge bei Ihnen? Bitte beteiligen Sie sich an der Umfrage.
Nur registrierte Benutzer können an der Umfrage teilnehmen. .
Darf man bei Ihnen SQL Profiler in PROD ausführen?
Wir sind ein kleines Unternehmen, bei uns ist alles einfach.
Die Produktionsadmins dürfen es natürlich.
Die Produktionsadmins dürfen es nach Genehmigungen und heftigem Kopfnicken.
Heilig, heilig, heilig.
4 Nutzer haben abgestimmt. 3 Nutzer haben sich enthalten.
Quelle: habr.com
