SQL Abfragedauer messen - Ergebnis in eine Zeile

[Dukel]

Dann teste das erstmal unabhängig von der Applikation.
Führe die selbe Abfrage mit einem beliebigen SQL Client auf den unterschiedlich schnellen Clients aus.

 

[MDDaniel]

Warum ist das Ergebnis deiner Meinung nach nicht belastbar?

Weil zu viele Faktoren da rein spielen die du mit der Gesamtzeit nicht erkennen kannst.
z.B.
a) Serverauslastung insgesamt (CPU, RAM, Festplatte)
b) Umstände auf dem SQL (Last, Locks, Caching, etc)
c) Netzwerkauslastung insgesamt
d) Clientauslastung (CPU, ...)
e) Security (Verschlüsselungen, V-Scanner, etc.)
f) Ein Select top x einfach nichts über Performance aussagt

Die selbe Abfrage kann 3x hintereinander auf dem selben Server ausgeführt (und genau weil sie 3 hintereinander ausgeführt wurde), 3 recht unterschiedliche Laufzeiten aufweisen (+/- 30%).
Unterschiedliche Systeme an unterschiedlichen Orten mit unterschiedlicher Konfiguration werden immer unterschiedlich performen, das erscheint mir logisch und systemimmanent. Für eine aussagekräftige Analyse wirst andere Instrumente brauchen.
Überwachung des SQL-Servers (xEvents oder Profiler), Eventlogs, Performancemonitor, Netzwerküberwachung, Systemüberwachung auf den Clients.

 

[t-sql]

@MDDaniel
das ist richtig. Ich suche nach Flaschenhälsen.

Ich habe 4 verschiedene Server/Client Systeme an unterschiedlichen Standorten welche mal mehr und mal weniger gut performen.

Die Abfrage an den Servern ist meiner Meinung nach nur die halbe Wahrheit.
Da sehe ich zwar grob wie schnell der SQL ist aber nicht wie schnell die Daten vom Client gelesen/übertragen und angezeigt werden.

Das richtige Vorgehen ist wie folgt:

• Query auf dem SQL Server ausführen mit set statistics io, time on. Dann bekommst Du die IO Info und die Zeit Info auf dem Server. Dann weißt du wenigstens, ob deine Query schon auf dem Server lahm ist. Ist auch nicht grob sondern sehr genau. Machen mußt es halt nur. Und am besten zeigste da mal das Ergebnis.
• Wie sieht der Exectution Plan für die Query aus?
• Wie sieht die fragliche Query überhaupt aus?

Die selbe Abfrage kann 3x hintereinander auf dem selben Server ausgeführt (und genau weil sie 3 hintereinander ausgeführt wurde), 3 recht unterschiedliche Laufzeiten aufweisen (+/- 30%).

Eigentlich kann sie das nicht. Wenn das auf deinem System auftritt, dann haste da aber ein gewaltiges Performance Problem.

 

[MDDaniel]

Eigentlich kann sie das nicht. Wenn das auf deinem System auftritt, dann haste da aber ein gewaltiges Performance Problem.

Das wird sie schon auf Grund des Cachings. Je nach Umfang der Abfrage wird sie unterschiedlich lange brauchen.
(Und wenn ich von 3x hintereinander schreibe dann meine ich das auch genau so - GO 3)
Außer du leerst jedesmal den Cache mit einem DBCC Dropcleanbuffers & FreeProccache

Das richtige Vorgehen ist wie folgt:

• Query auf dem SQL Server ausführen mit set statistics io, time on. Dann bekommst Du die IO Info und die Zeit Info auf dem Server. Dann weißt du wenigstens, ob deine Query schon auf dem Server lahm ist. Ist auch nicht grob sondern sehr genau. Machen mußt es halt nur. Und am besten zeigste da mal das Ergebnis.
• Wie sieht der Exectution Plan für die Query aus?
• Wie sieht die fragliche Query überhaupt aus?

Wenn es sich um einzelne Abfragen handelt, ist dieses Vorgehen sicher empfehlenswert.

 

[Speedy18a4]

Moin zusammen,

dannke schonmal für eure Antworten. Ich würde testen wenn niemand/kaum niemand im System ist. So wie aktuell.

Ich mache eine ganz einfache Abfrage ohne Join etc

Select Top 1000000 * FROM RechnungsPositionen
Also einfach nur 1 Mio Datensätze der Rechnungspositionen.

So sehen die Zahlen im Management Studio aus. Direk am Server selbst.

System 1 = nicht genug Daten. 1.600MS für 150.000 Datensätze
System 2 = 20.240 MS
System 3 = 14.806 MS
System 4 = 38.703 MS


Somit bestätigt sich immerhin schonmal was mir die User auch berichten.
System 4 ist mit Absstand das langsamste.
System 3 ist das mit der aktuellsten/schnellsten Hardware.

Bedeutet also dass Performance Problem beginnt schon an den Servern selbst.
Dann brauche ich am Client gar nicht mehr messen.

Danke für eure Posts!

 

[MDDaniel]

Naja, das kann mehrere Ursachen haben:

A) Unterschiedliche Festplatten / RAM Konfiguration
B) Fragmentierte Daten(!)
C) Locking ist wahrscheinlich eher auszuschließen wenn du alleine auf den Systemen bist
D) Unterschiedliche andere Tätigkeiten der Systeme während der Abfrage , sprich Grundauslastung
E) Unterschiedliche Installation der Systeme

Hast du dir die Daten von Statistics IO angeschaut?
Da deine Rechner scheinbar nicht die selben Daten enthalten, bringt ein "SELECT *" auch eine unterschiedliche Menge an Daten zurück. Außer du hast lauter Felder die die gleichen fixen Inhaltsmengen haben, also keine VARCHAR oder nVARCHAR, MEMO oder so.

Das kann einen wesentlichen Einfluß darauf haben wie viele Sites der SQL Lesen muss.
Ein SELECT nur auf den PK würde zumindest diesen Effekt reduzieren.

Aja und zu deiner Frage:
Es bedeutet nur das sie unterschiedlich Schnell arbeiten - Kann einfach nur ein Unterschied in der Wartung des SQL sein.

 

[MDDaniel]

Etwas muss ich noch nachlegen, weil es sich für mich gerade in die Richtung entwickelt:

Aussagen wie: "Das System 4 ist das lahmste ... es muss an der Performance des Systems" liegen halte ich für sehr gefährlich.

Falls der Gedanke in die Richtung geht, besseres Equipment löst immer gleich das Problem. verläuft man sich gerne ganz schnell in eine Richtung.

Was man aufgrund deiner Abfrage sagen kann ist:
a) Das System 4 liefert die Daten nicht so schnell wie die anderen System. (mögliche Ursachen sind eh bereits im vorherigen Post)
b) Select Top 1000000 * FROM RechnungsPositionen <- solche Abfragen sind hoffentlich keine Abfragen wie sie im System vorkommen.
c) Auf der Suche nach dem Flaschenhals im Tagesgeschäft bleibt wahrscheinlich nur der Weg über eine vernünftige Analyse. Und da sind die Systeme 2 und 3 möglicherweise auch sehr aussagekräftig. Sonst kann es passieren das die System 2 + 3 auch bald langsam sind.

Falls der Gedanke ist: "Das System 4 ist das lahmste - schauen wir welche Mankos sich hier manifestieren und warum" dann wird das zu einer nachhaltigen Lösung beitragen.