Firebird Backup Tool gbak unter Linux Mint v19.3 Cinnamon 4.4.8

[bfuerchau]

Mal sehen, wie man 3.0 nach 5.0 im Kompatibilitätsmodus mit SYSDBA verwenden kann, ob die Stabilität höher wird und wie sich Backup/Restore (DB-Rorganisation) dann verhalten. Wichtig in diesem Zusammenhang wird dann der parallele Indexaufbau, da wir, wie oben beschrieben, viele Indizes automatisch erstellen und je Tabelle bis zu 100! Indizes beim ETL deaktivieren und wieder Reaktivieren müssen.
100 sind deshalb keine Seltenheit, weil eine Tabelle durchaus mehr als 50 Felder haben kann und die Where-Klauseln sehr flexibel gestaltet werden können. Die Grenze für einen Index sind ja immer noch 16 Felder mit max. 4K (bei 16K Blocksize), wobei i.d.R. 4-6 Felder ausreichen und mehr selten Vorteile bringen. Die berühmten 1-Feld-Indizes habe ich abgeschafft, da diese einfach eine zu niedrige Selektivität haben.
Über den FBClient bekommt man ja auch ein Ergebnis der verwendeten Indizes zurück, so dass ich darüber eine Statistik, sowie letzte Verwendung erfahre (dabei stelle ich dann fest, wie hoch meine Trefferquote für meine Indexerstellung ist).
Nicht mehr verwendete Indizes fliegen nach 60 Tagen raus. Es wird deshalb so lange aufgehoben, da es z.B. Monatsabfragen gibt und diese dann den Index erst erstellen müssten.

[RS667]

Mal sehen, wie man 3.0 nach 5.0 im Kompatibilitätsmodus mit SYSDBA verwenden kann, ob die Stabilität höher wird und wie sich Backup/Restore (DB-Rorganisation) dann verhalten. Wichtig in diesem Zusammenhang wird dann der parallele Indexaufbau, da wir, wie oben beschrieben, viele Indizes automatisch erstellen und je Tabelle bis zu 100! Indizes beim ETL deaktivieren und wieder Reaktivieren müssen.

Welcher Kompatibilitätsmodus? Der für die Datatypes/timestamps? Der läuft gut. Ebenso habe ich beim spielen jetzt einen guten Eindruck von der Stabilität, wobei ich natürlich nur mit 8 Connections parallel getestet habe. Ein paar Importe über die Software, parallel ein paar über sql, parallel ein bisschen die normalen Programmfunktionen getestet.
Die parallele Indexerstelung / Backup / Restore ist der Hammer, das dürfte sich bei Euch dann richtig lohnen.

Ich habe hier mittlerweile Feedback, dass der Hersteller unserer Software maximal 3.0.5 offiziell unterstützt. Ich hab naiverweise auf unserem DBServer die aktuellste 3er aus dem apt repo gezogen, wir haben also eine unsupportete 3.0.8 produktiv im Einsatz. Problemlos allerdings.

Das jetzige Testsystem läuft auch tadellos auf 5.0.1, nachdem ich den coolen Bug mit der Datenanpassung umgangen habe. Die Aussage des Herstellers hat mich allerdings etwas nachdenklich gemacht, und ich werde mir noch einige der Videos anschauen, die letzthin von der foundation veröffentlicht wurden, zum Thema Migration von 3 auf 5. Dann bespreche ich mal mit unseren Devs, was die sagen.

@Martin: So machen wir das auch, wobei mich die Laufzeit bisher nicht so tangiert hat. Ich hab nur massive Probleme damit, wenn ich mal wirklich einen Restore bräuchte, und der dann über Stunden läuft...

MfG Michael

[martin.koeditz]

@Martin: So machen wir das auch, wobei mich die Laufzeit bisher nicht so tangiert hat. Ich hab nur massive Probleme damit, wenn ich mal wirklich einen Restore bräuchte, und der dann über Stunden läuft...

Das gehört nun in unserem Umfeld der Vergangenheit an.

