SQL-Performanceeinbruch bei SELECT

[alzaimar]

Hallo Leute,

Vielen Dank für die vielen Ideen. Ich habe aus der View nun eine Funktion gemacht, die die Ergebnistabelle sukkessive füllt. Zunächst werden die Daten der [order]-Tabelle sowie der direkt mit ihr verbundenen Detailtabellen in das Resultat geschrieben. Das dauert ca. 1 Sekunde. Lustigeweise sind die anschließenden Aktionen (also z.B. die 7 Left Joins mit den OrderPriceParameter) in 200ms durch, ebenso das Auffüllen der 7 Adressen (OrderAddress join Address). Insgesamt braucht die Funktion somit ca. 3 Sekunden.

Der Speicherbedarf des Servers liegt bei ca. 600MB, sodaß die 1GB RAM ruhig aufgestockt werden könnten.

@omata: Dein Vorschlag bringt auch nichts.

Zu MySQL: Erstmal haben wir eine DB im Einsatz, da kann man ja wohl schlecht das DBMS mal eben austauschen. Und soweit

Kann es sein, das MSSQL hier wirklich an seine Grenzen stößt?

[omata]

Zitat von alzaimar:

@omata: Dein Vorschlag bringt auch nichts.

Schade, einen Versuch war es wert.

Zitat von alzaimar:

Kann es sein, das MSSQL hier wirklich an seine Grenzen stößt?

Die Frage sollte wohl eher lauten: Benutze ich wirklich die Richtige Technik für das was ich machen möchte?
Für statistische Auswertungen gibt es die OLAP-Technik. Diese ist dafür da der Geschäftsleitung Daten für Ihre Statistiken zu liefern. Diese Analyse-Services sind für große Datenmengen ausgelegt und sorgen für eine schnelle Antwortzeit. Allerdings werden die Daten in solch einem Data-Warehouse mehrdimensional abgelegt und deshalb muss das dann auch eine sehr gute Hardware sein (grosse Platte + schnelle CPU). Man kann auch nicht mal so eben ein ganzes Data-Warehouse hochziehen. Trotzdem solltest du dir die Fragen stellen ob du eventuell in der Zukunft noch mehr und noch komplere Fragestellungen beantworten musst. Dann könnte vielleicht die OLAP-Technik bei euch sinn machen.

Schau dir doch einfach mal die SQL Server Analyse Services an. Sind auf der CD von SQL-Server mit drauf. Einfach installieren und mal probieren (vergiss aber nicht das Service Pack 4 einzuspielen, sonst geht nichts)

Gruss
Thorsten

[mkinzler]

Bei OLAP-Datenbanken hat man meistens keine Datensatz-orientierte sondern eine Spalten-orientierente Speicherung, deshalb ist damit eine derartige Fragestellung besser zu beantworten

[Elvis]

Zitat von alzaimar:

Kann es sein, das MSSQL hier wirklich an seine Grenzen stößt?

Naja, meine persönliche Meinung von dieser alten windows-only Sybase-version mit dem MS-Stempel mal außen vorgelassen:
Nur weil etwas geht, muss man es nicht immer unbedingt auch machen.
Dein SQL ließe sich wunderbar in 2 Statements aufteilen: dem Hauptteil ohne OrderPricemodelparameter und einem normalen Select, dass alle verknüpften DS aus OrderPricemodelparameter liefert.
Das 2. Statement wird "prepared" so dass du ein vorkompiliertes Handle darauf bekommst.
Dann Tun weitere Calls auch nicht so weh.
Wenn SQLs zu komplex werden, fangen auch die "großen" DBMS an Mist zu bauen, besonders wenn Sortierungen im Spiel sind...

[alzaimar]

Es geht hier doch nicht um Datenmassen, die aggregiert werden müssen, um der Geschäftsleitung die Statistiken der letzten Jahrhunderte so zu präsentieren, das selbst sie es verstehen. Es handelt sich um eine normale Tabelle, bei der einfach nur ein paar Daten zusammengesucht werden.

Was mich immer wieder entäuscht, ist die Tatsache, das ein eigentlich sauberes SQL-Statement aus einem Ferrari einen Eselskarren macht. Die Engine klappert nur ein paar Indexe ab, und müsste die Abfrage eigentlich in wesentlich kürzerer Zeit abarbeiten: Die View an sich ist ja sehr groß, aber die WHERE-Klausel limitiert die zu verknüpfenden Datensätze (aus der [Order]-Tabelle) schon auf das Endresultat. Da hier ein Index ansetzt (sieht man im Execution Plan), müsste die Engine nur die paar 1000 Records abklappern und über die Verknüpfungen die restlichen Daten zusammensuchen. Laut Execution Plan macht sie das auch. Nur eben in 30-40 Sekunden.

