Firebird Import aus Textdatei extrem langsam

[globetrotter77]

sehr schön, wenn auch unverständlich:
mit StartTransaction(TD) und Commit(TD) geht's plötzlich einigermaßen schnell.
Vorher ist allerdings noch
TD.TransactionID:=1;
erforderlich.
Ca. 105000 Datensätze in knapp 4 Minuten
Kein Vergleich mit dem Ergebnis von omata, aber immerhin.

Allerdings dauert danach ein Open eines ClientDataSets schlappe 15 (fünfzehn!) Minuten!!!

Abgesehen davon, dass es für mich nach wie vor unverständlich bleibt, wieso es
a) über ein ClientDataSet ewig lange dauert
b) mit Hilfe von SQLQuery nicht möglich ist bzw. unverständliche Fehlermeldungen liefert
ist es natürlich völlig unzumutbar für den User, nach dem Datenimport so lange zu warten, bis sich wieder was tut.

Wo ist denn hier der Fallstrick versteckt?
Ich kapiere es nicht mehr!
Wie gesagt - mit BDE und Interbase-Komponenten war das alles überhaupt kein Problem.
Wo kann ich denn bei den Einstellungen überhaupt so nen Bock schießen?
Ich gehe zumindest mal davon aus, dass ich ihn selber geschossen habe ...

[hoika]

Hallo,

benutzt du denn jetzt das hier ?

Delphi-Quellcode:

var 
  TD:TTransactionDesc; (aus DBXpress)
begin
  TD. // usw.

  SQLConnection.StartTransaction(TD);
  try
    SQLConnection.ExecuteDirect('INSERT INTO ...');
    SQLConnection.Commit(TD);
  except
    SQLConnection.Rollback(TD);
  end;
end;

Du musst das mit den Parametern und der Query hinbekommen.
Eine prepared Query ist etwa doppelt so schnell wie das da oben.

Man könnte auch noch folgendes machen:
- je nach 500 Datensätzen Commit/StartTransaction
- per Alter Index XXX Inactive alle nicht benötigten Indizes deaktivieren


Heiko

[mkinzler]

Oder alles in Kombination.

[globetrotter77]

Zitat von hoika:

Hallo,

benutzt du denn jetzt das hier ?

Delphi-Quellcode:

var 
  TD:TTransactionDesc; (aus DBXpress)
begin
  TD. // usw.

  SQLConnection.StartTransaction(TD);
  try
    SQLConnection.ExecuteDirect('INSERT INTO ...');
    SQLConnection.Commit(TD);
  except
    SQLConnection.Rollback(TD);
  end;
end;

Genau das benutze ich, allerdings zunächst mal nur in einer einzigen großen Transaktion.
Das werde ich noch abändern. Pro Datensatz ist allerdings auch zu langsam.

Zitat von hoika:

Du musst das mit den Parametern und der Query hinbekommen.
Eine prepared Query ist etwa doppelt so schnell wie das da oben.

Das würde ich gerne tun, aber mit SQLConnection.ExecuteDirect('INSERT INTO ...') habe ich doch gar keine Parameter zur Verfügung, oder?
Oder wäre es möglich, innerhalb von SQLConnection.StartTransaction und SQLConnection.Commit wieder auf SQLQuery-Methoden zurückzugreifen? (Mal abgesehen davon, dass die unbekannte Spalte angemeckert wird)

Zitat von hoika:

Man könnte auch noch folgendes machen:
- je nach 500 Datensätzen Commit/StartTransaction

das habe ich auf jeden Fall vor

Zitat von hoika:

- per Alter Index XXX Inactive alle nicht benötigten Indizes deaktivieren
Heiko

tja, leider habe ich schon alles soweit abgespeckt, dass nur noch ein PRIMARY KEY vorhanden ist, den ich auch brauche, weil mit doppelten Schlüsseln zu rechnen ist.