[vr2]

Ich habe hier mittlerweile Feedback, dass der Hersteller unserer Software maximal 3.0.5 offiziell unterstützt. Ich hab naiverweise auf unserem DBServer die aktuellste 3er aus dem apt repo gezogen, wir haben also eine unsupportete 3.0.8 produktiv im Einsatz. Problemlos allerdings.

Ist die closed-source-Software zufällig eine Wawi/Fibu?

Das jetzige Testsystem läuft auch tadellos auf 5.0.1, nachdem ich den coolen Bug mit der Datenanpassung umgangen habe. Die Aussage des Herstellers hat mich allerdings etwas nachdenklich gemacht, und ich werde mir noch einige der Videos anschauen, die letzthin von der foundation veröffentlicht wurden, zum Thema Migration von 3 auf 5. Dann bespreche ich mal mit unseren Devs, was die sagen.

Was meinst Du mit "nachdem ich den coolen Bug mit der Datenanpassung umgangen habe"?
Ansonsten: 5.0.1 ist natürlich produktionstauglich, haben wir bei BI-Anwendungen (Desktop und Web) im Einsatz.

[RS667]

Ich habe hier mittlerweile Feedback, dass der Hersteller unserer Software maximal 3.0.5 offiziell unterstützt. Ich hab naiverweise auf unserem DBServer die aktuellste 3er aus dem apt repo gezogen, wir haben also eine unsupportete 3.0.8 produktiv im Einsatz. Problemlos allerdings.

Ist die closed-source-Software zufällig eine Wawi/Fibu?

Das jetzige Testsystem läuft auch tadellos auf 5.0.1, nachdem ich den coolen Bug mit der Datenanpassung umgangen habe. Die Aussage des Herstellers hat mich allerdings etwas nachdenklich gemacht, und ich werde mir noch einige der Videos anschauen, die letzthin von der foundation veröffentlicht wurden, zum Thema Migration von 3 auf 5. Dann bespreche ich mal mit unseren Devs, was die sagen.

Was meinst Du mit "nachdem ich den coolen Bug mit der Datenanpassung umgangen habe"?
Ansonsten: 5.0.1 ist natürlich produktionstauglich, haben wir bei BI-Anwendungen (Desktop und Web) im Einsatz.

Nope, keine WaWi/FiBu. Und der Bug der Datenanpassung:
Beim Update der Software auf eine höhere Version wird auch die Datenbankstruktur angepasst, es kommen ein paar Felder und Tables hinzu. Während dieses Prozesses, der auf 3.0.8 ohne jegliche Probleme durch läuft, troitt zuerst der Fehler auf, dass eins der neuen NOT NULLFelder nicht hinzugefügt werden kann, weil....NULL Werte drin sind. Ich habe dieses Feld dann selbst als nullable hinzugefügt.
Zweiter Error war, dass an irgendeiner Stelle eine Abfrage gemacht wird, die in 3 funktioniert, in 5 einen ISC Error auswirft.

Da habe ich dann abgebrochen, die DB aus einem Backup auf 3.0.8 restored, das Softwareupdate auf diesem Stand durchgeführt, und danach per backup mit dem 3er FB und Restore auf den 5er FB eine lauffähige Version der Software gehabt.

Relativ billig die 2 Fehler umgangen halt.

MfG Michael

[bfuerchau]

Was du dann wohl mit jedem neuen Softwareupdate wiederholen must.
Warum gibt es aber Softwareupdates für eine Software mit einer alten DB-Version ?

[RS667]

Was du dann wohl mit jedem neuen Softwareupdate wiederholen must.
Warum gibt es aber Softwareupdates für eine Software mit einer alten DB-Version ?

Das könnte so sein, muss aber nicht. Und es gibt keine Updates für eine Software mit alter DB-Version. Man hat halt Softwarestand X mit DBVersion X, und wenn man auf Stand Y Updatet, dann muss die DB natürlich auch die Struktur von Y haben.

