Firebirdforum.de

Wir möchten Ihre Aufmerksamkeit auf diesen ausführlichen Artikel lenken, der auf Praxiserfahrungen basiert und einem selten diskutierten Thema gewidmet ist: der Migration von Firebird zu PostgreSQL.

Der Artikel beleuchtet 23 praxisnahe Probleme, die Teams oft unvorbereitet treffen – etwa warum PostgreSQL einfache Updates 17-mal langsamer ausführen kann als Firebird, weshalb Ihre Backup-Strategie komplett überarbeitet werden muss und warum Sie sämtliche Trigger neu schreiben müssen. Dabei geht es nicht darum, PostgreSQL schlechtzumachen (es ist eine hervorragende Datenbank), sondern darum, DBAs, CTOs und Entwicklern ein klares Bild davon zu geben, worauf sie sich einlassen.

Der Artikel ist auf Englisch, Deutsch und Portugiesisch verfügbar:

Migration from Firebird to PostgreSQL: What can go wrong? – PDF-Version

Migration von Firebird zu PostgreSQL. Was kann schiefgehen? – PDF-Version

Migração do Firebird para PostgreSQL: O que pode dar errado? – PDF-Version

Wir danken allen, die bei der Materialsammlung und der Vorbereitung der Übersetzungen geholfen haben: Dmitry Yemanov, Sergey Volkov, Denis Simonov, Alexey Kovyazin, Martin Köditz und Edson Gregorio.

Wenn Sie eine Datenbankmigration von Firebird zu PostgreSQL oder zu einer anderen Datenbank in Erwägung ziehen, teilen Sie uns bitte Ihre Fragen und Bedenken mit.

Für alle Rückfragen wenden Sie sich gerne an Alexey Kovyazin: ak@firebirdsql.org

Originaltext erschienen unter: https://firebirdfoundation.substack.com ... m-firebird

Eine sehr gute Erklärung für die unterschiedlichen Arbeitsweisen dieser 2 DBMS.
Erschreckend für mich ist nicht die Tatsache der Inkompatibiltäten der SQL's sondern dass es eine kommerzielle Postgre überhaupt gibt und diese auch nun für Windows nicht mehr verfügbar ist.
Ich dachte Postgre wir durch die Community, ähnlich Firebrid, gefördert.

Viele DBMS haben je Tabelle und Index je eine eigene Datei im Dateisystem was bei der Firebird eben nicht der Fall ist. Und wenn der Aufwand im Gegensatz zum Nutzen auch noch durch notwendige finanzielle Aufwände in eine Pro-Version mit Linux-Server erfolgen muss, sollte man von solchen Projekten wirklich Abstand nehmen.

Wir wurden des öfteren schon gefragt, ob wir nicht auf SQL-Server umstellen können, da man diesen bereits "im Haus" hätte.
Aber wie im o.a. Dokument erwähnt benutze ich häufig einen Execute-Block sowie auch innerhalb dessen bis zu 255 parametrierte Update or Insert (beschränkt halt auf die 10MB und max. 2000 Parametern).
Damit schafft man schon mal 10.000 bis 30.000 Inserts/Sekunde statt 2000/Sekunde mit Einzelausführungen.
255 deshalb, weil SQL max. 255 Tabellen verarbeiten kann, auch wenn es immer dieselbe ist.
Vorteile des Update or Inserts ist auch die Wiederholbarkeit innerhalb eines Massenladens.
Der SQL-Server Merge bietet zwar ähnliches an, allerdings wird ein 2. Update über denselben Schlüssel mit einem Transaktionsabbruch "doppelter Update" quittiert, also nicht hilfreich.

Auch die Satzversionen sind ein essentieller Bestandteil von ETL-Prozessen, die natürlich schon mal länger dauern können und auch mal per rollback abgebrochen werden müssen.
So wird dann ein "Delete from Table" und Massen Insert in einer Transaktion durchgeführt. Bei Abbruch, egal aus welchen Gründen, sind die vorherigen Daten halt weiter verfügbar.
Bei der PostGre kann ich das auf den ersten Blick nicht erkennen.

Vieles spricht also dafür, bei Firebird zu bleiben, weil letztlich die Haupt-Vorteile Einzeldatei und kostenlos überwiegen.

Wir wurden des öfteren schon gefragt, ob wir nicht auf SQL-Server umstellen können, da man diesen bereits "im Haus" hätte.

Ja, das ist ein aktuelles Thema bei uns. Läuft "unerwartet" auch nicht schneller...

Warum auch, da gibts halt so physikalische Grenzen, die auch Microsoft nicht umgehen kann.
Zumal die Datenbanken mangels Komprimierung auch größer sind und deshalb mehr von der Platte zu lesen ist.
Ein großes Problem habe ich da bei Transaktionen.
Wenn ich für den ETL einen synchronen Load (Read committed) einer Tabelle benötige, kommt das Thema LockEscalation ins Spiel, dass zum Schluss die gesamte Tabelle sperrt und ein ERP zum Stillstand bringen kann.
Immerhin lädt man bei ETL schon mal eine ganze Tabelle herunter.
Bei Lesegeschwindigkeiten von ca. 30.000 Zeilen/Sekunde dauern 1 Mio. Zeilen auch schon mal 30 Sekunden.
Bei der Firebird habe ich das Problem erst gar nicht, da ich neuerer Transaktionen sowieso nicht sehe.