[{"content":"Die Highlights jedes Releases, gruppiert nach Minor-Version. Das CHANGELOG.md im Upstream-Repository enthält die vollständige, ausführliche Historie — einschließlich der Analyse hinter jeder Korrektur — und jedes getaggte Release ist auf der GitHub-Releases-Seite aufgeführt.\n0.16.0 August 2026 Grundlegende Überarbeitung von Informix und eine Korrektur beim JDBC-Beenden JDBC-Connectoren hängen sich beim Beenden nicht mehr auf. Worker-Threads lösen sich nun gemeinsam mit ihrer Verbindung von der JVM, sodass eine Migration, die früher nach der Ausgabe ihrer Zusammenfassung endlos hing, in weniger als einer Sekunde abschließt. Informix: Systemkatalog wird nicht mehr migriert. Die Erkennung trennt jetzt Benutzerobjekte von den Objekten des Servers selbst — eine Testdatenbank ging von 534 Routinen und 89 Tabellen auf die 17 Routinen und 24 Tabellen zurück, die das Schema tatsächlich definiert. Informix: Viele Objekttypen werden überhaupt erst migriert. Korrekturen für BSON/JSON-Spalten, Collection- und Row-Typen, INTERVAL-Spalten, absteigende und funktionsbasierte Indizes, Check-Constraints, MERGE-Anweisungen, globale Variablen und Trigger — von denen mehrere zuvor die gesamte Planungsphase scheitern ließen. Informix: MONEY wird als NUMERIC migriert — unter Beibehaltung von Precision und Scale, statt als der deutlich abweichende MONEY-Typ von PostgreSQL. 0.15.0 Juli 2026 T-SQL-Parser und Tiefe der Validierung Die Validierung vergleicht die Struktur, nicht nur die Daten. Die Anzahl von Spalten, Indizes und Constraints wird jetzt auf beiden Seiten ermittelt, in den Protokolltabellen validation_indexes und validation_constraints festgehalten und im Markdown-Bericht als direkt gegenübergestellte Tabellen dargestellt. Jede Abweichung lässt die Validierung der Tabelle fehlschlagen. Härtung des Parsers für Sybase ASE / T-SQL. Temporäre #-Tabellen werden auf pg_temp abgebildet, aus EXEC @id = func(...) wird eine echte PL/pgSQL-Zuweisung, veraltete Transaktionsdirektiven und GOTO-Label werden neutralisiert, und Cursor-Definitionen über mehrere Zeilen werden korrekt geparst. Oracle nutzt nun python-oracledb und ersetzt damit das veraltete cx_Oracle. Der Thin-Modus ist die Voreinstellung, sodass der Oracle Instant Client nicht mehr erforderlich ist. Erschöpfung der Verbindungen bei der Validierung behoben — die Prüfsummen-Engines trennen die langlebigen Verbindungen des Validators nicht mehr mitten in der Schleife. 0.14.0 Mai 2026 Konfliktbehandlung und ein SQL-Parser für Sybase data_conflict_action in table_settings ergänzt — wählen Sie replace, merge_keep_target, merge_keep_source oder skip, wenn Daten sowohl in der Quell- als auch in der Zieldatenbank vorhanden sind. In allen Connectoren umgesetzt. table_name akzeptiert Listen und reguläre Ausdrücke, sodass eine einzige Direktive nun viele Tabellen gleichzeitig abdecken kann — einheitlich für abweichende Batch-Größen, Chunking und Schalter zur selektiven Migration. Sybase ASE hat einen echten SQL-Parser erhalten für Stored Procedures — denselben, der zuvor nur für Views genutzt wurde — zusammen mit einer langen Liste von Korrekturen bei der T-SQL-Konvertierung, die IF/ELSE-Verschachtelungen, UNION, PRINT, CONVERT-Datetime-Styles und Inline-Bedingungen abdecken. 0.12.x März – April 2026 Parallele View-Migration und DB2-z/OS-Aliase Views werden parallel migriert über einen Thread-Pool, wobei Alias-Views bewusst erst verarbeitet werden, nachdem alle regulären Views abgeschlossen sind, um Abhängigkeitskonflikte zu vermeiden. Die DB2-Alias-Auflösung kennzeichnet das Ziel eines Alias im Katalog nun als TABLE oder VIEW und verhindert damit zirkuläre Abhängigkeiten zwischen View und Alias. Der CSV-Import verarbeitet Komma-Dezimaltrennzeichen und führt Felder nur dort zusammen, wo die Zielspalte ein NUMERIC/DECIMAL/FLOAT mit Nachkommastellen ist. Korrekturen für Check-Constraints (#57), das Auslesen von Sequenzen bei Informix, MySQL und Sybase (#63), die View-Migration in den meisten Connectoren (#65) sowie die Ersetzung von Datentypen bei PostgreSQL-nach-PostgreSQL-Migrationen (#67). 0.11.x November 2025 – März 2026 Offline-DDL-Anbindung und IBM DB2 z/OS Neuer Konnektivitätstyp ddl — Datenbankobjekte können statt aus einer Live-Verbindung aus DDL-Dateien gelesen werden, konfiguriert über ddl.directory. Unterstützung für IBM DB2 z/OS durch den neuen Connector ibm_db2_zos ergänzt; der bestehende DB2-Connector wurde in ibm_db2_luw umbenannt. Die Sybase-ASE-Konvertierung wurde neu geschrieben — mit einem SQL-Parser für Kontrollfluss, Cursor und Datentypen sowie Unterstützung für die veraltete Outer-Join-Syntax (*= / =*), benutzerdefinierte Typen, OUTPUT- zu INOUT-Parameter und @@rowcount über GET DIAGNOSTICS. MS SQL Server hat eine View-Konvertierung mit korrekten Datentypen, eine Konvertierung benutzerdefinierter Typen sowie eine erste, brauchbare Version der Konvertierung von Triggern, Funktionen und Prozeduren erhalten. Erste Version der Benutzerdokumentation im Verzeichnis docs/ ergänzt. 0.10.x Oktober – November 2025 Informix-LOB-Import in großem Umfang Paralleler LOB-Import für Informix. Informix exportiert jedes CLOB/BLOB in eine eigene Datei (max. 2 GB), auf die Zeiger in der Haupt-UNL-Datei verweisen. Eine sequenzielle Verarbeitung war bis etwa zehn Dateien praktikabel; eine konfigurierbare Anzahl paralleler Worker bewältigt nun die Hunderte von Dateien, die reale Tabellen erzeugen. Mehrere LOB-Spalten pro Tabelle werden unterstützt, und NULL-LOB-Werte werden erkannt, gleich ob sie als Platzhalter 0,0,0 oder als literales NULL auftreten. Die UNL-nach-CSV-Konvertierung wurde gehärtet gegen abschließende Backslashes, Windows-Zeilenenden (\\r\\n) und escapte Trennzeichen. MySQL hat ODBC- und JDBC-Konnektivität erhalten — zusätzlich zum bestehenden nativen Treiber. 0.9.x Juni 2025 PyPI-Distribution und sqlglot-basierte View-Konvertierung Veröffentlichung auf PyPI über pyproject.toml, wodurch pip install credativ-pg-migrator zum Standardweg der Installation wurde. sqlglot für die View-Konvertierung übernommen, beginnend mit Sybase ASE, was die Erfolgsquote der View-Migration deutlich erhöht hat. names_case_handling (lower, upper, preserve) wird nun beim Erzeugen von CREATE-Anweisungen berücksichtigt — Legacy-Engines sind sich über die Groß- und Kleinschreibung von Bezeichnern uneinig, und Anwender müssen die Wahl haben. Daten werden über eine explizite Spaltenliste ausgewählt statt über SELECT *, sodass sperrige Typen (Geometrie, Sets, LOBs, benutzerdefinierte Typen) bereits in der Quellabfrage gecastet oder transformiert werden können. Die Analyse vor der Migration wurde begonnen — sie automatisiert die Fragen, die sonst jedem Kunden zu seiner Quelldatenbank gestellt werden. 0.8.0 Juni 2025 Erstes öffentliches Release Das erste öffentliche Release von credativ-pg-migrator, bei dem die Connectoren in ein eigenes Modulverzeichnis verschoben wurden. Ältere Releases # Versionen vor 0.8.0 liegen zeitlich vor der Veröffentlichung. Ihre Historie ist im vollständigen Changelog erhalten.\n","externalUrl":null,"permalink":"/de/changelog/","section":"credativ-pg-migrator","summary":"Die Highlights jedes Releases, gruppiert nach Minor-Version. Das CHANGELOG.md im Upstream-Repository enthält die vollständige, ausführliche Historie — einschließlich der Analyse hinter jeder Korrektur — und jedes getaggte Release ist auf der GitHub-Releases-Seite aufgeführt.\n","title":"Changelog","type":"page"},{"content":" Legacy-Datenbanken nach PostgreSQL migrieren credativ-pg-migrator überführt Schemata, Daten, Constraints, Routinen und Views aus proprietären und Legacy-Datenbanksystemen nach PostgreSQL — mit einem Migrationsprotokoll und einer Verifikation nach der Migration, die genau zeigen, was angekommen ist. Loslegen Auf GitHub ansehen Warum credativ-pg-migrator # Zehn Quelldatenbanken, ein Werkzeug Oracle, Informix, Sybase ASE, MS SQL Server, IBM DB2 (LUW, z/OS, i), MySQL, MariaDB, SQL Anywhere, SQLite und PostgreSQL — jede über einen eigenen Connector, sodass die Eigenheiten der Engines dort behandelt werden, wo sie hingehören.\nMehr als Tabellen und Zeilen Primärschlüssel, Sekundärindizes, Fremdschlüssel, Check-Constraints, Defaults, IDENTITY-Spalten und Sequenzen wandern gemeinsam mit den Daten. Views, Funktionen, Prozeduren und Trigger werden nach PostgreSQL-SQL und PL/pgSQL übersetzt.\nVerifiziert, nicht nur kopiert Die Validierung nach der Migration führt unabhängige Vergleiche durch — Zeilenzahlen, Prüfsummen ganzer Tabellen, Hashes zufälliger Zeilen und LOB-Byte-Größen — dazu einen strukturellen Vergleich von Spalten, Indizes und Constraints, ausgegeben als Markdown-Bericht.\nAuch für abgeschottete Umgebungen Wo eine Live-Verbindung nicht möglich ist, verarbeitet der Migrator stattdessen Offline-DDL-Skripte und CSV-Extrakte (IBM DB2 z/OS und i) oder Informix-.unl- Exportdateien.\nÜber Konfiguration anpassbar Eine einzige YAML-Datei steuert den Lauf: Ersetzungen von Datentypen und Default-Werten, WHERE-Filter pro Tabelle, Batch-Größen und Konfliktbehandlung — Anpassungen an Ihr Schema erfordern keine Codeänderungen.\nEin vollständiges Migrationsprotokoll Jedes migrierte Objekt wird mit Quellcode, generiertem Zielcode und Ergebnis in einer PostgreSQL-Migrationsdatenbank festgehalten — ein fehlgeschlagenes Objekt lässt sich so untersuchen und erneut migrieren, statt raten zu müssen.\nUnterstützte Quelldatenbanken # OracleLive-Verbindung InformixLive-Verbindung Sybase ASELive-Verbindung MS SQL ServerLive-Verbindung IBM DB2 LUWLive-Verbindung IBM DB2 z/OSoffline (DDL + CSV) IBM DB2 for ioffline (DDL + CSV) MySQLLive-Verbindung MariaDBLive-Verbindung SQL AnywhereLive-Verbindung SQLitelokale Datei, kein Treiber PostgreSQLfür Spezialfälle Wie vollständig die einzelnen Connectoren sind, unterscheidet sich erheblich. Die Funktionsmatrix führt den Status je Connector und Funktion auf — abgeglichen mit dem Quellcode der Connectoren, nicht mit einer Roadmap.\nZieldatenbank: PostgreSQL.\nInstallation # Aus PyPI # python3 -m venv migrator_venv . ./migrator_venv/bin/activate pip install credativ-pg-migrator Das Paket ist unter pypi.org/project/credativ-pg-migrator veröffentlicht.\nAus dem PostgreSQL-APT-Repository # credativ-pg-migrator ist im PostgreSQL-Community-Repository apt.postgresql.org enthalten — die PostgreSQL-APT-Wikiseite beschreibt, wie Sie es unter Debian und Ubuntu einbinden.\nEine Migration ausführen # credativ-pg-migrator \\ --config=./test_database.yaml \\ --log-file=./test_database_$(date +%Y%m%d).log \\ --log-level=INFO Fertige Konfigurationsbeispiele für jede unterstützte Quelldatenbank liegen im Repository unter docs/configs/ — kopieren Sie das Beispiel Ihrer Quelldatenbank, passen Sie die mit \u0026gt;\u0026gt;\u0026gt; ADJUST markierten Zeilen an und starten Sie den Lauf.\nArchitektur # Das Werkzeug verbindet sich mit der Quelldatenbank, liest das Datenmodell aus, erzeugt daraus PostgreSQL-kompatible Strukturen und schreibt sie in die Zieldatenbank — koordiniert von einem zentralen Orchestrator, der parallele Worker steuert. Mehr dazu auf der Dokumentationsseite.\nOpen Source, mit professionellem Support # credativ-pg-migrator steht unter der GNU General Public License v3 und wird offen auf GitHub entwickelt. Entwickelt und gepflegt wird das Projekt von der credativ GmbH, einem Beratungs- und Engineering-Unternehmen für PostgreSQL und Open Source.\nWenn Sie eine Datenbankmigration planen und professionelle Unterstützung wünschen — von der Analyse Ihres Quellsystems bis zur Durchführung der Migration — sprechen Sie uns an.\nMitmachen # Fehlerberichte, Feature-Wünsche und Pull Requests sind willkommen. Ob eine Quelldatenbank, deren Connector noch Lücken hat, oder ein Sonderfall, an dem die Konvertierung scheitert — ein Issue auf GitHub ist der richtige Anfang. Details finden Sie unter Mitmachen.\n","externalUrl":null,"permalink":"/de/","section":"credativ-pg-migrator","summary":" Legacy-Datenbanken nach PostgreSQL migrieren credativ-pg-migrator überführt Schemata, Daten, Constraints, Routinen und Views aus proprietären und Legacy-Datenbanksystemen nach PostgreSQL — mit einem Migrationsprotokoll und einer Verifikation nach der Migration, die genau zeigen, was angekommen ist. ","title":"credativ-pg-migrator","type":"page"},{"content":"Diese Seite gibt Ihnen einen Überblick zur ersten Orientierung. Die vollständige, gepflegte Dokumentation liegt im Repository — der User Guide beschreibt jeden Connector, jede Option und jede Einschränkung im Detail.\nFunktionsweise # credativ-pg-migrator ist ein Offline-Migrationswerkzeug. Es verbindet sich mit der Quelldatenbank, analysiert das Datenmodell, erzeugt PostgreSQL-kompatible Strukturen und schreibt diese in die Zielinstanz. Es ist dafür ausgelegt, während eines Wartungsfensters bzw. Read-only-Fensters auf der Quelle zu laufen, und nicht als Lösung für eine Live-Replikation.\nIn der Praxis wird die Migrationsgeschwindigkeit durch Hardware und Netzanbindung begrenzt — die Erfahrung zeigt, dass in der Regel der Server der Quelldatenbank der Engpass ist und nicht der Migrator.\nKomponenten # Komponente Aufgabe Parser Liest die YAML-Konfigurationsdatei und die Kommandozeilenargumente. Planner Liest Metadaten und Objektdefinitionen aus der Quelle und überführt sie in ihre PostgreSQL-Entsprechungen. Orchestrator Führt die Migrationsschritte aus und koordiniert die parallelen Worker. Worker Führen den Datentransfer und das Anlegen der Objekte parallel aus. Die drei Datenbanken # An einer Migration sind immer drei logische Datenbanken beteiligt:\nQuelldatenbank — jedes unterstützte System, angebunden über ODBC, JDBC oder einen nativen Python-Treiber. Es muss sich dabei nicht um einen Server handeln: Eine SQLite-Quelle ist eine einfache lokale Datei, und eine DB2-z/OS-Quelle kann aus einer Sammlung von Offline-DDL- und CSV-Dateien bestehen. Zieldatenbank — die PostgreSQL-Instanz, in der das migrierte Schema und die Daten angelegt werden. PostgreSQL ist das einzige unterstützte Ziel. Migrationsdatenbank — eine PostgreSQL-Datenbank, die das Migrationsprotokoll aufnimmt: jedes migrierte Objekt mit seinem Quellcode, dem erzeugten PostgreSQL-Code sowie einer Erfolgs- oder Fehlermarkierung mit Zeitstempeln. Üblicherweise ist dies die Zieldatenbank selbst, es kann aber auch eine separate Datenbank sein. Installation # Python-Paket # python3 -m venv migrator_venv . ./migrator_venv/bin/activate pip install credativ-pg-migrator Das Paket ist auf PyPI verfügbar: pypi.org/project/credativ-pg-migrator.\nDebian und Ubuntu # credativ-pg-migrator ist Bestandteil des PostgreSQL-Community-Repositories apt.postgresql.org. Wie Sie dieses einbinden, beschreibt die PostgreSQL-APT-Wikiseite.\nJe nach Quelldatenbank benötigen Sie zusätzlich den passenden ODBC- oder JDBC-Treiber. Die Ausnahme ist SQLite — hier ist überhaupt keine Treiberinstallation erforderlich.\nKonfiguration # Der Migrator wird über eine einzige YAML-Datei gesteuert. Diese beschreibt die Quelle, das Ziel, die Migrationsdatenbank, welche Objekte migriert werden sollen und wie sie zu konvertieren sind.\nAm schnellsten kommen Sie zum Ziel, wenn Sie das fertige Beispiel für Ihr Quellsystem aus docs/configs/ kopieren und jede mit \u0026gt;\u0026gt;\u0026gt; ADJUST markierte Zeile anpassen.\nEine Konfigurationsdatei umfasst typischerweise:\nEinstellungen der Quelle — Systemtyp, Host, Port, Datenbank, Zugangsdaten, Art der Anbindung (odbc, jdbc, ddl oder nativ) sowie Angaben zu Treiber, JAR-Datei bzw. DSN. Einstellungen des Ziels — PostgreSQL-Verbindungsdaten und das Standardschema für die migrierten Objekte. Einstellungen der Migrationsdatenbank — wo die Protokolltabellen angelegt werden. Objektauswahl — welche Schemata migriert werden sollen, Einschluss- und Ausschlusslisten für Tabellen, Views, Sequenzen und Routinen. Optionen für den Datentransfer — WHERE-Filter je Tabelle, Batch-Größen, Konfliktbehandlung und der Umgang mit Fremdschlüsseln während des Ladevorgangs. Abbildung von Datentypen und Default-Werten — Regeln, die Datentypen der Quelle und herstellerspezifische Default-Ausdrücke auf PostgreSQL-Entsprechungen abbilden. config_all_options_reference.yaml dokumentiert sämtliche vorhandenen Optionen und ist die maßgebliche Referenz — aber keine Vorlage. Die Datei führt sich gegenseitig ausschließende Optionen nebeneinander auf und lässt sich daher nicht unverändert als Konfigurationsdatei verwenden. Eine Migration durchführen # credativ-pg-migrator \\ --config=./my_migration.yaml \\ --log-file=./my_migration_$(date +%Y%m%d).log \\ --log-level=INFO Die Protokollierung erfolgt sowohl auf der Konsole als auch in der Logdatei. Es stehen zwei Detailstufen zur Verfügung, INFO und DEBUG; im Fehlerfall wird eine ausführliche Meldung ausgegeben. Parallel dazu werden umfangreiche Informationen in die Migrationsdatenbank geschrieben.\nEin typisches Migrationsprojekt # PostgreSQL vorbereiten. Richten Sie die Zielinstanz ein und entscheiden Sie, ob die Migrationsdatenbank dieselbe Datenbank oder eine separate ist. Anbindung vorbereiten. Installieren Sie die benötigten JDBC-, ODBC- oder nativen Treiber und prüfen Sie die Verbindung unabhängig davon — etwa mit isql für ODBC —, bevor Sie den Migrator einsetzen. Konfiguration erstellen. Beginnen Sie mit dem Beispiel für Ihr Quellsystem, tragen Sie die Verbindungsdaten ein, wählen Sie Schemata und Tabellen aus und ergänzen Sie die benötigten Typ- und Default-Abbildungen sowie Datenfilter. Testmigration durchführen gegen ein Ziel außerhalb der Produktion mit der Stufe INFO. Prüfen Sie die Logausgabe, die Protokolltabellen in der Migrationsdatenbank sowie das entstandene Schema und die Daten. Anpassen und erneut ausführen. Verfeinern Sie Abbildungen, Filter und Objektauswahl, bis das Ergebnis Ihren Erwartungen entspricht. Produktivmigration durchführen während eines Wartungsfensters bzw. Read-only-Fensters auf der Quelle, das Ergebnis validieren und anschließend die Anwendungen auf PostgreSQL umstellen. Die Migrationsdatenbank # Das Migrationsprotokoll ist eine der zentralen Stärken des Werkzeugs. Für jedes migrierte Objekt hält es die Namen in Quelle und Ziel fest, das zum Anlegen des Zielobjekts verwendete SQL, den Status (erfolgreich, übersprungen, Fehler) sowie Zeitstempel — für Tabellen, Indizes, Fremdschlüssel, Views, Sequenzen und für Funktionen, Prozeduren und Trigger einschließlich ihres ursprünglichen Quellcodes und des erzeugten PostgreSQL-Codes.\nDas ermöglicht Ihnen:\nexakt nachzuvollziehen, was auf welche Weise migriert wurde; den Quellcode mit dem erzeugten PL/pgSQL zu vergleichen — der praktikable Weg, die Best-Effort-Konvertierungen zu prüfen, bevor Sie ihnen vertrauen; einzelne Objekte erneut zu migrieren oder manuell zu korrigieren, ohne die gesamte Migration zu wiederholen. Behandeln Sie die Migrationsdatenbank als Metadaten mit Lesezugriff: Fragen Sie sie beliebig ab, ändern Sie ihre Tabellen aber nicht direkt.\nValidierung nach der Migration # Der Migrator bringt eine Validierungs-Engine mit, die das Ziel unabhängig von der Migration selbst gegen die Quelle prüft:\nZeilenanzahlen und Prüfsummen über die gesamte Tabelle für jede Quelle mit einer Live-Verbindung. Hashwerte zufällig ausgewählter Zeilen und LOB-Bytegrößen (derzeit für Quellen mit Oracle, PostgreSQL und SQLite). Struktureller Vergleich der Anzahl von Spalten, Indizes und Constraints, festgehalten in den Protokolltabellen validation_tables, validation_indexes und validation_constraints. Die Ergebnisse werden als Zusammenfassung in Markdown mit gegenübergestellten Tabellen ausgegeben; jede Abweichung markiert die Validierung der betroffenen Tabelle als fehlgeschlagen.\nWeiterführende Informationen # User Guide \u0026amp; Anbindungsoptionen — Status, Anbindung und Einschränkungen je Connector Funktionsmatrix — welche Funktion von welchem Connector unterstützt wird Standard-Migrationsworkflow Konfigurationsbeispiele Übersicht der Konfigurationsparameter ","externalUrl":null,"permalink":"/de/docs/","section":"credativ-pg-migrator","summary":"Diese Seite gibt Ihnen einen Überblick zur ersten Orientierung. Die vollständige, gepflegte Dokumentation liegt im Repository — der User Guide beschreibt jeden Connector, jede Option und jede Einschränkung im Detail.\nFunktionsweise # credativ-pg-migrator ist ein Offline-Migrationswerkzeug. Es verbindet sich mit der Quelldatenbank, analysiert das Datenmodell, erzeugt PostgreSQL-kompatible Strukturen und schreibt diese in die Zielinstanz. Es ist dafür ausgelegt, während eines Wartungsfensters bzw. Read-only-Fensters auf der Quelle zu laufen, und nicht als Lösung für eine Live-Replikation.\n","title":"Dokumentation","type":"page"},{"content":"Wie vollständig eine Migration ausfällt, hängt stark von der Quelldatenbank ab. Die folgende Tabelle zeigt den Status je Connector und Funktion. Sie entspricht der Datei FEATURE_MATRIX.md im Repository, die die maßgebliche Fassung ist und mit den Quelltexten der Connectoren abgeglichen wird — jeder Eintrag entspricht tatsächlich vorhandenem Code, nicht einer Planung.\nLegende # Symbol Bedeutung yes Unterstützt und erfolgreich getestet ? Grundsätzlich implementiert, für diese konkrete Datenbank aber unzureichend getestet WIP In Arbeit, noch nicht unterstützt -- Noch nicht implementiert N/A Von dieser Quelldatenbank nicht unterstützt (* = bedarf genauerer Prüfung) Das Schwierigste daran, ein ? zu einem yes zu machen, ist meist, eine Testdatenbank zu finden, die die betreffende Funktion in realistischer Weise einsetzt.\nUnterstützung je Connector # Abkürzungen der Spalten: DB2 LUW / z/OS / i = IBM-DB2-Varianten, MSSQL = MS SQL Server, SQL Any. = SQL Anywhere, Sybase = Sybase ASE.\nFunktion DB2 LUW DB2 z/OS DB2 i Informix MSSQL MySQL MariaDB Oracle PostgreSQL SQL Any. SQLite Sybase Analyse vor der Migration WIP \u0026ndash;[9] \u0026ndash;[9] yes WIP WIP WIP WIP WIP WIP yes WIP Datenmigration yes yes[9] yes[9] yes yes yes yes yes yes yes yes yes NOT NULL-Constraints yes yes yes yes yes yes yes yes yes yes yes yes Default-Werte auf Spalten yes yes yes WIP yes yes yes yes yes yes yes yes[4] IDENTITY-Spalten yes yes yes yes yes yes yes yes[1] yes yes yes[8] yes Berechnete (generierte) Spalten \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes yes yes yes \u0026ndash; yes[8] yes[5] Eigene Datentyp-Ersetzungen yes yes yes yes yes yes yes yes yes yes yes yes Implizite Default-Ersetzungen[6] yes yes yes \u0026ndash; yes yes yes yes N/A yes yes yes Eigene Ersetzungen von Default-Werten yes yes yes yes yes yes yes yes yes yes yes yes Primärschlüssel yes yes yes yes yes yes yes yes yes yes yes yes Sekundärindizes yes yes yes yes yes yes yes yes yes yes yes[8] yes Fremdschlüssel yes yes yes yes yes yes yes yes yes yes yes yes FK ON DELETE-Aktion \u0026ndash; yes yes \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes yes \u0026ndash; yes N/A* Check-Constraints yes yes yes yes \u0026ndash; \u0026ndash; \u0026ndash; ?[7] yes \u0026ndash; yes[8] yes Check-Regeln / Domains[3] \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; N/A N/A ?[7] ? \u0026ndash; N/A yes Benutzerdefinierte Datentypen \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; ? N/A N/A ?[7] yes \u0026ndash; N/A yes Benutzerdefinierte Collations[12] \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes \u0026ndash; N/A \u0026ndash; Objekte der Volltextsuche[13] \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes \u0026ndash; N/A \u0026ndash; Benutzerdefinierte Aggregate[14] \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; N/A N/A \u0026ndash; yes \u0026ndash; N/A \u0026ndash; Kommentare auf Spalten yes \u0026ndash;[9] \u0026ndash;[9] N/A* \u0026ndash; yes yes ?[7] yes \u0026ndash; N/A N/A* Kommentare auf Tabellen yes \u0026ndash;[9] \u0026ndash;[9] N/A* \u0026ndash; yes yes ?[7] yes \u0026ndash; N/A N/A* Migration von Views ? ? ? WIP ? WIP WIP ?[7] yes WIP ?[8] ? Konvertierung von Funktionen / Prozeduren \u0026ndash; ? \u0026ndash; yes ? \u0026ndash; \u0026ndash; ?[7] yes \u0026ndash; N/A ? Konvertierung von Triggern ? ? ? yes ? \u0026ndash; \u0026ndash; ?[7] yes \u0026ndash; ?[8] ? Sequenzen[2] ? ? ? \u0026ndash; ? N/A ?[10] ?[7] yes \u0026ndash; N/A N/A* Aliase / Synonyme ? ? ? ? ? N/A N/A ? N/A \u0026ndash; N/A N/A Mapping von SQL-Funktionen[11] WIP WIP WIP WIP WIP WIP WIP WIP N/A WIP WIP WIP Validierung — Zeilenzahlen \u0026amp; Prüfsummen yes yes \u0026ndash;[9] yes yes yes yes yes yes yes yes yes Validierung — Zufallsstichprobe \u0026amp; LOB-Größen \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; \u0026ndash; yes yes \u0026ndash; yes \u0026ndash; Anmerkungen # IDENTITY-Spalten (Oracle). Werden anhand der als Default-Wert verwendeten Sequenz erkannt. Die Datentypen bleiben ein Problem: Oracle erlaubt einen Primärschlüssel auf NUMBER mit einer Sequenz, während eine PostgreSQL-Identity-Spalte INT oder BIGINT sein muss. Sequenzen. Bei den meisten Engines werden sie nicht als eigenständige Objekte migriert. SERIAL/BIGSERIAL, Identity-Spalten und Spalten mit einer Sequenz als Default werden zu PostgreSQL-Identity-Spalten; die Sequenz wird also automatisch angelegt und ihr aktueller Wert anschließend aus den migrierten Daten gesetzt. Oracle migriert zusätzlich eigenständige Sequenzen als unabhängige PostgreSQL-Sequenzen (siehe Anmerkung 7). Check-Regeln / Domains. Extern definierte Prüfungen, die an eine Spalte oder einen Datentyp gebunden sind — Domains in PostgreSQL, Rules in einigen anderen Engines. Derzeit für Sybase ASE in Umsetzung. Defaults in Sybase ASE. CREATE DEFAULT erzeugt einen benannten Default, der an mehrere Spalten gebunden werden kann. PostgreSQL kennt dazu kein Gegenstück, daher wird der zugrunde liegende Default-Wert direkt an jede Zielspalte gehängt. Berechnete Spalten in Sybase ASE. Sybase legt für funktionsbasierte Indizes verborgene berechnete Spalten an (z. B. sybfi4_1 AS LOWER(ProductName) MATERIALIZED), was auch die in den Systemtabellen hinterlegte Index-DDL verändert. Implizite Default-Ersetzungen. Gängige Default-Werte, deren Syntax PostgreSQL nicht akzeptiert, werden während der Migration implizit ersetzt. Oracle. Check-Constraints, eigenständige Sequenzen, benutzerdefinierte Datentypen, Domains, Tabellen- und Spaltenkommentare, Views und materialisierte Views sowie eine PL/SQL-Konvertierung nach bestem Bemühen sind implementiert, jedoch noch nicht gegen eine laufende Datenbank verifiziert. Die PL/SQL-Konvertierung arbeitet heuristisch: Packages werden in eigenständige Funktionen \u0026lt;package\u0026gt;_\u0026lt;routine\u0026gt; aufgeteilt und die Aufrufstellen umgeschrieben (der Package-Zustand wird nicht migriert), Trigger werden zu einer PL/pgSQL-Triggerfunktion plus CREATE TRIGGER, und komplexe Konstrukte werden zur manuellen Nachbearbeitung markiert. Objekttypen werden zu zusammengesetzten Typen; Collection-Typen (VARRAY, verschachtelte Tabellen) werden zu Array-basierten Domains. SQLite. SQLite besitzt für mehrere dieser Objekte kein Data Dictionary, daher werden Check-Constraints, Ausdrücke generierter Spalten, AUTOINCREMENT-Markierungen und Ausdrücke funktionaler Indizes aus den CREATE-Anweisungen in sqlite_master herausgelesen. Views, Trigger und Ausdrücke werden mit sqlglot und einem SQLite-spezifischen Funktions-Mapping übersetzt. Partielle Indizes verlieren ihre WHERE-Bedingung (sie wird im Indexkommentar festgehalten), und ein partieller Unique-Index wird zu einem nicht eindeutigen Index herabgestuft. Virtuelle Tabellen (FTS, RTREE, …) und ihre Shadow-Tabellen werden übersprungen. Da SQLite dynamisch typisiert ist, werden die Werte während der Datenmigration in den Typ der Zielspalte überführt. IBM DB2 z/OS und DB2 for i. Dies sind offline-Connectoren — sie verbinden sich nie mit der Quellinstanz. Die Struktur wird aus .sql/DDL-Extrakten (connectivity: \u0026quot;ddl\u0026quot;) gelesen, die Daten aus quellseitig erzeugten CSV-Dateien. Alles, was eine laufende Quelle voraussetzt (Analyse vor der Migration, Validierung per Zufallsstichprobe und LOB-Größen), steht daher nicht zur Verfügung. COMMENT ON- und LABEL ON-Anweisungen werden aus der DDL gelesen und in den Protokolltabellen abgelegt, aber noch nicht auf das Ziel angewendet. MySQL und MariaDB. Getrennte, weitgehend identische Connectoren. MariaDB migriert zusätzlich eigenständige SEQUENCE-Objekte (MariaDB 10.3+). Funktionen, Prozeduren und Trigger konvertiert keiner von beiden. Mapping von SQL-Funktionen. Jeder Connector bringt ein Mapping gängiger SQL-Funktionen der Quelle auf PostgreSQL-Entsprechungen mit, das bei der Konvertierung von Defaults, Views, Constraints und Routinenrümpfen angewendet wird. Der Abdeckungsgrad unterscheidet sich je Engine und wird bei Bedarf erweitert — daher überall WIP. Für eine PostgreSQL-Quelle ist kein Mapping erforderlich. Benutzerdefinierte Collations. Eigenständige CREATE COLLATION-Objekte, die von Spalten und Indizes referenziert werden; migriert für eine PostgreSQL-Quelle (ICU- und libc-Provider, Locale, Tailoring-Regeln, nicht-deterministische Collations, Kommentar). Collations anderer Engines (utf8mb4_general_ci, Latin1_General_CI_AS, …) haben kein PostgreSQL-Gegenstück, daher wird die Referenz verworfen und die Spalte behält den Default der Zieldatenbank. Objekte der Volltextsuche. Wörterbücher und Textsuchkonfigurationen, die von generierten tsvector-Spalten, Views, Indizes und Funktionen referenziert werden. Migriert für eine PostgreSQL-Quelle einschließlich des vollständigen Mappings der Token-Typen; Referenzen innerhalb von 'name'::regconfig-Literalen werden umgeschrieben. Objekte, die zu einer Extension gehören, werden nicht migriert — sie kommen mit der Extension. Benutzerdefinierte Aggregate. CREATE AGGREGATE-Objekte, migriert für eine PostgreSQL-Quelle samt ihrer Übergangs-, Abschluss-, Parallel- und Moving-Aggregate-Hilfsfunktionen, Startwerte, Sortieroperatoren und Parallelitätssicherheit. Sie werden nach den Funktionen und Prozeduren angelegt, die sie referenzieren. Aggregate aus einer Extension werden nicht migriert. Getestete Datenbankversionen # Quelldatenbank Getestete Version IBM DB2 LUW aktuellste IBM DB2 z/OS DDL- + CSV-Extrakte (offline, keine laufende Instanz) IBM DB2 for i DDL- + CSV-Extrakte (offline, keine laufende Instanz) Informix 14.10 MS SQL Server 2022 MySQL 5.7 MariaDB noch nicht gegen eine laufende Instanz verifiziert Oracle 21.3 PostgreSQL 14, 17 SQL Anywhere 17 SQLite 3.46 Sybase ASE 16.0 Fehlt Ihnen eine Quelldatenbank oder eine Funktion, die Sie benötigen? Unterstützung dafür kann bei Bedarf ergänzt werden — siehe Mitmachen.\n","externalUrl":null,"permalink":"/de/features/","section":"credativ-pg-migrator","summary":"Wie vollständig eine Migration ausfällt, hängt stark von der Quelldatenbank ab. Die folgende Tabelle zeigt den Status je Connector und Funktion. Sie entspricht der Datei FEATURE_MATRIX.md im Repository, die die maßgebliche Fassung ist und mit den Quelltexten der Connectoren abgeglichen wird — jeder Eintrag entspricht tatsächlich vorhandenem Code, nicht einer Planung.\n","title":"Funktionsmatrix","type":"page"},{"content":"credativ-pg-migrator ist Open Source unter der GPLv3 und wird offen entwickelt. Beiträge sind willkommen — und sie müssen nicht aus Code bestehen.\nEin Problem melden # Der wertvollste Beitrag ist ein gut beschriebener Fehlerfall. Legacy-Datenbanken sind unerschöpflich einfallsreich, und die Konvertierungslogik kann nur abdecken, was sie bereits gesehen hat.\nEröffnen Sie ein Issue auf GitHub und geben Sie dabei an:\ndie Engine und Version der Quelldatenbank sowie den verwendeten Konnektivitätstyp (odbc, jdbc, ddl oder nativ); den relevanten Teil Ihrer Konfigurationsdatei — ohne Zugangsdaten; die Log-Ausgabe rund um den Fehler (--log-level=DEBUG liefert deutlich mehr Details); bei einem Konvertierungsproblem die ursprüngliche Objektdefinition und den erzeugten PostgreSQL-Code. Beides liegt nebeneinander in den Protokolltabellen der Migrationsdatenbank und lässt sich von dort leicht auslesen. Code beitragen # Pull Requests sind willkommen — für einen neuen Connector für eine Quelldatenbank, für eine bessere Abdeckung eines bestehenden Connectors oder für die Korrektur eines Sonderfalls bei der Konvertierung.\nEin Connector für eine Quelldatenbank implementiert die Klasse DatabaseConnector aus dem Modul credativ_pg_migrator.database_connector. Ihre Methoden dokumentieren das erwartete Verhalten und die Rückgabewerte, sodass diese Klasse der richtige Ausgangspunkt ist, wenn Sie eine weitere Engine ergänzen möchten. Quellen werden über ODBC, JDBC oder native Python-Bibliotheken angebunden — nicht jede Option steht für jede Engine zur Verfügung.\nDie Funktionsmatrix zeigt gut, wo die Lücken liegen: Jedes --, WIP und ? steht für Arbeit, die noch nicht erledigt oder noch nicht verifiziert ist. Insbesondere die ?-Einträge scheitern meist an einer einzigen Sache — daran, eine Testdatenbank zu finden, die die betreffende Funktion realistisch nutzt. Wenn Sie über ein solches Schema verfügen, ist allein das schon ein echter Beitrag.\nDie Dokumentation verbessern # Die Dokumentation liegt im Verzeichnis docs/ des Repositorys, direkt neben dem Code. Wenn bei Ihrer Migration etwas unklar war oder gefehlt hat, hilft ein Pull Request auf diese Dateien der nächsten Person weiter.\nProfessioneller Support # Wenn Sie eine Migration planen und diese lieber durchführen lassen möchten, statt sie selbst zu übernehmen: Die credativ GmbH bietet professionellen Support für PostgreSQL und Datenbankmigrationen — von der Bewertung des Quellsystems bis zur Durchführung der Migration.\nNehmen Sie Kontakt mit credativ auf.\nAutoren und Lizenz # credativ-pg-migrator wurde maßgeblich von Josef Machytka bei der credativ GmbH entwickelt und wird von ihm gepflegt — die vollständige Liste finden Sie in AUTHORS.\nDas Projekt steht unter der GNU General Public License, Version 3 (oder einer späteren Version). Den vollständigen Text finden Sie in COPYING.\n","externalUrl":null,"permalink":"/de/get-involved/","section":"credativ-pg-migrator","summary":"credativ-pg-migrator ist Open Source unter der GPLv3 und wird offen entwickelt. Beiträge sind willkommen — und sie müssen nicht aus Code bestehen.\nEin Problem melden # Der wertvollste Beitrag ist ein gut beschriebener Fehlerfall. Legacy-Datenbanken sind unerschöpflich einfallsreich, und die Konvertierungslogik kann nur abdecken, was sie bereits gesehen hat.\n","title":"Mitmachen","type":"page"},{"content":"","externalUrl":null,"permalink":"/de/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"}]