Da kommen immer mal Tables dazu, Felder in Tables, neue Trigger, Generatoren....sowas halt.

Und der DB Stand muss halt zum Softwarestand passen.

[vr2]

Da kommen immer mal Tables dazu, Felder in Tables, neue Trigger, Generatoren....sowas halt.

Und der DB Stand muss halt zum Softwarestand passen.

Meine Erfahrung mit kommerziellen Firebird-Anwendungen ist, dass deren Hersteller durchweg Jahre hinter der aktuellen Firebird-Entwicklung hinterherhinken und neue Features der DB nicht nutzen. Die nutzen Firebird wie vor 10-15 Jahren. Wenn Änderungen kommen, dann wie Du sagst neue Tabellen, Feldänderungen in Tabellen, evtl mal eine neue SP oder Trigger. Natürlich müssen die Hersteller beachten, dass ihre Produkte weiterhin reibungslos laufen, aber sie lassen sich schon sehr viel Zeit mit ihrem konservativen Ansatz und supporten gerade mal die nächsthöhere Version, die nicht bereits aus der offiziellen Wartung rausgefallen ist. Dh Firebird 3 wird mit Ach und Krach supportet, Firebird 4 oder gar 5 einfach nicht. Firebird 4 ist seit Frühjahr 2021 verfügbar. Wo ist das Problem? Bei Connectivity-Bibliotheken, die die neuen Firebird-Versionen ebenfalls jahrelang nicht unterstützen? Ja, ist teilweise sicher ein weiterer Grund. Allerdings kann man die meisten Vorteile neuerer Firebird-Versionen auch mit alten libs nutzen, wenn man sich hinreichend, nicht mal super, auskennt in der Materie, da die zum größten Teil serverseitig angesiedelt sind und dort ablaufen.

Die DB-Version muss nicht zur SW-Version passen, bzw kann einfach passend gemacht werden. Wenn ein FB5 auf legacy-Kommunikation konfiguriert ist, kannst Du ihn auch mit einem Client aus dem letzten Jahrhundert kontaktieren.

Viele Grüße, Volker

[RS667]

Hallo,

das weiß ich (leider?) alles schon. Mit Datenbankversion ist nicht die Version gemeint, auf der der Server läuft. Dass man das auf legacy schalten kann weiß ich. Ich meinte, dass die verwendete Software eine gewisse Datenbankstruktur erwartet, und falls Diese den Stand von einer Älteren hat wird beim Start die Datenbankstruktur angepasst. Der legt dann halt die fehlenden Tables, Felder, Trigger etc. an, falls sie nicht da sind. Das meinte ich, dass die Softwareversion zur Datenbank passen muss.

Bezüglich der FB Version und Anbieter hast Du recht. Ich bin hier produktiv auf 3.0.8 unterwegs. Eine Anfrage beim Hersteller ergab, dass die "offiziell" supportete Version max. 3.0.5 ist. Ich überlege immer noch, den Tip von Alexey zu befolgen, einfach mal das Tracing an zu machen, das Programm möglichst ausgiebig in der Testversion durch zu probieren, und mal Logs zu lesen.
Bei der Nutzung an sich habe ich im Testbetrieb keine Probleme festgestellt, nachdem alles erstmal lief. Aber aufgrund des wirklich großen Funktionsumfangs kann man nicht alles durchspielen...

MfG Michael.

[martin.koeditz]

Dass Softwarehersteller hier etwas träge reagieren, kann ich teilweise nachvollziehen. Es gibt noch immer diverse Programme, die FB 2.5 nutzen. Das kam aber schon 2016 heraus. Spricht natürlich irgendwie für das System.

Allerdings gibt es auch Gründe für eine Aktualisierung neben neuen Features, etc.. Der Support ist offiziell nur noch für die beiden aktuellsten Versionen gegeben. Wenn man dann auch noch NIS2-konform arbeiten soll, wird es eventuell schwierig.

Also, m.E. sollte man schon einigermaßen mit der Zeit gehen.

Gruß
Martin