PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Migration de DB2 vers PostgreSQL - Ce que vous devez savoir

Que la migration d'une base de données ou d'une application de DB2 vers PostgreSQL avec un seul type de connaissance de la base de données ne soit pas suffisante, il y a peu de choses à savoir sur les différences entre les deux systèmes de base de données.

PostgreSQL est la base de données open source avancée la plus utilisée au monde. La base de données PostgreSQL possède un riche ensemble de fonctionnalités et la communauté PostgreSQL est très forte et ils améliorent continuellement les fonctionnalités existantes et ajoutent de nouvelles fonctionnalités. Selon db-engine.com, PostgreSQL est le SGBD de l'année 2017 et 2018.

Comme vous le savez, DB2 et PostgreSQL sont des SGBDR mais il existe des incompatibilités. Dans ce blog, nous pouvons voir certaines de ces incompatibilités.

Pourquoi migrer de DB2 vers PostgreSQL

  1. Licences Open Source flexibles et disponibilité aisée auprès de fournisseurs de cloud public tels qu'AWS, Google Cloud et Microsoft Azure
  2. Bénéficiez de modules complémentaires open source pour améliorer les performances de la base de données.

Vous pouvez voir dans l'image ci-dessous que la popularité de PostgreSQL augmente avec le temps par rapport à DB2.

Intérêt au fil du temps

Évaluation de la migration

La première étape de la migration consiste à analyser l'application et l'objet de la base de données, à rechercher les incompatibilités entre les deux bases de données et à estimer le temps et le coût requis pour la migration.

Mappage des types de données

Certains des types de données d'IBM DB2 ne correspondent pas directement aux types de données PostgreSQL, vous devez donc le remplacer par le type de données PostgreSQL correspondant.

Veuillez vérifier le tableau ci-dessous.

IBM DB2 PostgreSQL
BIGINT Entier 64 bits BIGINT
BLOB(n) Grand objet binaire BYTEA
CLOB(n) Grand objet de personnage TEXTE
DBCLOB(n) Grand objet UTF-16 caractères TEXTE
NCLOB(n) Grand objet UTF-16 caractères TEXTE
CARACTÈRE(n), CARACTÈRE(n) Chaîne de longueur fixe CHAR(n)
CARACTÈRE VARIANT(n) Chaîne de longueur variable VARCHAR(n)
NCHAR(n) Chaîne UTF-16 de longueur fixe CHAR(n)
NCHAR VARIANT(n) Chaîne UTF-16 de longueur variable VARCHAR(n)
VARCHAR(n) Chaîne de longueur variable VARCHAR(n)
VARGRAPHIC(n) Chaîne UTF-16 de longueur variable VARCHAR(n)
VARCHAR(n) POUR LES DONNÉES BIT Chaîne d'octets de longueur variable BYTEA
NVARCHAR(n) Chaîne UTF-16 de longueur variable VARCHAR(n)
GRAPHIQUE(n) Chaîne UTF-16 de longueur fixe CHAR(n)
ENTIER Entier 32 bits ENTIER
NUMÉRIQUE(p,s) Numéro à virgule fixe NUMÉRIQUE(p,s)
DECIMAL(p,s) Numéro à virgule fixe DECIMAL(p,s)
DOUBLE PRÉCISION Nombre à virgule flottante double précision DOUBLE PRÉCISION
FLOAT(p) Nombre à virgule flottante double précision DOUBLE PRÉCISION
RÉEL Nombre à virgule flottante simple précision RÉEL
SMALLINT Entier 16 bits SMALLINT
DATE Date(année, mois et jour) DATE
HEURE TIME (heure, minute et seconde) HEURE(0)
TIMESTAMP(p) Date et heure avec fraction TIMESTAMP(p)
DECFLOAT(16 | 34) Numéro à virgule flottante IEEE FLOAT

Incompatibilités dans DB2 et PostgreSQL

Il existe de nombreuses incompatibilités présentes dans DB2 et PostgreSQL, vous pouvez en voir quelques-unes ici. Vous pouvez les automatiser en créant des extensions afin que vous puissiez utiliser la fonction DB2 telle qu'elle est dans PostgreSQL et que vous puissiez gagner du temps. Veuillez vérifier le comportement de la fonction DB2 dans PostgreSQL

TABLESPACE

La clause TABLESPACE définit le nom de l'espace de table dans lequel réside la table nouvellement créée.

DB2 utilise la clause IN pour TABLESPACE, elle doit donc être remplacée par la clause TABLESPACE dans PostgreSQL.

Exemple :

DB2 :

IN <tablespace_name>

PostgreSQL :

TABLESPACE <tablespace_name>

