Hallo,
ich nutze derzeit Firebird 2.5.8 mit Dateidatum 05.01.2018 unter Windows 10 Prof. IBO-Client mit Version 5.12.3 3064.
Ich würde vielleicht upgraden wollen, sofern da nicht wesentliche Anpassungen an Client und DB erforderlich sind. Zunächst würde ich bis zu der letzten Version mit ODS 11.2 upgraden, damit ggf. noch der Rückweg da ist.
Vielleicht existiert auch eine Doku für die einzelnen Schritte innerhalb der Versionen.
Gruß
K.-D.
Upgrade von WI-V6.3.8.27089 ohne Anpassungen
Moderator: martin.koeditz
Rückweg geht nicht, du musst die Kopie schon noch behalten.
Der Upgrade geht i.W. über den Umweg 3.0 => 4.0 => 5.0.
Du machst einen Backup deiner 2.5er DB, deinstallierst 2.5, installierst 3.0 und machst einen Restore.
Die 3.0 ist fast komplett kompatibel mit 2.5.
Bei 4.0 muss man schon ein wenig mehr aufpassen.
Wenn die Anwendung damit dann zurechtkommt, kannst du 4.0 versuchen.
Ich arbeite immer noch mit der 3.0.
Alternativ geht auch dieses:
https://ib-aid.com/en/articles/fast-con ... irebird-3/
Danach kann man ggf. den nächsten Schritt gehen.
Der Upgrade geht i.W. über den Umweg 3.0 => 4.0 => 5.0.
Du machst einen Backup deiner 2.5er DB, deinstallierst 2.5, installierst 3.0 und machst einen Restore.
Die 3.0 ist fast komplett kompatibel mit 2.5.
Bei 4.0 muss man schon ein wenig mehr aufpassen.
Wenn die Anwendung damit dann zurechtkommt, kannst du 4.0 versuchen.
Ich arbeite immer noch mit der 3.0.
Alternativ geht auch dieses:
https://ib-aid.com/en/articles/fast-con ... irebird-3/
Danach kann man ggf. den nächsten Schritt gehen.
- martin.koeditz
- Beiträge: 500
- Registriert: Sa 31. Mär 2018, 14:35
Was auch helfen kann, ist den Kompatibilitätsmodus auf 3.0 zu stellen. Z.B. in der database.conf für die jeweilige DB:
Gruß
Martin
Code: Alles auswählen
gsc.fdb = /var/firebird/gsc.fdb {
WireCrypt = Enabled
AuthServer = Legacy_Auth, Srp, Srp256
DataTypeCompatibility = 3.0
}
Martin
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH
Bis dahin erstmal vielen Dank.
Ich werde das mal Version für Version in einer Testumgebung hochsetzen.
Ich bin mir auch noch nicht klar, was die einzelnen Versionen an Vorteilen für mich bieten.
Die 2.5.8 läuft seit Jahren absolut stabil. Ebenso die Linux in einer Debian 6 Chroot Umgebung auf einer Synology 713+. Ich bekomme die Tage einen neuer Dell XPS 16 mit 32 GB RAM und Ultra 9, M2. Da es einiges einfacher macht (Daten synchron halten) habe ich mich entschieden, wieder mit dem Windows RDBMS auf dem Laptop zu arbeiten, da niemand die DB benötigt, wenn ich nicht im Büro bin.
Ich werde das mal Version für Version in einer Testumgebung hochsetzen.
Ich bin mir auch noch nicht klar, was die einzelnen Versionen an Vorteilen für mich bieten.
Die 2.5.8 läuft seit Jahren absolut stabil. Ebenso die Linux in einer Debian 6 Chroot Umgebung auf einer Synology 713+. Ich bekomme die Tage einen neuer Dell XPS 16 mit 32 GB RAM und Ultra 9, M2. Da es einiges einfacher macht (Daten synchron halten) habe ich mich entschieden, wieder mit dem Windows RDBMS auf dem Laptop zu arbeiten, da niemand die DB benötigt, wenn ich nicht im Büro bin.
Firebird 2.5 Debian auf Synology NAS, Windows 10 Prof.
Delphi 6 - 10 Seattle, IBO 5.12.3
Delphi 6 - 10 Seattle, IBO 5.12.3
Ins besonders wenn viele gleichzeitige Abfragen von mehreren Clients erforderlich sind, war die FB 2.5 eher schwerfällig.
Je Datenbank nur 1 Thread, so dass parallele Abfragen sequentiell hintereinander durchgefeührt wurden.
Mit dem Classic-Server konnte man dann 1 Prozess je Verbindung starten. Wenn man genug Speicher und Ressourcen hat, ging das noch ganz gut.
Mit der 3.0 ging es dann schlagartig besser, da der Singleprozess nun tatsächlich je Verbindung 1 Thread startet und somit das Sharing von DB-Pages erheblich einfacher und schneller ging. So habe ich dann z.B. 8GB DBCache konfiguriert um je CPU einen Query ausführen zu können. Klar gilt auch hier, je mehr CPU und Speicher, desto besser die Performance.
Unsere DB's sind so zwischen 50 und 90GB, Tendenz ständig wachsend, da wir via ETL Daten aus divesen Quellen in die Firebird konsolidieren um Abfragen und Beziehungen zu jeder Zeit dynamisch herstellen zu können. Hierfpür werden auch dynmisch Indizes erstellt (z.T. über 100 für 1 Tabelle), deaktiviert und wieder aktiviert.
Klar ist das keine klassische ERP-Lösung, aber so ein DWH ist eben auch für den kleinen Mittelstand erschwinglich.
Neben diesem Aspekt ist auch die Stabilität der DB 3.0 erheblch besser geworden. Wenn täglich zig tausende Transaktionen laufen, Tabellen z.T. gelöscht und neu erstellt werden, 100.000de Zeilen gelöscht und wieder hinzugefügt werden, da kommt einiges auf so eine DB zu.
Dies hätten wir mit dem Microsoft SQL-Server so nie realisieren können, da dieser eine intensive Sperrstrategie verfolgt, die bei der Firebird schlicht nicht existiert.
Je Datenbank nur 1 Thread, so dass parallele Abfragen sequentiell hintereinander durchgefeührt wurden.
Mit dem Classic-Server konnte man dann 1 Prozess je Verbindung starten. Wenn man genug Speicher und Ressourcen hat, ging das noch ganz gut.
Mit der 3.0 ging es dann schlagartig besser, da der Singleprozess nun tatsächlich je Verbindung 1 Thread startet und somit das Sharing von DB-Pages erheblich einfacher und schneller ging. So habe ich dann z.B. 8GB DBCache konfiguriert um je CPU einen Query ausführen zu können. Klar gilt auch hier, je mehr CPU und Speicher, desto besser die Performance.
Unsere DB's sind so zwischen 50 und 90GB, Tendenz ständig wachsend, da wir via ETL Daten aus divesen Quellen in die Firebird konsolidieren um Abfragen und Beziehungen zu jeder Zeit dynamisch herstellen zu können. Hierfpür werden auch dynmisch Indizes erstellt (z.T. über 100 für 1 Tabelle), deaktiviert und wieder aktiviert.
Klar ist das keine klassische ERP-Lösung, aber so ein DWH ist eben auch für den kleinen Mittelstand erschwinglich.
Neben diesem Aspekt ist auch die Stabilität der DB 3.0 erheblch besser geworden. Wenn täglich zig tausende Transaktionen laufen, Tabellen z.T. gelöscht und neu erstellt werden, 100.000de Zeilen gelöscht und wieder hinzugefügt werden, da kommt einiges auf so eine DB zu.
Dies hätten wir mit dem Microsoft SQL-Server so nie realisieren können, da dieser eine intensive Sperrstrategie verfolgt, die bei der Firebird schlicht nicht existiert.