TL;DR : Le travail manuel dans une migration d'Oracle vers PostgreSQL dépend entièrement de la manière dont le schéma a été construit, et non de sa taille.
Ce guide décrit trois schémas Oracle courants et les exemples de migration spécifiques qui les couvrent : OLTP hérité, OLTP moderne et entrepôt de données.
Si vous n'êtes pas sûr de celle qui s'applique à votre base de données, la section de diagnostic ci-dessous vous pose quatre questions pour le déterminer.
Trois DBA peuvent tous dire “ Je migre Oracle vers PostgreSQL ” et être confrontés à des problèmes complètement différents.
Le premier fait tourner un ERP de 15 ans sur Oracle 10g avec des paires séquence-déclencheur sur chaque table.
Le deuxième dispose d'une application de commandes client construite sur Oracle 19c avec des colonnes IDENTITY et du JSON stocké dans des BLOBs.
Le troisième consiste à migrer un entrepôt de données avec des tables de faits partitionnées par plage, des vues matérialisées et des index bitmap.
ora2pg gère les trois.
Le travail manuel est complètement différent dans chaque cas.
Table des matières
Pourquoi le type de schéma détermine-t-il l'effort de migration ?
Oracle prend en charge plusieurs modèles d'application — OLTP hérité, OLTP moderne et analytique/entrepôt de données — et chacun utilise un ensemble distinct de fonctionnalités spécifiques à Oracle.
PostgreSQL prend en charge les mêmes modèles, mais différemment.
Le travail de traduction se concentre là où les fonctionnalités Oracle n'ont pas d'équivalent PostgreSQL direct : séquences connectées à des triggers, gestion des séquences de colonnes IDENTITY, index bitmap, planification de rafraîchissement des vues matérialisées.
Connaître votre schéma avant de commencer vous indique exactement où se trouve le travail manuel, avant d'ouvrir ora2pg.
Héritage OLTP : le schéma RH
Ce à quoi cela ressemble : Tables avec des clés primaires basées sur des séquences, des déclencheurs BEFORE INSERT qui attribuent la valeur de séquence suivante lors de l'insertion, des procédures stockées et des contraintes de clé étrangère.
Exemples concrets : systèmes ERP, plateformes RH, bases de données CRM, toute application Oracle antérieure à Oracle 12c.
Le problème central est le modèle d'incrémentation automatique d'Oracle pré-12c :
CREATE OR REPLACE TRIGGER employees_bir
BEFORE INSERT ON employees
FOR EACH ROW
BEGIN
SELECT employees_seq.NEXTVAL INTO :NEW.employee_id FROM DUAL;
END;
ora2pg exporte ce déclencheur en PL/pgSQL.
Il se compile sans erreurs dans PostgreSQL.
C'est le mauvais modèle — PostgreSQL gère l'auto-incrémentation via les valeurs par défaut de colonne pointant vers une séquence, pas des déclencheurs.
L'approche par déclencheur fonctionne mais ajoute une surcharge inutile à chaque insertion et masque la dépendance de la séquence du lecteur de schéma.
Le guide du schéma des ressources humaines couvre cette conversion dans son intégralité, ainsi que deux autres problèmes qui apparaissent dans presque toutes les migrations OLTP héritées : le %TYPE bug de paramètre dans les fonctions PL/pgSQL exportées, et bug de réapplication des contraintes de clé étrangère d'ora2pg.
Lisez l'exemple complet de migration de schéma RH →
OLTP moderne : Le schéma CO
Ce à quoi cela ressemble : Clés primaires en utilisant GENERATED BY DEFAULT ON NULL AS IDENTITY, colonnes BLOB stockant du JSON et vues utilisant des fonctions SQL spécifiques à Oracle.
Exemples concrets : bases de données transactionnelles orientées client, systèmes de gestion des commandes, toute application Oracle développée ou modernisée sur Oracle 12c ou version ultérieure.
CO introduit trois problèmes qui n'apparaissent pas dans le schéma RH.
Le premier est la réinitialisation de la séquence de la colonne IDENTITY.
Après que ora2pg a chargé les données, les séquences sont toujours à leur valeur de départ — pas à la valeur maximale chargée.
La première insertion d'application après la migration échoue avec une violation de clé unique.
La correction est une seule ligne ALTER SEQUENCE par table, mais cela doit s'exécuter après le chargement des données.
Le second est du JSON stocké en BLOB.
ora2pg exporte la colonne comme bytea.
Les données sont là mais inutilisables pour des requêtes JSON.
Le type cible correct est jsonb, ce qui nécessite une étape de migration de données en plus de la conversion du schéma.
Le troisième est le SQL spécifique à Oracle dans les vues.LISTAGG, PIVOT, CONNECT BYet NUL n'ont pas d'équivalents directs dans PostgreSQL.
Les vues utilisant ces fonctions doivent être réécrites en SQL standard avant de pouvoir fonctionner.
Lisez l'exemple complet de migration de schéma CO →
Si votre schéma combine des modèles des OLTP hérités et modernes — par exemple, une application de 15 ans étendue sur Oracle 19c — lisez les guides HR et CO.
Si vous préférez qu'un expert cartographie le travail manuel avant d'engager votre équipe dans le projet, une évaluation à forfait couvre exactement cela
Data Warehouse : le schéma SH
Ce à quoi cela ressemble : Tables de faits partitionnées par plage, vues matérialisées utilisées pour le reporting pré-agrégé, et index bitmap sur les colonnes de dimension à faible cardinalité.
Exemples concrets : Entrepôts de données Oracle, plateformes de reporting BI, bases de données d'analyse, tout schéma conçu pour le reporting plutôt que pour le traitement des transactions.
SH introduit trois problèmes inédits dans les RH ou le CO.
La première est l'exportation de partition.
ora2pg divise une table partitionnée en deux fichiers d'exportation distincts : un pour la définition de la table parente et un pour les tables filles de partitionnement.
Les charger dans le mauvais ordre casse la migration.
L'ordre correct est d'abord la table parente, puis les données, puis les partitions filles — et cet ordre est différent de ce que le modèle de projet ora2pg suggère par défaut.
La deuxième est la conversion d'index bitmap.
Les index bitmap Oracle n'ont pas d'équivalent dans PostgreSQL.
ora2pg les convertit en index B-tree standard, ce qui est le résultat correct — mais il produit un index GIN sur des colonnes de clés étrangères entières dans certaines configurations, ce qui est incorrect.
Chaque index converti doit être vérifié avant le chargement des données.
Le troisième est la planification de l'actualisation des vues matérialisées.
PostgreSQL ACTUALISER LA VUE MATÉRIALISÉE est équivalent à Oracle DBMS_MVIEW.REFRESH.
Le mécanisme de planification n'est pas.
Oracle utilise DBMS_JOB ou DBMS_SCHEDULER.
PostgreSQL n'a ni l'un ni l'autre.
Les tâches de rafraîchissement doivent être recréées à l'aide de pg_cron ou d'un planificateur externe.
Lire l'exemple complet de migration de schéma SH →
Quel guide s'applique à votre schéma ?
Répondez à ces quatre questions :
1. Comment les clés primaires sont-elles implémentées ?
Gâchette d'insertion déclenchée AVANT Séquence Guide RH (OLTP hérité).GENERATED ... AS IDENTITÉ → Guide du CO (OLTP moderne).
Clés naturelles ou pas de modèle d'identité → lire les deux.
2. Votre schéma possède-t-il des tables partitionnées ?
Oui, avec Partitionnement par plage ou PARTITION BY LIST → Guide SH (entrepôt de données).
Non → ignorer le guide SH sauf si vous avez des vues matérialisées.
3. Avez-vous des vues matérialisées ?
Oui Guide SH couvre le problème de planification de l'actualisation dans son intégralité.
Non → cette section ne s'applique pas.
4. Des vues utilisent-elles des fonctions spécifiques à Oracle — NUL, DÉCODER, LISTAGG, CONNECT BY, ROWNUM, ou PIVOT?
Oui Guide du CO couvre la vue manuelle de réécriture en détail.
Non → vos vues seront probablement exportées proprement avec ora2pg.
La plupart des schémas réels de production sont une combinaison.
Un ERP de 15 ans étendu sur Oracle 19c peut avoir des paires séquence-déclencheur sur les tables héritées et des colonnes IDENTITY sur les plus récentes — lisez les guides RH et CO.
Si le même schéma pilote également les requêtes de reporting sur les tables partitionnées, ajoutez le guide SH.
Foire aux questions
Par quel guide devrais-je commencer si je n'ai jamais effectué de migration d'Oracle vers PostgreSQL auparavant ?
Commencez par le guide du schéma RH.
Il couvre le schéma le plus petit avec les problèmes les plus universels.
Les paires séquence-déclencheur, les incompatibilités de type de procédure stockée et le bug de réapplication de clé étrangère apparaissent dans presque toutes les migrations Oracle, quelle que soit la taille ou la complexité du schéma.
Les guides RH expliquent également le flux de travail ora2pg complet avant que les guides CO et SH n'introduisent leurs couches supplémentaires.
Dois-je lire les trois guides ?
Pas nécessairement.
Lisez celui qui correspond d'abord à votre modèle de schéma principal.
Si votre schéma combine des éléments de plusieurs catégories — par exemple, des colonnes IDENTITY et des tables partitionnées — lisez les sections pertinentes des deux guides.
Chaque guide est structuré de telle sorte que le flux de travail principal se trouve dans la première moitié et les problèmes spécifiques au schéma dans la seconde.
Ces guides sont-ils spécifiques à une version particulière d'Oracle ?
Les étapes de migration fonctionnent avec Oracle 12c et versions ultérieures.
Les colonnes d'identité, abordées dans le guide CO, nécessitent Oracle 12c minimum.
Le modèle de déclencheur de séquence, couvert dans le guide RH, est l'idiome Oracle pré-12c mais apparaît également dans les schémas 12c et 19c qui n'ont pas été modernisés.
Les trois guides utilisent ora2pg 25.0 avec Oracle 19c comme source et PostgreSQL 18 comme cible.
Et si mon schéma ne contenait aucun de ces modèles ?
Un schéma sans paires séquence-déclencheur, sans colonnes d'identité, sans partitionnement et sans vues matérialisées constitue le cas de migration le plus simple.
Le guide des RH s'applique toujours — il couvre le flux de travail ora2pg de base, le mappage des types de données, l'ordre de chargement des fichiers et la validation TEST que toute migration nécessite.
En résumé
Les problèmes de migration d'Oracle vers PostgreSQL sont prévisibles — une fois que vous savez quel schéma vous avez au départ.
Les schémas OLTP hérités construits avant Oracle 12c nécessitent un nettoyage des séquences-déclencheurs et des corrections de procédures stockées.
Les schémas OLTP modernes sur Oracle 12c et versions ultérieures nécessitent des réinitialisations de séquences d'identité et des réécritures de vues.
Les schémas d'entrepôts de données Oracle nécessitent une gestion prudente des partitions, des index bitmap et de la planification des vues matérialisées.
Exécutez d'abord le rapport de migration pour confirmer l'estimation de l'effort avant de vous engager sur un calendrier :
ora2pg -t SHOW_REPORT --estimate_cost --dump_as_html > reports/migration_report.html
Si votre schéma combine des modèles de plus d'une catégorie, ou si le rapport de migration signale une complexité que vous ne savez pas comment résoudre, prendre contact →.
Je propose une évaluation de migration à forfait qui répertorie chaque élément de conversion manuelle et vous donne une estimation claire de l'effort avant le début du projet.