Migration d'Oracle vers PostgreSQL - Ce que vous devez savoir

Qu'il s'agisse de migrer une base de données ou une application d'Oracle vers PostgreSQL avec un seul type de connaissance des bases de données, il y a peu de choses à savoir sur les différences entre les deux systèmes de bases de données.

PostgreSQL est la base de données open source la plus avancée au monde. La communauté PostgreSQL est très forte et améliore continuellement les fonctionnalités PostgreSQL existantes et ajoute également de nouvelles fonctionnalités. Selon db-engines.com, PostgreSQL est le SGBD de l'année 2017.

Il existe des incompatibilités dans Oracle et PostgreSQL. Le comportement de certaines fonctions est différent entre Oracle et PostgreSQL.

Pourquoi migrer d'Oracle vers PostgreSQL

1. Coût :comme vous le savez peut-être, le coût d'une licence Oracle est très élevé et il y a un coût supplémentaire pour certaines fonctionnalités telles que le partitionnement et la haute disponibilité. Donc, dans l'ensemble, c'est très cher.
2. Licences open source flexibles et disponibilité aisée auprès de fournisseurs de cloud public tels qu'AWS.
3. Bénéficiez de modules complémentaires open source pour améliorer les performances.

Vérification préliminaire

Comme vous le savez peut-être, la migration d'Oracle vers PostgreSQL est une tâche coûteuse et chronophage. Il est important de comprendre quelle partie doit migrer. Ne perdez pas de temps à migrer des objets dont vous n'avez plus besoin. Vérifiez également si des données historiques sont requises ou non. Ne perdez pas de temps à répliquer les données dont vous n'avez pas besoin, par exemple les données de sauvegarde et la table temporaire d'une maintenance antérieure.

Évaluation de la migration

Après vérification préliminaire, 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.

L'outil Ora2pg est très utile pour l'évaluation de la migration. Il se connecte à la base de données Oracle, l'analyse automatiquement et extrait les données, générant le rapport de migration de la base de données. Vous pouvez consulter un exemple de rapport dans Ora2pg.

Ce que vous devez savoir

Comprenez les différences entre Oracle et PostgreSQL et convertissez-le à l'aide de n'importe quel outil. Il n'existe aucun outil capable de convertir une base de données Oracle à 100% en PostgreSQL, certaines modifications manuelles sont nécessaires. Veuillez vérifier ci-dessous certaines des différences importantes que vous devez connaître avant de migrer.

Mappage des types de données

PostgreSQL possède un riche ensemble de types de données. Certaines des conversions de types de données importantes entre Oracle et PostgreSQL sont les suivantes.

Transactions

La base de données Oracle utilise toujours des transactions mais dans PostgreSQL, vous devez l'activer. Dans Oracle, la transaction commence lors de l'exécution d'une instruction et se termine lorsque l'instruction COMMIT est exécutée. Dans PostgreSQL, la transaction commence lors de l'exécution de BEGIN et se termine lorsque l'instruction COMMIT est exécutée. Même les niveaux d'isolement n'ont également aucun problème. La base de données PostgreSQL connaît tous les niveaux d'isolement connus de la base de données Oracle. Le niveau d'isolement par défaut de PostgreSQL est Lecture validée.

Exemple :

Oracle :

DELETE FROM table_name WHERE id = 120;
COMMIT;

PostgreSQL :

BEGIN;
DELETE FROM table_name WHERE id  = 120;
COMMIT;

Table double

Dans Oracle, la clause FROM est obligatoire pour chaque instruction SELECT, de sorte que la base de données Oracle utilise la table DUAL pour l'instruction SELECT où le nom de la table n'est pas requis. Dans PostgreSQL, la clause FROM n'est pas obligatoire, donc la table DUAL n'est pas nécessaire. La table Dual peut être créée dans PostgreSQL afin d'éliminer le problème de portage. L'outil Orafce l'a implémenté afin que vous puissiez également utiliser Orafce.

Exemple :

postgres=# SELECT CURRENT_TIMESTAMP FROM DUAL;
ERROR:  relation "dual" does not exist
LINE 1: SELECT CURRENT_TIMESTAMP FROM DUAL;
                                      ^
postgres=# SELECT CURRENT_TIMESTAMP;
       current_timestamp
-------------------------------
 2018-03-16 09:36:01.205925+00
(1 row)

Après avoir installé le module Orafce :

postgres=# SELECT CURRENT_TIMESTAMP FROM DUAL;
       current_timestamp
