Firebird und Interbase auf gleichen Rechner?

[Bernd Wurm]

Hallo Firebirdexperten,

ich würde gern FB 1.5 testen, habe meine ganzen Entwicklungen aber bisher mit IB 6 gemacht. Funktioniert es beide Server auf den Recher zu installieren. Ich arbeiten mit Win2000.

Gruß Bernd

[Torsten Grundke]

Hallo Bernd,

lt. Release Notes funktioniert das.

Gruß

Torste

[Bernd Wurm]

Hallo Torsten,

danke für die schnelle Antwort. Ich habe jetzt FB 1.5 installiert und den Dienst gestartet. Mit gbak habe ich mir aus einer IB 6 Datenbank mit Restore ein FB 1.5 Datenbank aufgebaut. Das hat alles geklappt. Mit IBExpert kann ich auch problemlos auf die Daten zugreifen. Ich kann sogar den Interbaseserver und den Firebirdserver parallel laufen lassen. Nur mit Delphi 7 bekomme ich weder mit IBX noch mit IBO ein Verbindung zu Datenbank. Es kommt bei IBO folgender Fehler:
<PRE>
ISC ERROR CODE:335544375

ISC ERROR MESSAGE:
unavailable database
</PRE>
Ich habe dazu den Dienst des Interbaseservers angehalten.

Was mache ich Falsch?

Gruß bern

[Torsten Grundke]

Hallo Bernd,

funktioniert der Zugriff auf Interbase?

Es könnte daran liegen das die falsche Version der gds32.dll verwendet wird. Auf deinem Rechner wird es eine gds32.dll für Firebird und eine für Interbase geben. Zum Test würde ich mal die IB-Version der gds32.dll entsorgen/umbenennen.

Wenn Du die Sourcen von IBO zur Verfügung hast, dann kannst Du auch die Clientbibliothek von "gds32.dll" auf "fbclient.dll" ändern. Allerdings bist Du dann auf Firebird festgelegt.

Eine weitere möglichkeit ist die Verwendung unterschiedlicher Ports für Firebird/Interbase. Bei Firebird kann man den verwendeten Port in der datei Firebird.conf einstellen. Bei Abweichung vom Standardport 3050 muß der zu verwendende Port auch im Connection-String mit angegeben werden.

Gruß

Torste

[Bernd Wurm]

Hallo Torsten,

ich hatte bei dem ersten Versuch nur die gds32.dll gewechselt und nicht die fbclient.dll mit in den Windossystemordner mit kopiert. Daran hat es wahrscheinlich gelegen. Jetzt klappt alles.

Ich bin gerade dabei ein allgemeines Objekt für den Datenzugriff zu schreiben, kann darin über Parameter die verschiedenen Datenzugriffskomponenten (IBX, IBO später auch ADO) nutzen und habe einige Performancetests gemacht. Dazu importiere ich einige hundert Datensätze (Artikelstammdaten) in die Datenbank. Die SQL - Scripts sind durch das Objekt immer die gleichen. Mein Ergebnis ist, dass tatsächlich IBO ca. 40% schneller ist als IBX. Den Test habe ich für Interbase und für Firebird 1.5 durchgeführt. Hier habe ich aber festgestellt, dass entgegen meinen Erwartungen Firebird beim Datenimport geringfügig langsamer ist. Nun habe ich gelesen, dass Firebird 1.5 eigentlich wesentlich schneller sein soll. Nun die Frage: Wo kann Firebird seine Geschwindigkeitsvorteile ausspielen oder wo gibt es eventuell noch etwas einzustellen?

Gruß Bernd

[Torsten Grundke]

Hallo Bernd,

persönlich sind mir bisher nur erhebliche Performanceverbeserungen bei Abfragen aufgefallen. Insert und Update habe ich nicht getestet.

Zur Beschleunigung von Insert's kann man eventuell Indices und Trigger's vorübergehend deaktivieren. Eventuell hilft auch die Verlagerung des Insert's in eine SP.

