Zugriff auf die FireBird 1.5 DB ist zu langsam

[catao]

Hi @ll

Wir sind momentan dabei unsere 8 Jahre alte Paradox gegen eine FireBird Datenbank auszutauschen, was so im Großen und Ganzen auch funktioniert, jedoch ist teilweise der Zugriff einfach zu langsam - obwohl unsere Rechner schon sehr schnell sind. Wenn ich an die Konfiguration der Kundenrechner denke und dann die Geschwindigkeiten von Firebird beim öffnen sehe, wird mir anders, zumal ich dann schon die Beschwerden kommen sehe.

Mit Programmstart öffnen wir 3 Datenbanken, was beim ersten Start mit unter bis zu >50 Sekunden dauert. Das ist mir persönlich viel zu lang, deshalb meine Frage, woran es liegen könnte.

Um eine mögliche Ursache für dieses Zeitproblem zu finden, habe ich einfach mal ein paar Daten gesammelt.

Ich habe die Datenbank1DB.GDB einfach mal im IB Manager geöffnet und habe gute 25 Sekunden gewartet, bis ich einen Zugriff auf diese hatte.

- Datenbank1DB.GDB ist knapp 60MB groß und umfasst 55 Tabellen, 1 Procedure, 15 Trigger und 12 Generatoren.
- Datenbank2DB.GDB ist knapp 22MB groß und umfasst 55 Tabellen - Zeitdauer zum öffnen ca. 8 Sekunden.
- Datenbank1DB.GDB ist knapp 43MB groß und umfasst 8 Tabellen - Zeitdauer zum öffnen ca. 6 Sekunden.

Wenn ich zuerst die Datenbank1DB.GDB mit dem IB Manager öffne, geht das öffnen er anderen Tabellen schneller (siehe Zeitangaben), öffne ich aber erst eine der anderen DatenbankXDB’s, dann dauern diese etwas länger. Sobald das erste Mal alle Datenbanken geöffnet worden sind, ist der Zugriff danach rasend schnell (<2 Skunden). Okay, das ist klar, weil diese ja schon einmal geöffnet worden sind. In den o.g. Datenbanken befinden sich „nur“ Testdaten, wenn aber wir die mit den lebendigen Daten füllen, dann sind sie um einiges größer.

Das „langsame“ Verhalten ist immer nach einem Rechnerneustart oder wenn ich den Rechner durchlaufen lasse am nächsten Tag spür- und messbar.

Wenn wir in unserem Programm, beim verlassen eines Dialoges ein „commit“ absetzen, vergehen ca. 3 -5 Sekunden, bevor man weiterarbeiten kann. Selbst wenn ich nur den Datensatz bearbeiten will, dieses aber nicht tue und mit abbrechen den Dialog verlasse. Deshalb haben wir es schon so gemacht, das wir erst nach jedem 10 Dialogaufruf ein „commit“ absetzen, ansonsten nur mit „commitretaining“ arbeiten– das warten danach ist genauso lange.

Teilweise sind einzelne Aufrufe per SQL innerhalb unseres Programme’s noch etwas träge, aber da kommen wir Stück für Stück weiter und können es beschleunigen.

Damit Ihr einen groben Einblick in die FireBird DB-Konfiguration bekommt, habe ich 3 Dateien angefügt, die vielleicht helfen können. Sollten weitere Informationen notwendig sein, dann bitte einfach kurz Bescheid sagen.

Ich hoffe dass jemand von Euch eine Idee hat, wo bei uns noch der Fehler liegt – oder soll das so normal sein?!

Da ich selber nicht der Programmierer bin, entschuldigt bitte meine (vielleicht) laienhaften Ausführungen.

Gruß

René

[WoGe]

Hallo,

Zitat von Catoo:

Mit Programmstart öffnen wir 3 Datenbanken, was beim ersten Start mit unter bis zu >50 Sekunden dauert. Das ist mir persönlich viel zu lang, deshalb meine Frage, woran es liegen könnte.

Beim 1ten Start wird vom FB-Server die Datenbank geladen und initialisiert. Wenn du danach von einem anderen Rechner aus auf die Datenbank zugreifst sollte dieser 2te Zugriff sehr viel schneller gehen.

Und es ist der Geschwindigkeit auch wenig förderlich, wenn man Table-Komponenten oder in Queries
Select * from Table verwendet, besonders wenn in den Tabellen Blobs sind.

Ich sehe in deinem Header der Zufriff erfolgt über Interbase-Komponenten. Welche denn? die originalen von Delphi sind doch wohl nicht mehr so richtig FB1.5 kompatibel!

mfg
wo

[catao]

hallo wo

Zitat von WoGe:

Beim 1ten Start wird vom FB-Server die Datenbank geladen und initialisiert. Wenn du danach von einem anderen Rechner aus auf die Datenbank zugreifst sollte dieser 2te Zugriff sehr viel schneller gehen.

das stimmt, der 2. db zugriff ist schneller, hatte ich ja auch geschrieben. dabei ist es egal, ob ich mit unserem programm oder über den ib-manager darauf zugreife. gibt es keine möglichkeit das zu beschleunigen oder kann man mit dem rechnerstart die datenbank im hintergrund vielleicht laden?