-------------------------------
 2018-03-16 09:36:01.205925+00
(1 row)

DATESYS

La fonction SYSDATE d'Oracle renvoie la date et l'heure. Le comportement de la fonction SYSDATE est différent selon les endroits. PostgreSQL n'a aucune fonction correspondant à la fonction SYSDATE. Dans PostgreSQL, il existe plusieurs méthodes pour obtenir la date et l'heure et elles sont basées sur l'objectif de l'application.

Dans l'exemple ci-dessous, clock_timestamp() renvoie l'heure à laquelle la fonction réelle est exécutée et l'autre statement_timestamp() renvoie l'heure à laquelle l'instruction SQL a commencé son exécution.

postgres=# SELECT now(), statement_timestamp(), current_timestamp, transaction_timestamp(), clock_timestamp();
              now              |      statement_timestamp      |       current_timestamp       |     transaction_timestamp     |        clock_timestamp
 
-------------------------------+-------------------------------+-------------------------------+-------------------------------+-------------------------------
 2018-03-16 09:27:56.163154+00 | 2018-03-16 09:27:56.163154+00 | 2018-03-16 09:27:56.163154+00 | 2018-03-16 09:27:56.163154+00 | 2018-03-16 09:27:56.163281+00
 (1 row)

TO_DATE(deux arguments)

La fonction TO_DATE d'Oracle renvoie la valeur de type DATE (année, mois, jour, heure, minute, seconde) tandis que TO_DATE (two_argument) de PostgreSQL renvoie la valeur de type DATE (année, mois, jour).

La solution à cette incompatibilité est de convertir TO_DATE() en TO_TIMESTAMP(). Si vous utilisez l'outil Orafce, il n'est pas nécessaire de changer quoi que ce soit car Orafce a implémenté cette fonction, nous obtenons donc le même résultat dans Oracle.

Oracle :

SELECT TO_DATE ('20180314121212','yyyymmddhh24miss') FROM dual;

PostgreSQL :

SELECT TO_TIMESTAMP ('20180314121212','yyyymmddhh24miss')::TIMESTAMP(0);

SYNONYME

CREATE SYNONYM n'est pas pris en charge dans PostgreSQL. Dans Oracle, CREATE SYNONYM est utilisé pour accéder aux objets distants tandis que dans PostgreSQL, nous pouvons utiliser SET search_path pour inclure la définition distante.

Oracle :

CREATE SYNONYM abc.table_name FOR pqr.table_name;

PostgreSQL :

SET search_path TO 'abc.table_name';

Comportement de chaîne vide et NULL

Dans Oracle, les chaînes vides et les valeurs NULL dans un contexte de chaîne sont identiques. La concaténation de NULL et de chaîne obtient une chaîne en conséquence. Dans PostgreSQL, le résultat de la concaténation est nul dans ce cas. Dans Oracle IS, l'opérateur NULL est utilisé pour vérifier si la chaîne est vide ou non, mais dans PostgreSQL, le résultat est FALSE pour une chaîne vide et TRUE pour NULL.

Séquences

Il y a une légère différence dans la syntaxe de la séquence dans Oracle et PostgreSQL.

Oracle :

Sequence_name.nextval

PostgreSQL :

Nextval(‘sequence_name’)

Pour modifier cette syntaxe, vous pouvez créer un script ou vous pouvez le modifier manuellement.

SUBSTR

Le comportement de la fonction SUBSTR dans Oracle et PostgreSQL est différent. La fonction SUBSTR fonctionne dans PostgreSQL sans erreur mais renvoie un résultat différent. Cette différence peut entraîner des bogues d'application.

Oracle :

SELECT SUBSTR(‘ABC’,-1) FROM DUAL;
Returns ‘C’

PostgreSQL :

postgres=# SELECT SUBSTR('ABC',-1);
 substr
--------
 ABC
(1 row)

La solution consiste à utiliser la fonction Orafce SUBSTR qui renvoie le même résultat qu'Oracle dans PostgreSQL.

SUPPRIMER l'instruction

Dans Oracle, l'instruction DELETE peut fonctionner sans la clause FROM, mais dans PostgreSQL, elle n'est pas prise en charge. Nous devons ajouter manuellement la clause FROM dans l'instruction PostgreSQL DELETE.

Oracle :

DELETE table_name WHERE column_name = 'Col_value';

PostgreSQL :

DELETE FROM table_name WHERE column_name = 'Col_value';

Couplage externe +