FIRST FETCH n ROWS UNIQUEMENT

Dans DB2, vous pouvez utiliser la clause FETCH FIRST n ROWS ONLY pour extraire au maximum n lignes. Dans PostgreSQL, vous pouvez utiliser LIMIT n qui équivaut à FETCH FIRST n ROWS ONLY.

Exemple :

DB2 :

SELECT * FROM EMP
 ORDER BY EMPID
 FETCH FIRST 10 ROWS ONLY;

PostgreSQL :

SELECT * FROM EMP
 ORDER BY EMPID
 LIMIT 10;

GÉNÉRÉ PAR DÉFAUT COMME IDENTITÉ

La colonne IDENTITY dans DB2 peut être remplacée par la colonne Serial dans PostgreSQL.

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
);

Sélectionner à partir de SYSIBM.SYSDUMMY1

Il n'y a pas de table « SYSIBM.SYSDUMMY1 » dans PostgreSQL. PostgreSQL autorise une clause "SELECT" sans "FROM". Vous pouvez supprimer cela en utilisant un script.

Fonctions scalaires :DB2 vs PostgreSQL

PLAFOND/PLAFOND

CEIL ou CEILING renvoie la plus petite valeur entière suivante supérieure ou égale à l'entrée (par exemple, CEIL(122.89) renvoie 123, et CEIL(122.19) renvoie également 123).

DB2 :

SELECT CEIL(123.89) FROM SYSIBM.SYSDUMMY1; 
SELECT CEILING(123.89) FROM SYSIBM.SYSDUMMY1;

PostgreSQL :

SELECT CEIL(123.89) ; 
SELECT CEILING(123.89) ;

DATE

Il convertit l'entrée en valeurs de date. Vous pouvez convertir la fonction DATE en fonction TO_DATE dans PostgreSQL.

DB2 :

SELECT DATE ('2018-09-21') FROM SYSIBM.SYSDUMMY1;

PostgreSQL :

SELECT TO_DATE ('21-09-2018',’DD-MM-YYYY’) ;

JOUR

Il renvoie la partie jour (jour du mois) d'une date ou d'une valeur équivalente. Le format de sortie est entier.

DB2 :

SELECT DAY (DATE('2016-09-21')) FROM SYSIBM.SYSDUMMY1;

PostgreSQL :

SELECT DATE_PART('day', '2016- 09-21'::date);

MOIS

Il renvoie la partie mois de la valeur de date. Le format de sortie est entier.

DB2 :

SELECT MONTH (DATE('2016-09-21')) FROM SYSIBM.SYSDUMMY1;

PostgreSQL :

SELECT DATE_PART ('month', '2016-09- 21'::date);

POSSTR

Renvoie la position de la chaîne. La fonction POSSTR est remplacée par la fonction POSITION dans PostgreSQL.

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

Il renvoie une valeur à virgule flottante pseudo-aléatoire comprise entre zéro et un inclus. Vous pouvez remplacer la fonction RAND par RANDOM dans PostgreSQL.

DB2 :

SELECT RAND() FROM SYSIBM.SYSDUMMY1;

PostgreSQL :

SELECT RANDOM();
Téléchargez le livre blanc aujourd'hui PostgreSQL Management &Automation with ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blanc

Outils

Vous pouvez utiliser certains outils pour migrer la base de données DB2 vers PostgreSQL. Veuillez tester l'outil avant de l'utiliser.

  1. Db2topg

    Il s'agit d'un outil automatisé pour la migration de DB2 vers PostgreSQL comme ora2pg. Les scripts de l'outil db2pg convertissent autant que possible une base de données DB2 UDB. Cet outil ne fonctionne pas avec DB2 zOS. Il est très simple à utiliser, vous avez besoin d'un vidage SQL de votre schéma, puis utilisez le script db2pg pour le convertir en schéma PostgreSQL.

  2. Conversion complète

    L'outil d'entreprise copie rapidement la base de données DB2 vers PostgreSQL. La conversion de DB2 en base de données PostgreSQL à l'aide de l'outil Full Convert est très simple.
    Étapes :

    • Se connecter à la base de données source, c'est-à-dire DB2
    • Facultatif :Choisissez les tableaux que vous souhaitez convertir (par défaut tous les tableaux sélectionnés)
    • Démarrez la conversion.

Conclusion

Comme nous avons pu le voir, migrer de DB2 vers PostgreSQL n'est pas sorcier, mais nous devons garder à l'esprit ce que nous avons vu précédemment pour éviter de gros problèmes dans notre système. Il suffit donc d'être prudent dans la tâche et d'aller de l'avant, vous pouvez migrer vers la base de données open source la plus avancée et profiter de ses avantages.