Migrer d'Oracle vers PostgreSQL : méthode et pièges.

Avant de commencer : est-ce le bon projet ?

Une migration vers PostgreSQL se justifie quand le coût de licence pèse, quand l'application peut évoluer, ou quand l'hébergement cible est un cloud proposant PostgreSQL managé. Elle est plus discutable si l'application repose massivement sur des fonctions propres à Oracle (RAC, Data Guard, packages très volumineux) et que personne ne peut les réécrire.

La bonne question n'est pas « peut-on migrer ? » mais « combien de code et de comportements faut-il réécrire, et qui les valide ? ».

1. Cadrer : l'inventaire fait gagner des mois

Avant tout choix d'outil, il faut dresser la liste de ce qui existe réellement :

• schémas, tables, volumétrie et taux de croissance ;
• objets procéduraux : packages, procédures, fonctions, déclencheurs, volume de PL/SQL ;
• tâches planifiées, liens de base de données (db links), vues matérialisées, partitionnement ;
• types et fonctionnalités spécifiques Oracle utilisés par l'application ;
• applications connectées : requêtes SQL écrites en dur, ORM, outils de reporting, ETL.

Des outils comme ora2pg produisent un rapport d'évaluation qui estime l'effort de conversion. Il donne un ordre de grandeur, pas un engagement : il faut le recouper avec une lecture du code le plus critique.

2. Convertir le schéma et le code

La partie la plus visible, mais pas la plus risquée. Quelques différences de comportement qui reviennent à chaque projet :

• Chaînes vides : Oracle les traite comme NULL, PostgreSQL non. Les tests de nullité et les contraintes doivent être revus.
• Type DATE : en Oracle il contient l'heure. L'équivalent est généralement timestamp, pas date.
• Types numériques : NUMBER doit être converti selon l'usage réel (integer, bigint ou numeric) pour éviter à la fois les erreurs et les pertes de performance.
• Packages : PostgreSQL n'a pas de packages natifs. On les remplace par des schémas et des fonctions.
• PL/SQL vers PL/pgSQL : la syntaxe est proche mais pas identique (gestion des exceptions, curseurs, transactions autonomes à reconstruire autrement).
• Requêtes hiérarchiques : CONNECT BY devient une requête récursive (WITH RECURSIVE) ; ROWNUM devient LIMIT ou une fonction de fenêtrage ; la syntaxe de jointure externe (+) est à réécrire.
• Séquences, synonymes, droits : à recréer et à tester, car ils sont souvent oubliés.

3. Reprendre les données

Pour une base de taille modeste, un export puis un import suffisent. Pour une base volumineuse ou une application qui ne peut pas s'arrêter longtemps, on met en place une synchronisation continue (capture des changements) entre Oracle et PostgreSQL, puis on bascule quand les deux sont alignés.

Dans tous les cas, la reprise doit être vérifiée : comptages par table, sommes de contrôle sur les colonnes sensibles, échantillonnage fonctionnel validé par les utilisateurs métier.

4. Retester la performance, ne pas la supposer

Les plans d'exécution ne sont pas les mêmes d'un moteur à l'autre. Une requête rapide sous Oracle peut être lente sous PostgreSQL, et inversement. Il faut :

• rejouer une charge représentative, pas seulement quelques requêtes ;
• mettre à jour les statistiques (ANALYZE) et revoir les index ;
• ajuster les paramètres mémoire et la maintenance (autovacuum) à la volumétrie réelle ;
• comparer les temps de réponse sur les traitements critiques avant la bascule.

5. Préparer la bascule et le retour arrière

La bascule se répète à blanc, avec un chronométrage. Un plan de retour arrière doit exister, tant que l'ancienne base Oracle est conservée. La date de bascule se choisit en fonction du métier (clôtures, pics d'activité), pas de la disponibilité de l'équipe technique.

Les pièges les plus fréquents

• sous-estimer le volume de PL/SQL et les règles métier qui y sont cachées ;
• ne tester que sur un jeu de données réduit ;
• oublier les traitements batch, les exports et les outils de reporting connectés à la base ;
• ne pas former les équipes d'exploitation : sauvegarde, supervision et maintenance changent avec PostgreSQL ;
• supprimer la base Oracle trop tôt.