SQL Server Performance

Hallo zusammen!
Gibt es hier SQL-Cracks?
Ich hab folgendes Problem: Ich habe ein LV-Programm geschrieben, mit dem man Daten aus einer großen SQL-Server Tabelle (Einige Millionen Datensätze) abfragen kann.
Die Abfrage sieht dann mit verschiedenen Filterkriterien ungefähr so aus:

SELECT p.PPunktNr, p.Beschreibung, g.Ist, p.Soll, p.MaxWert, p.MinWert, p.Toleranz, g.Status, g.GerNr, g.Pruefdatum, g.Pruefablauf, ge.GerTyp, ge.WMNr FROM tbl_Pruefpunkt p INNER JOIN tbl_Geraete ge INNER JOIN tbl_GerPruefPunkt g ON ge.GerTypIDCnt = g.GerID ON p.PPunktIDCnt = g.PPunktID WHERE g.PPunktID IN (1173) AND g.GerID = 109 AND g.Status != 0 AND g.Pruefablauf = 'Prüfung Produktion' ORDER BY p.PPunktNr, g.GerNr

Tabellen:
tbl_Pruefpunkt p enthält Stammdaten, ca. 2000 Datensätze
tbl_Geraete ge enthält Stammdaten, ca. 100 Datensätze
tbl_GerPruefPunkt g enthält Ergebnissdaten, mehrere Millionen Datensätze

weitere Infos:
SQL Server 2000
LV 2009
Verbindung mittels Microsoft Native Client 9 (per OLE)
Für SQL Kommunikation verwende ich das ADO TOOL von IBB:
http://forum.ib-berger.com/index.php?showforum=12

Folgendes Verhalten ergibt sich:
Frage ich Geräte ab, zu denen nur wenige Datensätze existieren (GerID), geht die Abfrage relativ schnell (z.B. 3 s, erneute Abfrage um Faktor 100 beschleunigt). Bei Geräten mit mehr Datensätzen (GerID=xy) verlangsamt sich das ganze dramatisch (z.b. 190s, erneute Abfrage genau so lahm).
Dabei ist egal, wie viele Datensätze tatsächlich übertragen werden. Scheinbar dauert das Erstellen eines Recordsets so lange. Das Auslesen der Zeilen mittels getRows geht dann schnell.Ist auch in diesem Bild ganz gut zu sehen:

   

Das Programm steckt sehr lange in dem linken Teil bis die Referenz auf ein recordset ausgegeben wird.
Frage ich Werte ohne joins direkt ab mit z.B.:

SELECT g.Ist, g.Status, g.GerNr, g.Pruefdatum, g.Pruefablauf FROM tbl_GerPruefPunkt g WHERE g.PPunktID IN (1173) AND g.GerID = 109 AND g.Status != 0 AND g.Pruefablauf = 'Prüfung Produktion' ORDER BY g.GerNr

geht das Ganze auch nicht schneller. Daher vermute ich mal, dass es nicht wirklich an der Art und Weise der Abfrage liegen kann. Vom Netzwerktraffic scheint es auch nicht wirklich abhängig zu sein, da das Holen von 200 Zeilen genau so lange dauert, wie das von 200.000 zeilen.
Gibt es eine Möglichkeit, das Erstellen eines Recordsets in der DB zu beschleunigen? Müssen da evtl. noch Indizes gesetzt werden etc...?

Ach ja: Frage ich per Eigenschaftsknoten die Einstellungen des Cursors ab ist dieser auf server, fast forward, read only eingestellt. Sollte eigentlich passen.

Irgendwelche Tipps?

Gruß,
Daniel

Anzeige

Du könntest mal schauen, wie lange es dauert, wenn du die Abfrage direkt auf dem SQL-Server machst.
(z.Bsp. mit dem SQL Server Management Studio)

ev. liegt es ja gar nicht an LabVIEW.

Da der Delay im Execute selber auftritt ist LabVIEW fast 100% sicher nicht daran beteiligt. Bleibt nur der SQL Server ADO Treiber oder die Datenbank selber.

Versuch mal die Idee von Role. Wenns da schnell geht dann wird's wohl der ADO Treiber und/oder die Netwerkverbindung zum Server sein. Ansonsten hast Du wohl eine SEHR komische Datentabellenstruktur die den SQL Server irgendwie ziemlich ausbremst.

Rolf Kalbermatter

OK, danke schon mal für die Antworten.

Dann werde ich mal einen Termin mit unserem SQL-Experten machen, wobei das mit dem immer etwas kompliziert ist...

@rolfk:
Mit ADO Treiber ist der client-seitige treiber gemeint? Da habe ich ja schon diverse ausprobiert (ODBC, SQL-Native mit ODBC oder OLE). Schließe ich weitgehend aus.
Zum Delay im Execute: Das findet doch bei server-seitigem Cursor direkt auf dem Server statt, oder nicht? Daher sollte doch die Netzwerkverbindung da keinen Einfluss mehr haben? Die Dauer der Anfrage ist ja auch völlig unabhängig von der Anzahl der zu holenden Zeilen. Es scheint vielmehr an der Anzahl der Zeilen zu liegen, die den Inner Joins mit den anderen Tabellen entsprechen.

Gruß,
Daniel

Ich dachte da schon daran um SQL Studio von einem anderen Computer aus zu gebrauchen. Auf der Maschine auf der der Server läuft misst Du wirklich nur die SQL Engine Performance alleine, was eventuel auch schon einige Indizien geben könnte aber auch einiges weglässt.

Rolf Kalbermatter

So hab´s jetzt herausgefunden. Das Problem lag daran, dass in der Ergebnistabelle die Spalte PPunktID nicht indiziert war. Das ist natürlich eines unserer Hauptsuchkriterien.
Nach Anlegen eines Index ist die Abfrage ca. um den Faktor 100 beschleunigt. Die Dauer einer Abfrage korreliert jetzt auch viel besser mit der Anzahl zu übertragender Datensätze.

Gruß,
Daniel

' schrieb:Nach Anlegen eines Index ist die Abfrage ca. um den Faktor 100 beschleunigt. Die Dauer einer Abfrage korreliert jetzt auch viel besser mit der Anzahl zu übertragender Datensätze.

du kannst das ganze höchstwahrscheinlich auch nochmal deutlich beschleunigen, in dem du die Abfrage als Stored Procedure im SQL-Server speicherst und die dann mit EXEC myStoredProcedureName(Parameter1, Parameter2, ...) aufrufst.

Ein Problem dürfte aber auch sein, dass für so große Abfragen erstmal massiv Speicher allociert werden muss. Ich würd mir mal überlegen, ob du das in einer Stored Procedure nicht noch optimieren kannst?

kann schonmal 2-3 Tage dauern eine SP performant zu programmieren, aber dafür hat man dann keinen Stress mehr in LV, und das beste daran ist: die Arbeit macht die SQL Engine und die ist schließlich dafür optimiert ...

Hmmm, ich verstehe jetzt aber nicht so ganz, wie mir eine SP dabei helfen soll, Abfragen zu beschleungigen? Im Endeffekt ist das doch nur eine Abfolge von Commands, oder nicht? Die Parameter bestimmen ja die Suche und die können sich jederzeit ändern. Verwende ich natürlich einen oder mehrere davon erneut, sind gewisse Dinge im Cache und werden schneller abgearbeitet.
Die SP kann doch aber nicht für alle möglichen Parameter zwischenspeicher anlegen. Könntest Du nochmal erklären, warum das Deiner Meinung nach mehr Speed geben sollte?