Firebird bei Masseninsert (DBPump) seeeehr langsam

[Lemmy]

Hallo,

bei einer Firebird-Anwendung werden Stammdaten bei den Kunden verteilt/aktualisiert, in dem die Stammdaten in einer eigenen fdb an die Kunden geliefert werden und diese Daten dann per DataPump (von UIB, das eigentlich verdammt schnell ist) in die andere DB übernommen.

Wir haben jetzt immer wieder den Fall, dass dieses Update sehr lange braucht, inzwischen auch einen Rechner bei uns im Haus. Da haben wir dann festgestellt, dass beim Schreiben der Daten diese mit ca. 400-500 kB/s auf die HDD tröpfeln (zippen einer größeren Datei läuft mit 8-10 MB/s, also ca. 20x schneller).

Das Verhalten lässt sich auf der Maschine unter Win7 und auch unter WIn XP (in einer virtuellen Maschine) reproduzieren.

Wir haben auf unseren Backup-Restore-Zyklus nach dem DataPump mal verzichtet um in eine schon große DB zu schreiben ob evtl. die Dateivergrößerung ne Rolle spielt, aber ohne Erfolg.

Definierte Indizes bei den betroffenen Tabellen spielen keine Rolle.

Ich bin mit meinem Latein jetzt am Ende. Hat mir jemand noch nen Tipp was wir probieren können? Ich will jetzt mal einen Masseninsert mit isql versuchen, um ein Problem der verwendeten Bibliotheken auszuschließen...

Grüße

[mkinzler]

-Alles in einer Transaktion?
-Gleichzeitig andere Vorgänge?
Ich hatte hier auch den Fall, dass es am Raid-Controller lag. Nach Bündelung von Schreibzugriffen wurde der Zugriff erheblich schneller.

[Lemmy]

Hi,

Transaktionsmanagement schließe ich jetzt einfach mal aus, weil es bei dem Großteil der eingesetzten Installationen kein Problem gibt. Ich schau aber mal nach, wie das UIB das intern macht.

Ob was anderes läuft... gut, Virenscanner wär noch ne Option das abzuschalten. Ansonsten: Da das Problem auf dem Rechner auf 2 Installationen (win 7 und XP) vergleichbar langsam abgeht hätte ich ein Hardwareproblem vermutet...

Wegen deinem Raid-Controller: Was meinst Du mit Bündelung der Schreibzugriffe?

Grüße

[tsteinmaurer]

Neben Transaktions-Handling, der Einsatz von Prepare Statement etc. wäre natürlich noch die Frage nach der Dateiendung der DB-Datei ein Schuss ins Blaue. .gdb (aus der alten InterBase Zeit) ist zum Beispiel keine gute Idee.

Das Non-Plus-Ultra in Bezug auf Import-Performance wäre natürlich der Weg über Firebird's EXTERNAL TABLE.

[Blup]

Wenn das bei vergleichbaren Installationen nur vereinzelt auftritt, denke ich zuerst an verweiste Transaktionen (der DB-Server hat den Verbindungsabbruch nicht bemerkt, älteste aktive Transaktion). Wenn so eine Transaktion über einige Stunden/Tage/Wochen weiter läuft, wird die Arbeit mit der Datenbank immer langsamer.
Vor solch einem Masseninsert/DataPump die Datenbank runterfahren und wieder hochfahren.

[Lemmy]

hi,

Danke für die Anregungen:

* Endung ist fdb
* verwaiste Transaktionen / Fehler im Management: Problem tritt auch mit einer neuen FDB auf (Backup/Restore)


@Thomas: External Table: wären die wirklich so viel schneller? Das wäre dann wirklich ein verdammt guter Ansatz. Anstelle einer fdb liefern wir ne handvoll external Tables aus, die wir dann nach belieben reinfüttern können.

Leider kann ich noch nichts über das Verhalten bei einem größeren SQL-Script schreiben, weil mir aktuelle Infos dazu fehlen...

Grüße

[Hansa]

Ja, external Table ist das schnellste, was es momentan gibt. Vor allem aber wird der komische Effekt wohl nicht mehr auftauchen. Hoffe es zumindest.

[nahpets]

Wir hatten mal das Problem, dass Datenbanken (diverser Hersteller) in virtuellen Maschinen deutlich langsamer waren, als auf "richtiger" Hardware.
Je mehr virtuelle Maschinen auf eine Hardware, um so langsamer.
Der Flaschenhals lag irgendwo in der "Kommunikation" zwischen virtueller Maschine und der Hardware.
Bei zu massiven Problemen blieb uns nur eine Lösung: Datenbank auf eigene Hardware ohne virtuelle Maschine.

Bei Windowssystemen war ein wesentliches Problem:

Wenn die virtuelle Maschine auslagert und das zu einer Auslagerung des Hostsystemes führt geht jede Hardware in die Knie, da dann die Festplattenzugriffe zum Engpass werden.

Tritt das Problem nur bei Systemen auf virtuellen Maschinen auf? Dann wäre das Problem eventuell in dem Bereich zu suchen.

[tsteinmaurer]

External Tables mußt du dir so vorstellen, dass du da alles auf den Server verlagern kannst und dadurch zum Beispiel das Firebird-Remoteprotokoll komplett eliminiert (gut, ein INSERT INTO oder SP-Aufruf wirst halt trotzdem wo, z.b. vom Client, triggern müssen) werden kann.

Dann macht man z.B. einfach etwas in der Form:

insert into real_table select * from external_table

und ab geht die Post. Wenn es nicht so einfach mit einem INSERT INTO geht, dann kann man natürlich auch eine SP darauf los lassen. Aber auch hier, die Sache läuft auf dem Server.

Schneller gehts ned.

Wichtig ist halt zu wissen, dass EXTERNAL TABLEs gewissen Restriktionen unterworfen sind, z.B. nur INSERT in eine EXTERNAL TABLE (ja, das geht auch!), keine Indizes, kein Transaktionsupport, keine BLOBs. Aber z.B. für einen Einweg-Import perfekt.

[Lemmy]

Zitat:

Zitat von nahpets (Beitrag 1202435)

Tritt das Problem nur bei Systemen auf virtuellen Maschinen auf? Dann wäre das Problem eventuell in dem Bereich zu suchen.

Nope, auf "normalen" Maschinen. Die VM haben wir nur zu Testzwecken eingesetzt ob es evtl. am Betriebssystem liegt...

Grüße