Zitat von WoGe:

Und es ist der Geschwindigkeit auch wenig förderlich, wenn man Table-Komponenten oder in Queries
Select * from Table verwendet, besonders wenn in den Tabellen Blobs sind.

gut zu wissen, das gebe ich nachher mal an den programmierer weiter.

Zitat von WoGe:

Ich sehe in deinem Header der Zufriff erfolgt über Interbase-Komponenten. Welche denn? die originalen von Delphi sind doch wohl nicht mehr so richtig FB1.5 kompatibel!

da muss ich den programmierer nachher fragen, wenn er wieder am rechner sitzt, aber soweit ich weiß nutzt er die originalen von delpi. welche müsste er denn verwenden?


gruß
rené

[WoGe]

Zitat von catao:

da muss ich den programmierer nachher fragen, wenn er wieder am rechner sitzt, aber soweit ich weiß nutzt er die originalen von delpi. welche müsste er denn verwenden?

Ich vewende zurzeit die ZEOS-Komponenten. Bin mir aber noch nicht 100% darüber klar ob das der Weisheit letzter Schluss ist. Sie funktionieren für meine Zwecke halt mehr ails ausreichend.

mfg
wo

[fisherman_b]

Hallo,

zum Thema Firebird & InterBase Komponenten kann ich folgende Erfahrung beisteuern:

Ich habe ein Warenwirtschaftssystem mit Firebird 1.5 und den InterBase Komponenten von Delphi 7 programmiert. Hinsichtlich der Geschwindigkeit gibt es keinerlei Grund zur Beanstandung, und die Interbase Komponenten arbeiten wunderbar mit dem Firebird Server zusammen. Ich vermute, dass es bei Deinem Problem gar nicht mit den verwendeten Komponenten zusammenhängt... aber das kannst Du ja am einfachsten testen, indem Du mal mit einem kleinen Testprojekt, welches die Zeos Komponenten verwendet, auf die gleichen Datenbanken zugreifst.
Natürlich darf man gerade bei den Interbase-Komponenten nicht einfach davon ausgehen, dass die mit künftigen Firebird-Versionen reibungslos funktionieren werden. Daher sind die Delphi Interbase-Komponenten wahrscheinlich kaum als erste Wahl zu sehen. Man sollte allerdings nicht den Fall als Standard ansehen, dass auf einem Produktiv-System jede neu erscheinende Version einer Datenbank Software gleich die vorherige ersetzt. Das macht man wohl eher auf Test- oder Entwicklungssystemen. Im Produktiv-Betrieb setzt man ja über einen möglichst langen Zeitraum Produkte und deren Versionen ein, die sich über einen bestimmten Zeitraum hinweg etabliert haben. Beispiel Apache oder MySQL... die am häufigsten verwendeten Versionen in Produktionsumgebungen haben schon richtig viele Jahre auf dem Buckel.

Gruss,

Bernhard

[arnold mueller]

Hallo René,

auf welchem Betriebssystem läuft der Firebird Server?
Falls es XP sein sollte, und die Systemwiederherstellung aktiviert ist,
dann lohnt ein Blick hier.

Bye,
Arno

[Robert_G]

Das ist möglich, schlielich heißt sie GDB.
Benenne die DBs lieber in fdb um.

Und zu TTable -> Das Ding ist IMHO gedacht für winzige Mini Datenbestände oder wenn man keinen Plan von SQL hat.
Da beides bei euch wohl nicht der Fall ist (60MB ist zwar vergleichsweise wenig, aber für ungefilterte SELECT* ), denke ich es wäre wohl das beste auf die entsprechenden DataSets ummzusteigen.

[dstein]

Hallo Forum,

Ich möchte zu Firebird 1.5 und den InterBase Komponenten von Delphi 7 noch hinterher schicken,
dasz die neuen SQL-Befehle von FB 1.5 nicht 100% unterstützt werden (z.Bsp.: recreate...).
Als alternative zu Zeos, UIB(Unified Interbase)[1], IBObjects[2] finde ich FibPlus[3] gut, weil die Zeitnah zu Firebird entwickeln. Und laut verschiedener Stimmen sollen die den "schnellsten Zugriff/Verarbeitung" haben!

[1] http://www.sourceforge.net/projects/uib
[2] http://www.ibobjects.com
[3] http://www.devrace.com

Tschau
Dirk Stein

[alex517]

Hallo,

die Dauer des ersten Zugriffs auf eine FB/IB-Datenbank hängt u.A. auch
von der Auflösung des Servernamens durch das Netzwerk ab.
Es hilft manchmal statt des Servernamens die IP-Adresse anzugeben.

Als Komponenten kann ich FibPlus nur empfehlen.
Von Vorteil ist z.B. die Verwendung von getrennten Lese- und Schreib- Transaktionen
für ein DataSet. Damit ist die Dauer der Schreibtransaktionen auch bei Verwendung
datensensitiver Componenten wie TDBGrid, TDBEdit usw. nicht vom Benutzer abhängig,
sondern wird auf die Dauer des Postens reduziert. Es kann auch eine Hardcommit
verwendet werden (an Stelle des serverbelastenden CommitRetainings) da es spezielle
Routinen für ein Refresh gibt.

alex