Gruß

Torste

[Bernd Wurm]

Hallo Torsten,

unschlagbare Werte beim Datenimport habe ich ja bisher nur mit External Files gehabt. Hier gab es nur das Problem, dass eine Datei die einmal von Datenbankserver verwendet wurde, exklusiv gesperrt wurde. Man bekam nur mit einigen Tricks neue Daten in diese Files hinein. Die Dateien werden erst nach einem shutdown des Servers wieder freigegeben, was im Netzwerk nicht immer unbedingt möglich ist. Ein weiteres Problem war, dass das Laufwerk in dem sich die External Files befinden, unbedingt gemapt sein muss. So bin ich eigentlich immer wieder auf der Suche, etwas ähnlich schnelles zu finden, da ich sehr häufig Daten in meinen Programmen importieren oder exportieren muss.

Die Indices und Trigger habe ich auch schon ausgeschaltet, was auch Vorteile in der Geschwindigkeit gab, nur ist das im Netzwerk, wenn mehrere gleichzeitig mit der Datenbank arbeit auch so ein Problem. Falls gerade ein Suche in den Tabellen durchgeführt wird, kann ein verwendeter Index nicht deaktiviert werden.

In den Objekt was ich gerade aufbaue, versuchte ich meine Kenntnisstand zu optimieren, so dass ich bei einer Tabelle mit ca. 70 Feldern und 9 Indices bei 5000 Datensätzen auf etwa 15 Sekunden komme. Allerdings mit einem P4 2,4 GHz. Damit bin ich auch erst einmal zufrieden.

Gruß Bern

[Torsten Grundke]

Hallo Bernd,

die external Tables kann man zwar schnell importieren, aber der Zugriff auf dieses Tabellen ist sehr langsam.

15 Sekunden für 5000 Datensätze erscheint mir etwas langsam. Ich habe ein Importprogramm geschrieben das aus einer Textdatei inklusive visueller Fortschrittsanzeige ca 170 KB pro Sekunde gelesen hat. Ohne Fortschrittsanzeige so ca. 300 KB. Die Testdateieen war so zwischen 10 - 100 MB groß.

Die Daten lagen entweder mit fester Länge oder mit Feldtrenner vor. Die Tabelle besteht aus ca. 120 Feldern wobei die Datentypen bunt gemischt sind.

Gruß

Torste

[Bernd Wurm]

Hallo Torsten,

die Datei, die ich als Test importiere, ist ein CSV-Datei und hat eine Größe von 2,5 MB.
<PRE>
Die 15 Sekunden teilen sich in etwa wie Folgt:
1. 1,5 Sekunden für die Statusanzeige und die Übergabe der Felder in ein Array
2. 5 Sekunden die Abfrage über den Hauptschlüssel, ob der Datensatz bereits vorhanden ist
3. 4 Sekunden für die Parameterübergabe
4. 5 Sekunden Ausführen des Updates oder Inserts
</PRE>

Relativ lang erschein mir hier der 2. Teil. Meine Tabellen haben fast alle eine ID als Hauptschlüssel. Dieser wird hier abgefragt (SELECT ID FROM Artikel WHERE ID=:ID). Die Querys prepare ich auch alle vor dem Öffnen. Da im 2. Teil nur wenige Daten „bewegt“ werden, kommt mir das auch recht gegenüber den anderen Teilen recht langsam vor.

Die Parameter hole ich aus einem array of variant (aFelder) , um flexibel zu sein.
<PRE>
for i:=0 to Feldliste.Count-1 do
TIB_Query(qry).ParamByName(Feldliste.Strings[i]).Value:=aFelder[i];
</PRE>

Gruß Bern

[Torsten Grundke]

Hallo Bernd,

TIB_Query ist für die datenübergabe nicht die ideale Wahl. TIB_DSQL ist dafür das Maß aller Dinge.