Leider hat das alles aber gar nichts damit zu tun, dass sich das System danach (!) völlig unzumutbar verhält.

[hoika]

Hallo,

Zitat:

danach unzumutbar verhält

Langsam ?

Was passiert, wenn du den Server-Dienst (FBGuardian) anhälst und neustartest ?
Ist es danach wieder "normal" schnell,
dann hast du eine offene Transaktion (also eine nicht comittete).

Zur Query.
Was war noch mal das Problem, nicht die SQLQuery zu benutzen ?
Wie weit warst du denn da schon.
Hast du noch den Quellcode davon (nicht nur die Splitter hier) ?


Heiko

[globetrotter77]

Zitat von hoika:

Hallo,

Zitat:

danach unzumutbar verhält

Langsam ?

gnadenlos langsam ... CLientDataSet.Active:=true ===> ca. 15 Minuten, bis es weitergeht

Zitat von hoika:

Was passiert, wenn du den Server-Dienst (FBGuardian) anhälst und neustartest ?
Ist es danach wieder "normal" schnell,
dann hast du eine offene Transaktion (also eine nicht comittete).

werde ich probieren, glaube aber nicht, dass es daran liegt

Zitat von hoika:

Zur Query.
Was war noch mal das Problem, nicht die SQLQuery zu benutzen ?
Wie weit warst du denn da schon.
Hast du noch den Quellcode davon (nicht nur die Splitter hier) ?

da bekam ich den Fehler "column unknown" an der Stelle, wo der Parameter angesprochen wurde - warum, weiß der Kuckuck!

den Quellcode habe ich mittlerweile so sehr gemetzelt, das er kaum noch zu erkennen ist, nur um die verschiedenen Vorschläge auszuprobieren.
ich habe den Eindruck, dass ich ein grundsätzliches Einstellungsproblem vorliegen habe, habe aber leider keine Ahnung, wo das liegen könnte.

was mir ohnehin nicht gefällt, ist die Verwendung der dbExpress-Komponenten (sind mir schon wegen der Unidirektionalität sehr suspekt), aber ich wüsste nicht, was ich sonst nehmen könnte.

wenn ich es richtig in Erinnerung habe, muss ich das ClientDataSet verwenden, um auch rückwärts gehen zu können, nicht wahr?

irgendwie zieht hier eine Krücke die nächste nach sich, und diese gleich noch mal eine usw. usw.

Was für Connection-Möglichkeiten gibt es denn sonst noch? und ist da auch was Empfehlenswertes dabei?

[nahpets]

Hallo,

wie wäre es mit den Zeos-Komponenten?

ein Tutorial
Die Komponenten zur ZeosLib

Tutorial zu ClientDataSet
Beim ClientDataSet darfst Du nicht vergessen, dass er die gesamten Daten im Arbeitsspeicher vorhält, Deine 100 und ein paartausend Sätze werden also erstmal in die Arbeitsspeicher geladen, ist das erforderlich, da ja offensichtlich eine ziemlich arge "Spassbremse".

[mkinzler]

Hierfür sollte auch IBX ausreichen

[hoika]

Hallo,

also hier

1

wird auf einen SQL-Monitor verwiesen.


Heiko

[globetrotter77]

Zitat von omata:

So, ich habe das jetzt mal selber ausprobiert...

Code:

1.000.000   Zeilen = 0:18 (Datei = 16MB)
1.000.000.0 Zeilen = 2:48 (Datei = 166MB)

Also für einen Datensatz ca. 18µs (auf meiner Maschine = P4, 3GHz)

da komme ich noch lange nicht ran ...
könntest du mir vielleicht mal verraten, welche Komponenten und Methoden du verwendet hast?
evtl. den Quelltext und/oder die Einstellungen im Object Inspector?
vielleicht komme ich dann dahinter, was ich falsch gemacht habe ...

wäre toll!

Edit:
hast du auch doppelte Primary Keys dabei?
die muss ich nämlich berücksichtigen