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:

Zitat von generic (Beitrag 1149992)

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:

Zitat von generic (Beitrag 1149992)

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:

Zitat von bernhard_LA (Beitrag 1149997)

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:

Zitat von bernhard_LA (Beitrag 1149997)

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:

Zitat von bernhard_LA (Beitrag 1149997)

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:

Zitat von p80286 (Beitrag 1150042)

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.

[bernhard_LA]

wir haben eine TQuery mit 400K Elementen in der Ergebnismenge und eine Schleife

Delphi-Quellcode:

    


    Query.first

    
    Query.Next

      Zugiff auf die einzelnen Werte mit 
  
       Query.FieldByname( .....)


    until query.EOF

ist FieldbyName die Performance Bremse ?

[p80286]

Sollte man meinen, aber lt Hilfe ist dies nicht der Fall. Aus irgendwelchengründen ist das iterieren durch die Felder etwas langsamer.
Wie schon mehrmals angesprechen überprüf einmal die Cursor.
Je nachdem welche Datenbank im Hintergrund werkelt hat das einige Auswirkungen auf Geschw./Speicherverbrauch.

Gruß
K-H

[Iwo Asnet]

FieldByName sucht jedesmal in der Feldliste nach dem Feld mit dem Namen...

Führe die Analyse im Server aus oder schreibe dir eine extended stored procedure. Wenn das Resultat keine Riesenmengen sind, ist das in jedem Fall die bessere Wahl.

[einbeliebigername]

Hallo,

Zitat:

Zitat von bernhard_LA (Beitrag 1150089)

Delphi-Quellcode:

    


    Query.first

    
    Query.Next

      Zugiff auf die einzelnen Werte mit 
  
       Query.FieldByname( .....)


    until query.EOF

also

Delphi-Quellcode:

FieldByName

mit ein und derselben Spalte sollte man wirklich nicht innerhalb einer Schleife machen. Am besten zwischen Open und Close pro Spalte nur einmal

Delphi-Quellcode:

FieldByName

. Man kann ja nach dem Öffnen erst mal für jede Spalten, die man brauch,

Delphi-Quellcode:

FieldByName

aufrufen und das Ergebnis in einer Sinnvoll benannten Variable speichern und diese in der Schleife benutzen.

Und dann sag mal ist die Reihenfolge von First, Next, Zugriff und EOF wirklich so wie oben. Denn eigentlich müsste das so sein:

Delphi-Quellcode:

    Query.first
    while not Query.EOF do
    begin
      Zugriff auf die einzelnen Werte mit 
      QueryField.…
    
      Query.Next
    end;

einbeliebigername.