PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Migration von DB2 zu PostgreSQL – Was Sie wissen sollten

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

  1. Flexible Open-Source-Lizenzierung und einfache Verfügbarkeit von öffentlichen Cloud-Anbietern wie AWS, Google Cloud, Microsoft Azure.
  2. 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.

entfernen

Skalare 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.

  1. 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.

  2. 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.