Firebird Import aus Textdatei extrem langsam

[mkinzler]

Was soll dann geschehen ( bei doppelten PKs)?

[hoika]

Hallo,

die doppelten sollen doch ignoriert werden (?).

3 Fragen an den Thread-Ersteller:
- Server und Client auf der gleichen Maschine oder 2 Rechner ?
- Version der fbclient.dll stimmt mit Server über ein ?
Welche Version genau ?
- Welche Datenstruktur hat die Tabelle ?

Sonderpreis-Frage:
Mal den Virenscanner deaktiviert ?


Heiko

[mkinzler]

Überschreiben wäre natürlich einfacher ( update or insert into .... )

[muenster]

Die Erfahrung der langsamen Transaktion habe ich auch.

Im Grunde nutze ich einen öhnlichen Code um aus der BDE die Daten in Firebird zu migriren.
Allerdings verwende ich die IBDAC.
Da ich die BDE Tabellen zerlegen muss, sind mehrere Aufrufe über TQuery notwendig um die jeweiligen Firebird Tabellen zu füllen. Am Ende des "Umbaus" steht ein INSERT INTO der mit Parametern gefüllt wird. Und die Performance ist ähnlich schlecht wie beschrieben. Das Ganze läuft bei mit komplett lokal.

Es liegt somit die Vermutung nah, dass das Absetzen einzelner Datensätze die Performance des lokalen Firebirdserver ziemlich ausbremst.

Wenn ich den Thread hier richtig verstehe, kann über die Transaktionskontrolle das Absetzen mehrerer Statements gebündelt werden. Ist es richtig, dass SQL.Text mehr als ein INSERT Statement enthalten darf?

[mkinzler]

Nein, ein normaler Query nimmt immer nur ein Statement auf. Es gibt aber in jeder Komponentensammlung auch eine skript-Komponente. Explizite Transaktionssteuerung bedeutet, dass kein Autocommit, nach jedem Insert ausgeführt wird, sondern dass dieser manuell erfolgt. Bei einzelnen Inserts ( unprepared; ohne Parameter) muss zusätzlich für jeden Insert ein Plan gebildet werden. Die Kombination von parametrisierten Abfragen mit Transaktionssteuerung sollte deshlab einiges bringen. Zudem könnte man überlegen die Dupletten vorher aus zu sortieren.

[muenster]

Danke, ist aber genau das was ich befürchtet hatte.
Doppelte Datensätze gibt es nicht, ich muss nur häufiger durch die Tabellen um diese in neue Häppchen zu zerlegen. Wenn man schon migriert, dann kann man ja auch gleich das Design überarbeiten.

[mkinzler]

Ich würde, wie gesagt prepared Queries verwenden. Man könnte sich auch überlegen für diesen Fall ein SP zu nehmen

Zitat:

Wenn man schon migriert, dann kann man ja auch gleich das Design überarbeiten.

Macht auf jeden Fall Sinn

[nahpets]

Hallo,

Zitat von muenster:

Wenn ich den Thread hier richtig verstehe, kann über die Transaktionskontrolle das Absetzen mehrerer Statements gebündelt werden. Ist es richtig, dass SQL.Text mehr als ein INSERT Statement enthalten darf?

Jain, es kommt auf die Datenbank an.

Bei einem ähnlichen Problem mit 'nem SQL-Server bin ich hergegangen und habe 100 Inserts in einer Stringliste gesammelt und dann zusammen einer TAdoQuery zugewiesen und gemeinsam per ExecSQL ausgeführt. Das funktioniert, jedes Statement muss dann aber mit einem Semikolon enden. Es ist zumindest mal einen Versuch wert, ob Firebird damit auch zurecht kommt. So könnte man dann eben 100 (oder so) Statements in eine Transaktion packen. Bei meinem Rechner und der benutzen Datenbank habe ich mit 100er-Schritten das beste Ergebnis erhalten, bei weniger Inserts, wurde es deutlich langsamer, bei mehr musste ich mit Timeouts rechnen.

[hoika]

Hallo,

Zitat:

ich muss nur häufiger durch die Tabellen um diese in neue Häppchen zu zerlegen. Wenn man schon migriert, dann kann man ja auch gleich das Design überarbeiten.

Und dafür werden hoffentlich mind. prepared Queries benutzt ?

Ist denn der Häppchen-Code wirklich so kompliziert,
dass er nicht in eine SP passt ?


Heiko

[muenster]

Zitat von hoika:

Und dafür werden hoffentlich mind. prepared Queries benutzt ?

Ist denn der Häppchen-Code wirklich so kompliziert,
dass er nicht in eine SP passt ?

Keine prepared Queries weil das Ganze nur einmal läuft.

Schön wär's wenn es in eine SP passen würde. Leider sind Ergänzungen und/oder Zerlegungen drin. Für eine Einmalige Umstellung viel zu aufwendig.

Gruß Karsten