Warum wird BDE (mit Paradoxtabelle) immer langsamer

[Ferber]

Hi !
Habe nunmal diese Anwendung vor einiger Zeit mit Paradox angefangen ...
Nun tritt folgendes Phänomen ein, vielleicht weiss jemand warum und was dagegen tun.
Anwendung ist eine Client Server Anwendung die für Excel Daten zur Verfügung stellt.
Handelt sich um Artikelstammdaten, derzeit 206000 Datensätze am Server.
Datanormdateien werden in ExcelDateien importiert, dies geschieht auf der Clientseite,
geht schnell und ist eine gute Methode die Daten zu sichten, da oft Datenschrott geliefert wird.
Die Excelzeilen werden werden Clientseitig zu einem CSV-Strings gepackt, an die Serveranwendung geschickt, dort wieder entpackt,
und die Datensätze entweder aktualisiert oder angehängt.

Jetzt das eigentliche Mirakel.
Läuft wirklich schnell, aber nur bis etwa 4000 Datensätze, dann wird's so langsam,
dass für 60000 Datensätze mehr als eine Stunde benötigt wird.

Schnell wird's manchmal wieder nach einiger Zeit, auf allefälle nach einem Reboot des Servers.
Bin schon sehr verleitet die Datensätze mit Stream und Pointerlist zu verwalten.

Die Schnecke ist das Locate der BDE, aber warum

[Peter Piksa]

Hmm, ich bin zwar keine Leuchte was Delphi und BDE angeht (heute erst angefangen mit Delphi)
aber kann es vielleicht daran liegen, dass die verarbeitende Maschine hardwaretechnisch nicht genug auf den Rippen hat?
Vielleicht könnte da mehr RAM oder ne bessere CPU abhilfe schaffen.

Ich hatte sowas ähnliches mal als ich über ein PHP Script einige Millionen Datensätze in eine Mysql Dose rattern wollte.
Leider kam es nie dazu das System mit mehr RAM auszustatten. (hatte 256MB DDR). Wie sieht deine Maschine denn aus?

Gruss Peter

[SubData]

Wenn ich mich recht entsinne, dann liest Locate die komplette Tabelle und um so mehr Datensätze das sind um so mehr Speicher / Rechenleistung brauch die Kiste.

Also ich würde eher auf nen Software Fehler anstelle von einer langsamen BDE.

Ich arbeite gerade mit ner Paradox Datenbank die knapp 400 MB umfasst und selbst 50 MB Tabellen können in wenigen Sekunden ausgelesen werden (Nicht komplett, aber die entsprechenden Datensätze).

[r_kerber]

Moin,

ich muß gestehen, wenn ich Client-Server-Anwendung mit Paradox höre, dann stehen mir die Haare zu Berge. Paradox ist eindeutig eine Desktop-Datenbank und die BDE ist recht langsam. Bei "normalen" CS-Datenbanken werden die Abfragen von einem Server-Programm mit ausgeklügelten Such-Algorithmen ausgeführt und lediglich die Antwortmenge zum Cleient geliefert. Anders bei der BDE. Bei einem Locate werden alle(!) Datensätze zum Client übertragen und dann wird das Suchkriterium angewendet. Das bringt bei großen Datenmengen eindeutig Performance-Einbußen. Hinzu kommt, das es bei Paradox keinen vernünftigen Locking-Mechanismus (für den gleichzeitigen Zugriff mehrere Clients) gibt. Von Transaktionen brauchen wir gar nicht zu reden. Das führt dazu, daß die einzelnen Clients sich wesentlich gegenseitig behindern als vei echten CS-DB's.

[Ferber]

Die Kiste ist nicht so schlecht. 2,5GHz, 1GB Ram, Adaptec Raid 320!
Die Clients greifen via Typenbibliothek auf die Serveranwendung zu, die lokal und ganz alleine auf die Tabelle zugreift und die Einzelnen Datensätze oder auch nur Datenfelder an den Klient übermittelt.
Auch wenn's manchen die Zehennägel aufrollt, es gab schon Programme bevor es Provider und Clientdatenmengen gab, die wie r_kerber richtig meint,
das Netz überlasten würden. Transaktionen sind bei praktisch statischen Daten nicht erforderlich.
Werd mich wohl um eine ander Datenbank oder Lösung umsehen.

[SubData]

Na dann liegts definitiv an der Kiste, denn die Kiste mit der ich die 400 MB Datenbank anspreche hat gerade mal 1,1 GHz mit 320 MB RAM -g-

Da meine Software auf einer uralten Zeiterfassungsdatenbank aufsetzt (entstanden 1993 oder so), muss ich wohl oder übel Paradox verwenden bis die ganze Datenbankstruktur auf SQL umgestellt wurde. Aber auch sowas geht, wenn man nur richtig damit arbeitet und extrem auf Performance achtet und Indizes, Abfragen und Such-Algos so schreibt, dass sie wirklich nur das machen, was auch dringend gebraucht wird

[r_kerber]

Zitat von SubData:

Na dann liegts definitiv an der Kiste, denn die Kiste mit der ich die 400 MB Datenbank anspreche hat gerade mal 1,1 GHz mit 320 MB RAM -g-

Glaube ich eher weniger. Wenn das Programm auf dem Server liegt und auf Paradox zugreift, sollte das relativ fix gehen. Ich tippe da eher auf ungünstige Architektur in diesem programm selbst. Trotz alledem muß der Client die Daten über's Netz schieben (wenn ich das richtig sehe alle 200000). Und wird auf das Server-Programm auf von anderen Clients aus zuggegriffen? Dan sollte es natürlich Mulithreaded sein...

[SubData]

Oh ... verdammter Tippfehler

Ich wollte schreiben es liegt definitiv NICHT an der Kiste... Sorry

[MacNuke]

Der Server braucht bloß eine schnelle Festplatte und eine schnelle Netzwerkanbindung.

Alle Abfragen und Datenaktionen, werden bei Paradox-Anwendungen vom Client ausgeführt.

Softwareseitig wäre es vielleicht besser die Tabelle erst grob zu Filtern und dann mit einem locate zu suchen.

[trifid]

Ich würde auch mal einen Testen machen, ob es am Virenscanner leigen könnte.
Wie sind die Paradox-Parameter in der BDE eingestellt
(wie z.B. Blocksize, FILL FACTOR, MAXBUFSIZE, SHAREDMEMSIZE, etc.)
Gibt es Indizies auf den Tabellen.
Kann man diesen Effekt auf einen.
Wie sind die Lockingmechanismen am Server und am Client eingestellt?
(Stichwort opportunistisches Filelocking)
Warum verwendest du "locate" und kein ".gotokey".
Machst du etwas mit TQuery und SQL oder sind es reine TTable-Komponenten.
Wie verhält sich der Arbeitsspeicher am Server und am Client wenn du den Transfer startest.