MSSQL server + ADO = lahme Ente ????

[bernhard_LA]

wir haben eine Datenbank mit 1..5 Mio Elementen, die DB ist im wesentlichen eine Tabelle mit ein paar Feldern, eines davon ist ein TextFeld mit einer XML Datei in diesem Feld.
400.000 Datensätze in einer Query und dann jeweils die XML Datei auslesen dauert ca. 2 h.

Ich habe das ganze als DummyList(TObjectList) angelegt vergleichbare Daten in das TextFeld geschrieben und wieder ausgewertet. Zeitbedarf 1..10 sec.


Sehe ich hier nur den Unterschied MSSQL = Daten auf Festplatte mit Zugriffszeit = msec gegenüber TObjectList = Arbeitsspeicher = Zugriff im ~ GHz Bereich , oder hat hier ADO/MSSQL noch ein paar Performancebremsen im Angebot ???

Kann ich mit ADO / MSSQL die Daten irgendwie cachen im Arbeitsspeicher halten um Performance zu gewinnen ?
Datenvolumen ~ GBYTE ?

Würde gerne bei einer DB Lösung bleiben wegen MultiUser Zugriff, Netzwerkzugriff, ....

[shmia]

Also:
BLOB-Felder liegen in der Datenbankdatei an anderer Stelle als "normale" Felder (char, varchar,...).
Deshalb gibt es einen Performanceverlust wenn eine Tabelle BLOB-Felder enthält.
Nach meinen Messungen können das bis zu 30% Verlust sein.


Wenn du mit einer Abfrage quasi fast alle Daten einer Datenbank abrufst, dann sollte dem SQL-Server soviel RAM Speicher zur Verfügung stehen, wie die Datenbank auf der Platte benötigt.
Sollte die DB z.B. 7GB gross sein, der SQL Server hat aber nur 2GB RAM zur Verfügung,
dann ist das für deine Aufgabe ein Flaschenhals.

[Furtbichler]

Sag mal, ihr lest 1,5 Mio Datensätze inklusive XML-Dokument aus und schaufelt das in den Client? Was soll das denn?

Sag mal lieber, was Du bezwecken willst. Man sollte das mit einer Query im Server selbst erschlagen.

Ein RDBMS ist ein Spezialist für die Verwaltung von Tabellen, aber nicht sonderlich gut als Dateisystem. Für mich sieht das aber so aus (wegen dem XML-Zeugs).

[generic]

Wenn du das Borland ADO nimmt, ja das ist bekanntlich nicht das schnellst.
Native Ado geht erheblich schneller.

Andreas Kosch hat sich schon einige mal in seinen Büchern drüber ausgelassen.
Wobei eure Datenanzahl noch nicht besonders hoch ist.

Evtl. der SQL Server nicht optimal Eingerichtet?
Zu wenig Ram? Logfiles auf langsamen Platten?
Keine/Falsche Indizes/Statistiken?

SQL-Profiler laufen lassen um den Engpass ermitteln.

[Bernhard Geyer]

Zitat von generic:

Wenn du das Borland ADO nimmt, ja das ist bekanntlich nicht das schnellst.
Native Ado geht erheblich schneller.

Ist mir bisher eigentlich nur aufgefallen beim öffnen von vielen Recordsets mit wenige Ergebnisdatensätzen.
Dort wird immer versuch zu erkennen ob autoinc-Felder beteiligt sind.

Zitat von generic:

Evtl. der SQL Server nicht optimal Eingerichtet?
Zu wenig Ram? Logfiles auf langsamen Platten?
Keine/Falsche Indizes/Statistiken?

SQL-Profiler laufen lassen um den Engpass ermitteln.

Es gibt einiges wo man drehen könnte. Curserlocation wäre z.B. eine Option.

[bernhard_LA]

unter DELPHI XE2 haben dbgo (ADO) eingebaut, wenn wir uns die 400K Datensatze in einer query vom Server holen dauert dies ca. 10 min, das Durchlesen dann in einer Schleife mit TQuery.NEXT die besagenten 2 Stunden

[Bernhard Geyer]

Zitat von bernhard_LA:

unter DELPHI XE2 haben dbgo (ADO) eingebaut, wenn wir uns die 400K Datensatze in einer query vom Server holen dauert dies ca. 10 min, das Durchlesen dann in einer Schleife mit TQuery.NEXT die besagenten 2 Stunden

Stell mal Curserlocation auf clUseClient ein.

[Furtbichler]

Zitat von bernhard_LA:

das Durchlesen dann in einer Schleife mit TQuery.NEXT die besagenten 2 Stunden

1. Was macht die Schleife?
2. Verwendest Du "FieldByName", oder "DataSet['MyField']"?
3. Hast Du ein Grid angeschlossen oder andere datensensitive Elemente, TDBEdit o.ä.?
3. Eine ADO- oder was weiss ich- Tabelle ist nicht ideal, um über viele Datensätze zu iterieren.

Ich bin immer noch der Überzeugung, das Du mit einer Query bzw. eine UDF oder SP schneller zum Ziel kommst.

[p80286]

Zitat von bernhard_LA:

unter DELPHI XE2 haben dbgo (ADO) eingebaut, wenn wir uns die 400K Datensatze in einer query vom Server holen dauert dies ca. 10 min, das Durchlesen dann in einer Schleife mit TQuery.NEXT die besagenten 2 Stunden

Ich glaube da gibt es ein Mißverständnis. Nach dem "Open" trudelt der erste Datensatz ein.
Das ist ein Verhalten was ich auch bei anderen DBs beobachte, das Datenschieben über's Netz dauert. Du solltest ggf. mal die Datenmenge überprüfen.

Gruß
K-H

[Bernhard Geyer]

Zitat von p80286:

Ich glaube da gibt es ein Mißverständnis. Nach dem "Open" trudelt der erste Datensatz ein.
Das ist ein Verhalten was ich auch bei anderen DBs beobachte, das Datenschieben über's Netz dauert. Du solltest ggf. mal die Datenmenge überprüfen.

Trotzdem Stichwort CurserLocation:

clUseServer: Datensätze werden erst gefetcht wenn sie benötigt werden - Hohe serverbelastung
clUseClient: Mit dem öffnen werden alle Ergebnisdatensätze sofort um Client übertragen. währen der Durchiteration müssen diese nicht erst "Zeitaufwändig" immer wieder angefragt werden.

Solltest du die Datensätze nur zum exportieren (ohne Rückwärts-Positionierung) benötigen wäre auch ein Forward-Only-Curser sinnvoll.