FireDAC: Viele Records einfügen dauert ziemlich lange

[p80286]

Zitat:

Zitat von jobo (Beitrag 1323922)

... dann jenachdem möglichst selten commiten, am besten nur einmal am Ende.

das "am besten am Ende" kann auch kontraproduktiv sein.
Ich mache es so, daß alle 1000-2000 Datensätze ein Commit erfolgt. (Oracle, Erfahrungswert)
das ist aber wohl von der Datenbank abhängig.

Gruß
K-H

[Daniel]

Da könntest Du auch das ExecSQL der Connection nutzen. Wenn Dir das langt, sparst Du Dir die zusätzliche Komponente.

[Der schöne Günther]

Habe ich grade versucht, das spart auch etwas, ist aber kein bedeutender Unterschied. Zwei Sekunden für 20.000 Records ist immer noch ziemlich hart. Ich schaue mal ob ich mit dem Index irgendwie etwas machen kann...

[haentschman]

Zitat:

und es ist schon mal 50% schneller

...das meinte ich mit direktem SQL...:zwinker: Deine Anzahl an Inserts reicht an Masseninserts heran. Wieviele "Durchläufe" deiner 50000 Inserts sind im Laufe eines Jahres zu erwarten? Ggf. mußt du dir auch über die Datenmenge im Gesamten Gedanken machen...

[Sir Rufo]

Der Standardweg sollte immer so ablaufen:

Delphi-Quellcode:

Connection.StartTransaction;
try

  // Viele Datensätze einfügen
  for idx := 1 to 30000 do
  begin
    ...
    Connection.ExecSQL(sqlString, [param1, param2, param3]);
  end;

  Connection.Commit;
except
  Connection.Rollback;
  raise;
end;

Schneller sind dann nur noch BULK INSERTS

[Der schöne Günther]

Zitat:

Zitat von haentschman (Beitrag 1323937)

Wieviele "Durchläufe" deiner 50000 Inserts sind im Laufe eines Jahres zu erwarten?

Bis zu ein, zwei Dutzend täglich :cyclops:
Aber 50.000 ist ein Extremfall, ich rechne im Schnitt eher mit einem Zehntel der Menge.

Zitat:

Zitat von Sir Rufo (Beitrag 1323938)

Der Standardweg sollte immer so ablaufen:

Tut er :-)
Nur meine Advantage-Datenbank ist die lokale Freeware-Version und hat keine Transaktionen, da sind das nur leere Dummies. Der Monster-Zeitanteil geht wahrscheinlich tatsächlich dafür drauf dass er nach jedem Record schaut ob die referentielle Integrität beim FKEY noch gegeben ist. Würde er das einmal am Schluss machen wäre es bestimmt schneller. Ach ja ... :pale:

[jobo]

Zitat:

Zitat von Der schöne Günther (Beitrag 1323939)

dass er nach jedem Record schaut ob die referentielle Integrität beim FKEY noch gegeben ist. Würde er das einmal am Schluss machen wäre es bestimmt schneller. Ach ja ... :pale:

Jenachdem wie sehr diese freie DB kastriert ist, kannst Du auch die Constraints deaktivieren.
Da hier das Transaktionhandling abgeklemmt ist, kann ich mir grad spontan nicht vorstellen, wie das dann geht. Stichwort ist jedenfalls: "deferred constraint"
Notfalls kannst Du den Constraint auch droppen und wieder einfügen, genau wie den Index. Das müsste dann natürlich am besten nebenläufig erfolgen.
Oder Du nimmst eine freie DB, die nicht so ein Eunuch ist. ;)

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1323934)

Zitat:

Zitat von jobo (Beitrag 1323922)

... dann jenachdem möglichst selten commiten, am besten nur einmal am Ende.

das "am besten am Ende" kann auch kontraproduktiv sein.
Ich mache es so, daß alle 1000-2000 Datensätze ein Commit erfolgt. (Oracle, Erfahrungswert)
das ist aber wohl von der Datenbank abhängig.

Ja, kommt auf Rollbackmechanismen und Rollbackplatz an. Wenn man aus 50T commits eine Handvoll macht, sollte das schon spürbar sein.

[Bernhard Geyer]

Zitat:

Zitat von p80286 (Beitrag 1323934)

Zitat:

Zitat von jobo (Beitrag 1323922)

... dann jenachdem möglichst selten commiten, am besten nur einmal am Ende.

das "am besten am Ende" kann auch kontraproduktiv sein.
Ich mache es so, daß alle 1000-2000 Datensätze ein Commit erfolgt. (Oracle, Erfahrungswert)
das ist aber wohl von der Datenbank abhängig.

Tja. Das liebe Oracle. Hatten mal ein Oracle-Installation soweit in die Knie bekommen (mit einem Import) das sich selbst der Admin nicht mehr anmelden konnte.

Normalerweise sollte man bei einem Import der nur als ganzes gültig ist auch nur am Ende ein Commit machen.
In 2015 sollten selbst "schwachbrüstige" DB-Installationen problemlos Commits nach 100.000 Inserts verkraften.
Diese 1000-2000 Datensätze ist mehr oder minder ein fauler Kompromiss der aufgrund der schlecht Implementierung oder Konfiguration der DB geschuldet ist.
Letztendlich führt man mit so einem Commit die elementare Eigenschaft eines DBMS (ACID) ad absurdum.

[p80286]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1323984)

Diese 1000-2000 Datensätze ist mehr oder minder ein fauler Kompromiss der aufgrund der schlecht Implementierung oder Konfiguration der DB geschuldet ist.

Mach was, wenn Du nur "Kunde" bist. Irgendwann zuckst Du nur noch mit den Schultern und arrangierst Dich mit dem was die Fachleute verbrochen haben.

Gruß
K-H