Firebird geht in die Knie?

[Grünhage]

hallo,

in einer Umgebung wie folgt:

Firebird 1.5
Delphi 6.0
Win XP pro

soll eine ASCI-Datei eingelesen und interpretiert werden.
Vormals wurde dies mit einem Clientdataset auf xml- Ebene gemacht.
Die Performance war aktzeptabel, wenn auch nicht berauschend. Lag scheinbar an der Dateigrösse.
Jetzt wurde Interbase bemüht. Als Beispiel ist eine Datei mit ca. 50.000 Datensätzen einzulesen. Es wird direkt von der Platte gelesen (Textfile, readln). Nach 100 Datensätzen wird ein Commitretaining abgesetzt, nach 1000 Datensätzen ein Commit.
Bufferchunks wurden auf 1024 belassen.

Mit der Anzahl der eingelesenen Datensätze geht die Performance immer weiter zurück. Irgendwann scheint ein Buchhalter am Werk zu sein.

Ich glaube nicht, dass ich den Speicher mit dynamisch erzeugten Variablen (Stringlist, inifiel oder so) vollmülle. Es werden nur ganz normale Stringoperationen ausgeführt.

Hänge ich mehrer Dateien zusammen, kommt es irgendwann zu der Meldung 'Nicht genug Speicher'

Was läuft hier falsch. Könnt Ihr mir helfen?

Gruß

Peter

[Grünhage]

Hallo,

habe es rausgefunden:

Bufferchunks auf 10240
cached Updates auf true
commit nach je 1000 Datensätzen (der Sicherheit wegen)

Ist das so optimal?

Gruß

Pete

[Grünhage]

Hallo,

zu früh gefreut.
Mit chached Update ist zwar alles recht fix, aber keine Daten da.
ohne Cached Update wir Firebird nach ca. 3000 Datensätzen entsätzlich langsam.

Was mache ich bloß falsch?

Wäre toll wenn ihr helfen könntet!

Gruß

Pete

[Torsten Grundke]

Hallo Peter,

wie fügst Du denn die datensätze ein? Welche Komponente wird den verwendet?

Commitretaining würde ich gleich weglassen.

Torste

[Heiko Luettge]

Hallo,

1. wieviel Speicher zeigt denn der Taskmanager an ?
wer ist der, der den Speicher verbrät
FB oder dein Programm ?
2. Mache ein prepare vor dem Insert.

Heik

[Klemmo]

Moin,

wenn das schon als Textfile vorliegt, warum dann nicht per external file importieren und die string Operationen innerhalb einer Prozedur mit Udfs ausführen, geht erfahrungsgemäß 10-20 mal schneller als andere Importverfahren.

Gruß
Holger
www.ibexpert.co

[Grünhage]

Hallo beisammen,

nun tauche ich wieder aus meiner Verzweiflung auf.
Also
@ Thorsten
verwendet wurde die Komponete IBdataset, das Mitschreiben am Bildschirm wurde mit disabled unterbunden.

@Heiko
Definitiv verbrät Firebird den Speicher. Die Routinen sind 1:1 die gleichen wie vorher mit dem Clientdataset

@Holger
Das sind Weblogdateien. Furchtbare Zusammenstellung. Kann leioder nicht ausschließen, dass ich öfter an den Routinen ändern muß. Daher lieber in meinem Quelltext.

@All
Habe jetzt die Lösung gefunden:
Komponente IBSQL löst die Probleme. Blitzschnelles Einlesen (Schneller als vorher) und Speicher bleibt stabil.
Commitretaining war natürlich Quatsch, habe ja nix anzuzeigen.

Nehme jetzt für die Anzeigen IBQuery. Auch deutschlich schneller als das IBdataset.

Danke Euch für euer Interesse

[Thomas Steinmaurer]

Hallo Peter,
mit IBDataSet verwendest Du eine "Buffered" Komponente, die ganz allgemein gesprochen Overhead mitführt, um z.B. in einer Datenmenge vorwärts und rückwärts navigieren erlaubt (z.B. in einem Grid, ...). Wenn es sich um eine Aufgabe handelt, wo es nur um das Ausführen von puren DML (Delete, Insert, Update) Operationen geht, dann <b>immer</b> TIBSQL verwenden. Für Aufgaben, wo man eine Ergebnismenge vom Anfang bis zum Ende durchlaufen muss (z.B. Schleife oder für Reports, ...), dann sollte eine Komponente immer mit <b>UniDirectional := True</b> eingesetzt werden. Gerade Buffered Komponenten können beim Durchlaufen einer großen Datenmenge einiges an Speicher fressen, allerdings am Rechner, wo die Anwendung ausgeführt wurde.
<br>
Thoma

[Grünhage]

Hallo Thomas,

da ich lokal arbeite habe ich das auf Firebird geschoben.
Der Unterschied ist jedenfalls gewaltig.

Auch die IBQuery scheint weniger zu verbrauchen. Zum Darstellen von Readonly-Ergebnismengen wohl die beste Lösung.

Gruß

Pete

[Reich]

Hi,
ein typisches Problem von SQL-Datenbanken.
SQL arbeitet mengenorientiert. In eine große Menge Daten
Einzufügen oder anzuhängen dauert lange.
Deshalb mache ich immer zuerst einen select auf einen Datensatz,
den es nicht gibt. Dann ist die Tabelle, die erweitert werden soll
zunächst ganz klein (keine Datensatze).
Das Schreiben in eine Tabelle geht also viel schneller, wenn nach
dem Open ein select auf z.B. Lfd.Nr. -1 rausgeschickt wird.
Dadurch ist die geöffnete Tabelle zunächst leer. Danach können
Daten mit append oder insert angehängt oder eingefügt werden.
Nach dem Commit, der nach z.B. 1000 Einträgen erfolgt, wieder
einen Datensatz suchen, der nicht verfügbar ist (select Lfd.Nr. -1)
und wieder weiter in die Tabelle reinschreiben.
Dann geht die Post ab

[Heiko Luettge]

Hallo Reich,

das habe ich jetzt nicht verstanden,
was hat das Select mit dem "Tabelle klein zu tun".

Meinst du vielleicht das Verhalten der BDE,
nach einem Append die Daten vom Server wieder
komplett zu laden ?.

IBSQL macht wohl genau das nicht,
es dient in erster Linie dem Ausführen,
nicht dem Select.

Heik