[MSSQL] Dauer/Laufzeitberechnung von Statements im Voraus!

[DeeJTwoK]

Hallo,
ich habe ein größeres Projekt für das ich die Laufzeiten von Statements im Voraus berechnen möchte. Die Statements werden über eine GUI zusammengeklickt und werden dadurch mitunter sehr komplex. Der User brauch daher eine grobe Zeitabschätzung über die Dauer, die er auf die Antwort warten muss. Sind es ein paar Sekunden, eine halbe Stunde oder doch eher ein paar Stunden.

Nun meine Frage:
Kennt jemand gute Quellen, mit deren Hilfe ich mich in das Thema einarbeiten könnte?
Alterativ würde ich natürlich hier eine kleine Diskussion anstoßen. Wovon hängt die Laufzeit eines Statements ab?

• Anzahl der JOINs
• Anzahl der unterschiedlichen beteiligten Tabellen
• Größe der beteiligten Tabellen
• Komplexität der WHERE-Bedingung ("id=5" oder eher "name LIKE '%foo%'")
• Indizes
• verwendete Hardware

Was wisst ihr noch, bzw. wie stark kann man die einzelnen Einflussfaktoren bewerten?

Über jede Hilfe dankbar,
Dominik

 

[Michael Engel]

• Anzahl der Benutzer die Anfragen durch die MySQL jagen

Generell lässt sich so etwas schwer vorhersagen, wenn sie die abfragen wiederholen, könntest du immer wenn du eine gemacht hast die Laufzeiten merken und durchschnittszahlen abspeichern wie lange sie dauerte. Wenn es jedesmal komplett verschiedene sind wüsste ich kaum einen weg das vorher auch nur halbwegs genau zu bestimmen.

 

[lmarkus31]

Hallo,

ganz unabhängig vom verwendeten RDBMS kann man sagen, dass es mehrere Einflussfaktoren gibt:

Anzahl der JOINs
Anzahl der unterschiedlichen beteiligten Tabellen
Größe der beteiligten Tabellen

Diese Faktoren spielen eine Rolle, wenn du aber von Abfragen redest, kommt es auch auf die Art der Verknüpfung (INNER JOINs, OUTER JOINs, Subquerys, Corelated Subquerys usw.) die Verteilung der Daten auf die einzelnen Tabellen, bei manchen RDB;S auf die Reihenfolge der Tabellen innerhalb der Abfrage und so weiter an.

Komplexität der WHERE-Bedingung ("id=5" oder eher "name LIKE '%foo%'")

Das kommt genauso auf das verwendete RDBMS an.
Wenn die Spalte "id" in deinem Falle nicht indiziert ist, kann die Abfrage durchaus länger benötigen, als eine Abfrage auf "name", die mit LIKE arbeitet, aber einen Index auf diese Spalte besitzt / nutzen kann.

Desweiten kann man sagen, dass ein Statement erstmal eine PARSE-Phase durchläuft, in der versucht wird zu ermitteln, welcher der optimale Zugriffpfad /-plan ist. Diesen kann man sich in den meisten RDBMS für eine Query anzeigen lassen.

ANALYSE QUERY
EXPLAIN <sql>
usw.

Indizes

Ja und nein.
Ob ein Index verwendet werden kann hängt nicht nur von seinem Vorhandensein ab. Es kann durchaus sein, dass das RDBMS entscheidet den Index nicht zu benutzen, da der Zugriffspfad über einen direkten Tabellenzugriff schneller ist.
Desweiteren kann es auch vorkommen, dass ein Statement zwar von einem Index profitieren würde, aber aufgrund einer nicht optimalen SQL-Query diesen nicht benutzt, was bei Indizes, die sich über mehrere Spalten erstrecken (Compound Index) häufiger vorkommen kann.

verwendete Hardware

Das stimmt natürlich, man kann aber ohne weiteres keine Angaben machen.
Klar ist, dass mehr RAM, mehr Harddisk und eine schnellere CPU sich in jedem Falle bemerkbar machen.
Pauschalisieren ist hier aber schwierig, da es von der Art der Datenbank und auch der Art der Anfragen, die an eine Datenbank gestellt werden, wie diese ausgestattet sein soll.

Mehr RAM = mehr Tabellenblöcke können im Speicher gehalten werden, mehr Sortieropertationen können im Speicher ausgeführt werden usw.

Mehr CPU = rechenintensive Operationen können schneller ausgeführt werden, dies betrifft im Speziellen Stored Procedures

Mehr / schnellere Harddisk / RAID-System = Antwortzeiten evtl. kürzer beim Zugriiff. Hier kommts auch wieder auf die Art der Datenbank an, ob das ganze Sinn macht.

Anzahl der Benutzer die Anfragen durch die MySQL jagen

Ja, kann ich voll zustimmen. Eine Datenbank ohne vernüftige Last zu testen/simulieren wird nie zeigen, wie sie sich beim Kunden verhält, nicht nur im Hinblick auf Performance, auch im Hinblick auf Locking-Probleme etc.

Ich hoffe das reicht als Einstieg und grober Überblick

Markus

 

[DeeJTwoK]

Super! Vielen Dank erstmal. Ich denke ich werde mich dann mal tiefer einarbeiten und ein paar Laufzeitmessungen vornehmen um herauszufinden, welche Faktoren wie stark Einfluss nehmen.
Es muss dazu auch irgendwelche Quellen im Internet geben. Kennt da niemand was?

Viele Grüße,
Dominik

 

[DeeJTwoK]

Also ich bin jetzt auf was gestoßen.
Mit SET SHOWPLAN_XML ON kann man sich den Ablaufplan eines Statements zurückgeben lassen:

Auszug:

<StmtSimple StatementText="SELECT * 
FROM ContactPerson
WHERE LocationID = '4';" StatementId="1" StatementCompId="1" StatementType="SELECT" StatementSubTreeCost="0.0033205" StatementEstRows="17.027" StatementOptmLevel="TRIVIAL">
          <StatementSetOptions QUOTED_IDENTIFIER="false" ARITHABORT="true" CONCAT_NULL_YIELDS_NULL="false" ANSI_NULLS="false" ANSI_PADDING="false" ANSI_WARNINGS="false" NUMERIC_ROUNDABORT="false" />
...
</StmtSimple>

Ich finde aber nirgends eine vernünftige Auflistung der Elemente und Attribute mit Beschreibung.
Ich denke besonders interessant hört sich hier StatementSubTreeCost an. Gibt dieses Attribut eine Zeit an, wie lange die Abfrage laufen wird (vielleicht in Sekunden) oder was sagt mir die Zahl 0.0033205?

Kennt sich jemand damit aus? Es würde mir natürlich auch ein Link reichen, am besten aus dem msdn-Bereich, auf dem ich mich selber schlau machen kann.

Das Prinzip ist mir klar:
http://msdn2.microsoft.com/de-de/library/ms187757.aspx

Nur was bedeuten die ganzen Werte? Das muss doch irgendwo dokumentiert sein!

Vielen Dank im Vorraus,
Dominik