Prinzipiell sieht die vom Client generierte Abfrage so aus:

Select [bla] from View_Orders where [Einschränkungen für die Order-Tabelle] and [Einschränkungen der verknüpften Felder] Bei den 'Einschränkungen für die Order-Tabelle' handelt es sich um ein Zeitfenster sowie noch ein paar Dinge ('Alle vermittelten Aufträge von Gestern'), die dann bestimmten Filterkriterien (z.B. Kundenname enthält 'umpitz') entsprechen. Mit diesem Wissen kann ich dann die erwähnte Funktion schreiben, die mir dann die fertige Tabelle zusammenbastelt. Zunächst erstellt sie eine Tabelle, die alle Records mit den 'Einschränkungen für die Order-Tabelle' enhält. Dann wird sie befüllt und abschließend werden die Daten gefiltert.
Befriedigend ist das aber nicht, weil nicht allgemeingültig.

Es ist wirklich bedauerlich, wie schnell man in die Trickkiste greifen muss.

@omata: Mit OLAP habe ich mich noch nie beschäftigt, werde ich mich aber mal schlau machen.

Also nochmals Dank an alle Mitdenkenden: Ich probiere heute noch mal ein paar Tricks aus.

[hoika]

Hallo,

wie ein left join intern abgearbeitet wird,
weisst du aber ?
Da kann man nicht einfach "ein paar Indizes" abklappern.
Packe doch mal in einer Test-DB für jedes deiner left joins
einen Eintrag in die Tabelle
und ändere dann in einen inner join.


Heiko

[alzaimar]

Hi hoika,

Leider kann man nur an 1-2 Stellen das LEFT JOIN durch ein INNER JOIN ersetzen.

Wenn ich aber testweise ein SELECT einmal mit LEFT JOIN und einmal mit JOIN durchlaufen lasse, dann ist sowohl der Query plan als auch die verwendete Zeit identisch. Deshalb behaupte ich weiterhin, das ein LEFT JOIN auch nur ein paar Indexe abklappert. Ehrlich gesagt war ich auch der Überzeugung, das ein LEFT JOIN länger dauert. Bis ich das mal durchgetestet habe und keine Verbesserung beobachten konnte.

Ich versuche gerade, dem Query-Optimizer und der Engine die Sache zu vereinfachen, indem ich meine Funktion noch weiter verbessere: Derzeit werden alle Aufträge innerhalb des Zeitraums generiert, zum Client geschaufelt und dort (mit einem TcxGrid von DevExpress) gefiltert. Das geht viel schneller, als dieses blöde 'SELECT * From View_Orders', ist aber trotzdem nicht perfekt. Und vor Allen Dingen ist es doch krank, erstmal 4MB Daten zu verschicken, nur um im Client eine Zeile darzustellen.

[hoika]

Hallo,

also ich weiss zumindestens unter Firebird,
das left outer joins lahm sind.
Im Netz steht dazu, dass left outer joins eines der
kostenintensivsten Statements sind.

Als eine Lösung war eben angegeben, (inner) joins drauszumachen,
indem Dummy-Einträge in den gejointen Tabellen eingetragen werden.
Wenn einem Auftrag eine Rechnung zugeordnet werden kann,
wird beim Auftragsanlegen eine Dummyrechnung (alle Felder NULL),
angelegt, die kann dann einfach gejoint werden.
Beim Anlegen der 1. Rechnung muss natürlich diese Dummy-Rechnung verschwinden.

Ich habe in unserem Programm auch so ne "Auftragsübersicht".
Dort habe ich mich um das Dummy gedrückt
und habe die eine Query auseinandergenommen und pro Left Join
eine eigene Query gemacht.
Der Code bastelt daraus dann wieder ein Grid (über eigene Klasen/Listen).

Performance um 1000% hochgegangen.

Das Problem war, mit ein paar Daten merkst du keine Unterschied.

"Fully populate your database", heisst es ja so schön.


Eine andere Lösung wäre eine Stored Procedure
mit mehreren for/select


Heiko

[alzaimar]

Heiko, danke. Ich versuch's einfach mal.