Oracle utilise l'opérateur + pour les jointures gauche et droite mais PostgreSQL ne l'utilise pas.

Oracle :

SELECT a1.name1, a2.name2
     FROM a1, a2
     WHERE a1.code = a2.code (+);

PostgreSQL :

SELECT a1.name1, a2.name2
    FROM a1
    LEFT OUTER JOIN a2 ON a1.code = a2.code;

COMMENCER PAR..CONNECTER PAR

Oracle utilise START WITH..CONNECT BY pour les requêtes hiérarchiques. PostgreSQL ne prend pas en charge l'instruction START WITH..CONNECT BY. PostgreSQL a WITH RECURSIVE pour les requêtes hiérarchiques, donc traduisez l'instruction CONNECT BY en instruction WITH RECURSIVE.

Oracle :

SELECT 
    restaurant_name, 
    city_name 
FROM 
    restaurants rs 
START WITH rs.city_name = 'TOKYO' 
CONNECT BY PRIOR rs.restaurant_name = rs.city_name;

PostgreSQL :

WITH RECURSIVE tmp AS (SELECT restaurant_name, city_name
                                 FROM restaurants
                                WHERE city_name = 'TOKYO'
                                UNION
                               SELECT m.restaurant_name, m.city_name
                                 FROM restaurants m
                                 JOIN tmp ON tmp.restaurant_name = m.city_name)
                  SELECT restaurant_name, city_name FROM tmp;

Conversion PLSQL vers PLPGSQL

Le langage PL/pgSQL de PostgreSQL est similaire au langage PL/SQL d'Oracle à bien des égards. C'est un langage impératif structuré en blocs, et toutes les variables doivent être déclarées. Dans les deux bases de données, les affectations, les boucles et les conditions sont similaires.

Les principales différences que vous devez garder à l'esprit lors du portage du PL/SQL d'Oracle vers le PL/pgSQL de PostgreSQL

Outils de migration

Certains outils sont très utiles pour une migration d'Oracle vers PostgreSQL. Vous pouvez également créer votre propre outil en tant qu'extension et l'utiliser dans PostgreSQL.

Orafce

Les fonctions, types de données et packages compatibles avec Oracle peuvent être utilisés tels quels dans PostgreSQL. Il s'agit d'un outil open source avec licence BSD afin que n'importe qui puisse utiliser cet outil.

La plupart des fonctions principales sont couvertes dans Orafce.

Les applications utilisent généralement ces fonctions avec plusieurs occurrences. Vous pouvez réduire le coût de modification de SQL en utilisant cet outil.

Toutes les fonctions et tous les packages sont correctement implémentés et bien testés.

Certaines des fonctions :

• Dbms_output
• dbms_random
• utl_file – fonctions liées au système de fichiers
• Dbms_pipe et dbms_alert
• PLVdate,PLVstr, PLVchr
• Type de données DATE compatible avec Oracle et fonctions telles que ADD_MONTHS, LAST_DAY, NEXT_DAY, etc.
• Fonction NVL
• Fonction SUBSTR et SUBSTRB
• Compatibilité VARCHAR2 et NVARCHAR2
• TO_DATE()

Ora2pg

Ora2Pg est un outil gratuit utilisé pour migrer une base de données Oracle vers un schéma compatible PostgreSQL.

Il se connecte à la base de données Oracle, l'analyse automatiquement, extrait sa structure ou ses données, puis génère des scripts SQL que vous pouvez charger dans votre base de données PostgreSQL.

L'estimation des coûts d'une migration d'Oracle vers PostgreSQL n'est pas facile.

Ora2Pg inspecte tous les objets de la base de données, toutes les fonctions et procédures stockées pour détecter s'il reste des objets et du code PL/SQL qui ne peuvent pas être automatiquement convertis par Ora2Pg.

Cet outil est très utile pour les conversions suivantes :

• Conversion de schéma
• Conversion PLSQL vers PLPGSQL

Test

Tester l'ensemble de l'application et la base de données migrée est très important car certaines des fonctions sont les mêmes dans les deux bases de données, mais le comportement est différent.

• Certains scénarios courants doivent être vérifiés :
  • Vérifiez si tous les objets sont correctement convertis ou non.
  • Vérifiez si tous les DMLS fonctionnent correctement ou non.
  • Chargez des exemples de données dans les deux bases de données et vérifiez le résultat. Le résultat de SQL des deux bases de données doit être le même.
  • Vérifiez les performances du DML et améliorez-les si nécessaire.