Im Vergleich zu TIB_Cursor habe ich damit noch einmal etwa 30% Performancegewinn verzeichnen können. Selbst TIB_Cursor allein ist schon wesentlich schneller als TIB_Query. Somit wirst du einen deutlichen Performancegewinn merken.

Die Verwendung von ParamByName ist in Deinem Fall auch keine ideale Wahl. IBO muß bei ParamByName für jeden deiner 5000 Datensätze immer wieder den Index des jeweiligen Parameters neu bestimmen. Besser ist das einmalige Ermitteln der Parameternummer für jeden Parameter und in der Schleife wird dann per dsql.Params[xyz].Value der Wert zugewiesen.

Für die Abfrage ob der Datensatz bereits vorhanden ist, verwendest du ebenfalls TIB_DSQL. Allerdings geht da natürlich deine Flexibilität verloren.

Machst Du das prepare vor jedem Aufruf der Query?

Den größten Performanceschub bekommst Du bei Verwendung einer SP. Innerhalb der SP wird geprüft ob ein Insert oder Update notwendig ist und der entsprechende Codeteil ausgeführt.

Tschau

Torste

[Torsten Grundke]

Hallo Bernd,

die Geschwindigkeitsangaben beziehen sich auf einen Athlon XP 1GHz Maschine.

Tschau

Torste

[Bernd Wurm]

Hallo Torsten,

erst einmal Danke für Deine Antworten. Ich habe mich heute Vormittag noch einmal an den Umbau meines Objektes gemacht und bin jetzt bei reichlich der hälfte der Zeit angekommen.

Relativ viel hat die Umstellung der Parameterübergabe gemacht. Ich musste hier nur aufpassen, dass ich die Schüsselfelder (die ja normalerweise die ersten Felder sind) beim Update als letztes übergebe und nicht als erstes, wie beim Insert. Die Zeit der Parameterübergabe konnte ich fast komplett einsparen.

Für die Suche des Hauptschlüssels bin ich TIB_Cursor gegangen, das hat auch noch einiges gebracht. (Zeiteinsparung mindesten 50% gegenüber TIB_Query)

Nur das Einsetzen von TIB_DSQL zeigte kaum Vorteile.

Gruß Bern

[Thomas Steinmaurer]

Hallo,<br><br>
Vorsicht beim Zugriff auf Parameter über den Index, und nicht über den Namen, wenn man Firebird 1.5 einsetzt! Unbedingt <b>OldParameterOrdering</b> in <b>firebird.conf</b> auskommentieren und auf 1 setzen. Danach den Firebird Server restarten. Es kann ansonsten sein, dass die Zuordnung von Parameter und Datentyp nicht mehr paßt.<br><br>
Thoma

[Torsten Grundke]

Hallo Thomas,

wenn ich ein Statement einmal Prepare und danach mehrfach verwende, dann sollte sich doch nichts an der Reihenfolge der Parameter ändern?

Die Umsetzung Parametername in Parameternummer erfolgt ja erst nach dem Prepare.

Tschüß

Torste

[Bernd Wurm]

Hallo Thomas und Torsten,

wie Thomas schon erwähnte wird von mir die Query einmal aufgebaut und danach gleich das Prepare aufgerufen. Erst dann komme ich ja auch erst an die Parameter heran. Die Reihenfolge der Felder für die gesamte Tabelle hole ich mir für des Objekt aus den Systemtabellen. In der gleichen Reihenfolge werden dann die Parameter aufgebaut. Nun bin ich bis jetzt der Meinung gewesen, das diese auch in der gleichen Reihenfolge in den Params stehen.

Thomas hat die firebird.conf angesprochen. Die habe ich noch nicht berücksichtig. In welchen Pfad muss die stehen? Welche Einstellungen haben große Auswirkungen auf das Verhalten von FB? Bei Interbase hat sich ja nur die Einstellung von ein zwei Parametern gelohnt.

Gruß Bern