Unabhängig davon, ob die Migration einer Datenbank oder einer Anwendung von DB2 zu PostgreSQL mit nur einer Art von Datenbankkenntnissen nicht ausreicht, gibt es einige Dinge, die man über die Unterschiede zwischen den beiden Datenbanksystemen wissen sollte.
PostgreSQL ist die weltweit am weitesten verbreitete erweiterte Open-Source-Datenbank. Die PostgreSQL-Datenbank verfügt über einen umfangreichen Funktionsumfang und die PostgreSQL-Community ist sehr stark und verbessert kontinuierlich die vorhandenen Funktionen und fügt neue Funktionen hinzu. Laut db-engine.com ist PostgreSQL das DBMS des Jahres 2017 und 2018.
Wie Sie wissen, sind DB2 und PostgreSQL RDBMS, aber es gibt einige Inkompatibilitäten. In diesem Blog können wir einige dieser Inkompatibilitäten sehen.
Warum von DB2 zu PostgreSQL migrieren
- Flexible Open-Source-Lizenzierung und einfache Verfügbarkeit von öffentlichen Cloud-Anbietern wie AWS, Google Cloud, Microsoft Azure.
- Profitieren Sie von Open-Source-Add-ons, um die Datenbankleistung zu verbessern.
Sie können in der Abbildung unten sehen, dass die Popularität von PostgreSQL im Vergleich zu DB2 im Laufe der Zeit zunimmt.
Interesse im Laufe der Zeit
Migrationsbewertung
Der erste Schritt der Migration besteht darin, die Anwendung und das Datenbankobjekt zu analysieren, die Inkompatibilitäten zwischen den beiden Datenbanken herauszufinden und den Zeit- und Kostenaufwand für die Migration abzuschätzen.
Datentypzuordnung
Einige der Datentypen von IBM DB2 stimmen nicht direkt mit den PostgreSQL-Datentypen überein, daher müssen Sie sie in den entsprechenden PostgreSQL-Datentyp ändern.
Bitte überprüfen Sie die folgende Tabelle.
IBM DB2 | PostgreSQL | |
BIGINT | 64-Bit-Ganzzahl | GROSS |
BLOB(n) | Binäres großes Objekt | BYTEA |
CLOB(n) | Charakter großes Objekt | TEXT |
DBCLOB(n) | Großes UTF-16-Zeichenobjekt | TEXT |
NCLOB(n) | Großes UTF-16-Zeichenobjekt | TEXT |
ZEICHEN(n), ZEICHEN(n) | String mit fester Länge | CHAR(n) |
CHARACTER VARYING(n) | String variabler Länge | VARCHAR(n) |
NCHAR(n) | UTF-16-String mit fester Länge | CHAR(n) |
NCHAR VARYING(n) | UTF-16-String variabler Länge | VARCHAR(n) |
VARCHAR(n) | String variabler Länge | VARCHAR(n) |
VARGRAPHIC(n) | UTF-16-String variabler Länge | VARCHAR(n) |
VARCHAR(n) FÜR BITDATEN | Byte-String variabler Länge | BYTEA |
NVARCHAR(n) | UTF-16-String mit unterschiedlicher Länge | VARCHAR(n) |
GRAFIK(n) | UTF-16-String mit fester Länge | CHAR(n) |
INTEGER | 32-Bit-Ganzzahl | INTEGER |
NUMERIC(p,s) | Festkommazahl | NUMERIC(p,s) |
DEZIMAL(p,s) | Festkommazahl | DEZIMAL(p,s) |
DOPPELTE PRÄZISION | Gleitkommazahl mit doppelter Genauigkeit | DOPPELTE PRÄZISION |
FLOAT(p) | Gleitkommazahl mit doppelter Genauigkeit | DOPPELTE PRÄZISION |
ECHT | Gleitkommazahl mit einfacher Genauigkeit | ECHT |
SMALLINT | 16-Bit-Ganzzahl | SMALLINT |
DATUM | Datum (Jahr, Monat und Tag) | DATUM |
ZEIT | ZEIT (Stunde, Minute und Sekunde) | ZEIT(0) |
ZEITSTEMPEL(p) | Datum und Uhrzeit mit Bruch | ZEITSTEMPEL(p) |
DECFLOAT(16 | 34) | IEEE-Gleitkommazahl | SCHWEBEN |
Inkompatibilitäten in DB2 und PostgreSQL
Es gibt viele Inkompatibilitäten in DB2 und PostgreSQL, einige davon können Sie hier sehen. Sie können sie automatisieren, indem Sie Erweiterungen erstellen, sodass Sie die DB2-Funktion wie in PostgreSQL verwenden und Zeit sparen können. Bitte überprüfen Sie das Verhalten der DB2-Funktion in PostgreSQL
TABLESPACE
Die TABLESPACE-Klausel definiert den Namen des Tablespace, in dem sich die neu erstellte Tabelle befindet.
DB2 verwendet die IN-Klausel für TABLESPACE, daher sollte sie in PostgreSQL durch die TABLESPACE-Klausel ersetzt werden.
Beispiel:
DB2:
IN <tablespace_name>
PostgreSQL:
TABLESPACE <tablespace_name>
ZUERST NUR n ZEILEN ABRUFEN
In DB2 können Sie die Klausel FETCH FIRST n ROWS ONLY verwenden, um nicht mehr als n Zeilen abzurufen. In PostgreSQL können Sie LIMIT n verwenden, was äquivalent ist zu FETCH FIRST n ROWS ONLY.
Beispiel:
DB2:
SELECT * FROM EMP
ORDER BY EMPID
FETCH FIRST 10 ROWS ONLY;
PostgreSQL:
SELECT * FROM EMP
ORDER BY EMPID
LIMIT 10;
STANDARD ALS IDENTITÄT ERZEUGT
Die IDENTITY-Spalte in DB2 kann durch die Serial-Spalte in PostgreSQL ersetzt werden.
DB2:
CREATE TABLE <table_name> (
<column_name> INTEGER NOT NULL
GENERATED BY DEFAULT AS IDENTITY (START WITH 1, INCREMENT BY 1, CACHE 20)
);
PostgreSQL:
CREATE TABLE <table_name> (
<column_name> SERIAL NOT NULL
);
Aus SYSIBM.SYSDUMMY1 auswählen
In PostgreSQL gibt es keine Tabelle „SYSIBM.SYSDUMMY1“. PostgreSQL erlaubt eine „SELECT“-Klausel ohne „FROM“-Klausel. Sie können dies mithilfe von script.
entfernenSkalare Funktionen:DB2 vs. PostgreSQL
DECKE/DECKE
CEIL oder CEILING gibt den nächstkleineren ganzzahligen Wert zurück, der größer oder gleich der Eingabe ist (z. B. gibt CEIL(122,89) 123 zurück, auch CEIL(122,19) gibt 123 zurück).
DB2:
SELECT CEIL(123.89) FROM SYSIBM.SYSDUMMY1;
SELECT CEILING(123.89) FROM SYSIBM.SYSDUMMY1;
PostgreSQL:
SELECT CEIL(123.89) ;
SELECT CEILING(123.89) ;
DATUM
Es wandelt die Eingabe in Datumswerte um. Sie können die DATE-Funktion in PostgreSQL in die TO_DATE-Funktion konvertieren.
DB2:
SELECT DATE ('2018-09-21') FROM SYSIBM.SYSDUMMY1;
PostgreSQL:
SELECT TO_DATE ('21-09-2018',’DD-MM-YYYY’) ;
TAG
Es gibt den Tag (Tag des Monats) als Teil eines Datums oder einen entsprechenden Wert zurück. Das Ausgabeformat ist Integer.
DB2:
SELECT DAY (DATE('2016-09-21')) FROM SYSIBM.SYSDUMMY1;
PostgreSQL:
SELECT DATE_PART('day', '2016- 09-21'::date);
MONAT
Es gibt den Monatsteil des Datumswerts zurück. Das Ausgabeformat ist Integer.
DB2:
SELECT MONTH (DATE('2016-09-21')) FROM SYSIBM.SYSDUMMY1;
PostgreSQL:
SELECT DATE_PART ('month', '2016-09- 21'::date);
POSSTR
Gibt die Position der Zeichenfolge zurück. Die POSSTR-Funktion wird in PostgreSQL durch die POSITION-Funktion ersetzt.
DB2:
Usage : POSSTR(<Filed_1>,<Field2>)
SELECT POSSTR('PostgreSQL and DB2', 'and') FROM SYSIBM.SYSDUMMY1;
PostgreSQL:
Usage: POSITION(<Field_1> IN<Field_2>)
SELECT POSITION('and' IN'PostgreSQL and DB2');
RAND
Es gibt einen pseudozufälligen Gleitkommawert im Bereich von null bis einschließlich eins zurück. Sie können die RAND-Funktion in PostgreSQL durch RANDOM ersetzen.
DB2:
SELECT RAND() FROM SYSIBM.SYSDUMMY1;
PostgreSQL:
SELECT RANDOM();
Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunter Werkzeuge
Sie können einige Tools verwenden, um die DB2-Datenbank zu PostgreSQL zu migrieren. Bitte testen Sie das Tool, bevor Sie es verwenden.
-
Db2topg
Es ist ein automatisiertes Tool für die Migration von DB2 zu PostgreSQL wie ora2pg. Die Scripts im db2pg-Tool konvertieren so viel wie möglich von einer DB2 UDB-Datenbank. Dieses Tool funktioniert nicht mit DB2 zOS. Es ist sehr einfach zu verwenden, Sie benötigen einen SQL-Dump Ihres Schemas und verwenden dann das db2pg-Skript, um es in ein PostgreSQL-Schema zu konvertieren.
-
Vollständig konvertieren
Das Enterprise-Tool kopiert schnell die DB2-Datenbank nach PostgreSQL. Die Konvertierung der DB2- in die PostgreSQL-Datenbank mit dem Full Convert-Tool ist sehr einfach.
Schritte:- Verbinden Sie sich mit der Quelldatenbank, z. B. DB2
- Optional:Wählen Sie die Tabellen aus, die Sie konvertieren möchten (standardmäßig alle ausgewählten Tabellen)
- Konvertierung starten.
Schlussfolgerung
Wie wir sehen konnten, ist die Migration von DB2 zu PostgreSQL keine Raketenwissenschaft, aber wir müssen das im Hinterkopf behalten, was wir zuvor gesehen haben, um große Probleme in unserem System zu vermeiden. Also müssen wir bei der Aufgabe nur vorsichtig sein und loslegen, Sie können auf die fortschrittlichste Open-Source-Datenbank migrieren und ihre Vorteile nutzen.