Wie bekomme ich einen performanten Firebird?

[Union]

Ich habe zum Test auf einem unserer Server Firebird als SuperClassic installiert. Um die Performance zu testen wollte ich aus einer anderen Datenbank Testdaten übertragen und dann einge Quälscripts laufen lassen.

Leider bin ich jetzt der Gequälte.

Nach der Anlage der Datenbank und Tabellen füge ich Testdaten per iSQL-Script hinzu. Die Laufzeit ist aber ziemlich unterirdisch. Für 100 Records werden ca. 3-5 Sekunden benötigt. Das ist meherere hundert Male langsamer als ich das von anderen DB-Servern kenne.

Was kann ich wo und wie drehen, damit die Performance besser wird? Systemauslastung ist bei unter 1%.

System:

Windows 2008 Server R2
2x Intel Xeon E6520 (zus. 16 Kerne)
24 GB Speicher

[mkinzler]

-Alle Inserts innerhalb einer Transaktion? Wie sieht das Skript aus (Insert, Insert or Update, Merge?)
-Werden mehrere Kerne verwendet? ( Parameter -m, AffinityMask)
-Aktive Trigger?

[Perlsau]

Ich mach das immer so:

1. Daten einer Firebird-Tabelle im IbExpert anzeigen lassen.
   
2. Links oben auf Tabelle/Exportiere Daten in Script
   
3. Felder und Dateiname auswählen und exportieren
   
4. Script in der Zieldatenbank laden und starten.

Schneller geht's nicht.

[mkinzler]

Zitat:

....Daten einer Firebird-Tabelle im IbExpert anzeigen lassen....

Es handelt sich wohl um Datn eines anderen DBMS.

[Union]

Das Script sieht so aus (mit 50000 inserts):

Code:

Insert into Bestand values(21654631, 23, '1918298', 23899, null, null, null, '20', '2020682276', 21649245, 747, 21649993, null, null, 'IT', '/', 'IT', 40.34, 'Ft', null, null, 147390, 2573092, null, null, null, '2008-06-12', '11:12:05', '2009-03-25', null, 6, 0, null, null);
Insert into Bestand values(22138465, 24, '2543234', 19510874, null, null, null, '0001', '7022371544', 22110364, 220, 22110386, null, null, 'CN', null, null, 0, null, null, null, 147390, 144627, null, null, null, '2009-03-25', '15:17:32', null, null, 2, 0.03696, null, null);
Insert into Bestand values(22156974, 23, '2577937', 64322, null, null, null, '20', '2020682334', 22128344, 399, 22128744, null, null, 'ES', '/', 'ES', 8.86, 'Ft', null, null, 69667, 105578, null, null, null, '2009-04-14', '15:59:51', null, null, 4, 0, null, null);
-- ... Alle 100 records ein commit:
commit;

Die Installation habe ich mit der Batchdatei aus dem Zipkit gemacht, ohne irgendwas zu ändern.

@perlsau: das insert script habe ich mit einem selbsterstellten tool aus einer Produktions-DB eines anderen DB-Servers generiert.

[mkinzler]

Gibt es aktive Trigger/Constraints?
Massenimport als externe Tabelle ist die schnellste Alternative

[Union]

Keine Trigger, keine Constraints, keine Relationen. Aber 8 Indizes:

Code:

CREATE INDEX "BESTAND_ID" ON BESTAND (ID);
CREATE INDEX "BESTAND_MAND_ID" ON BESTAND (MAND_ID, ART_ID);
CREATE INDEX "BESTAND_ART_ID" ON BESTAND (ART_ID, MAND_ID);
CREATE INDEX "BESTAND_ZUG_NR" ON BESTAND (ZUG_NR, MAND_ID, ART_ID);
CREATE INDEX "BESTAND_PAL_NR" ON BESTAND (MAND_ID, PAL_NR);
CREATE INDEX "BESTAND_FIFO" ON BESTAND (MAND_ID, ART_ID, ZUG_DAT, ZUG_ZEIT);
CREATE INDEX "BESTAND_PLATZ_ID" ON BESTAND (PLATZ_ID, ART_ID, ZUG_DAT);
CREATE INDEX "BESTAND_KUND_ID" ON BESTAND (KUNDE_ID);

[HHennig]

Schalte mal alle nicht absolut benötigten (alles ausser Primary Indices) aus. Massenimport und viele Indices ist ganz schlecht - bei jedem DBMS.

Edit: Nach beendetem Import dann alle vorher deaktivierten Indices neu aufbauen lassen.

[mkinzler]

Diese würde ich temporär deaktivieren

SQL-Code:

alter index <Indexname> inactive;

und am Ende neu berechnen lassen.

SQL-Code:

SET statistics INDEX <Indexname>;

[Union]

Klar dass ein Indexupdate Zeit braucht. Aber ein Durchsatz von nur 5 Records/s ist doch etwas fragwürdig. In der Zeit schreibe ich normalerweise ein komplette SAP-SHPORD mit mehreren 100 records. Und Massenupdates sind auch in der Produktion an der Tagesordnung, wenn Material Master Updates laufen. Da liegt die Geschwindigkeit bei > 1000 IDoc / min. inklusive Analyse.