Contexte et sélection de l'outil

Le scénario cible une base Oracle à l'architecture linéaire, exemptée de vues, de procédures stockées ou de fonctions PL/SQL. Après une analyse comparative des solutions ouvertes telles que pgloader, DBeaver et ora2pg, le choix s'est porté sur ora2pg pour sa robustesse lors de la transposition des schémas et sa gestion native des contraintes PostgreSQL.

Tentative initiale avec pgloader

L'approche via pgloader a rapidement rencontré des obstacles liés à la résolution des bibliothèques clientes Oracle et au parsing des chaînes de connexion. Un script de chargement standard a été configuré :

LOAD DATABASE
    FROM oracle://src_user:pass@10.20.30.40:1521/DBSOURCE
    INTO postgresql://tgt_user:pass@10.20.30.41:5432/DBTARGET

WITH include drop, create tables, create indexes, reset sequences

SET work_mem TO '32MB', maintenance_work_mem TO '1GB'

BEFORE LOAD DO
$$ CREATE SCHEMA IF NOT EXISTS target_schema; $$

AFTER LOAD DO
$$ ANALYZE target_schema; $$;

Malgré l'installation des paquets Instant Client et la tentative d'isolation via des conteneurs Docker, le moteur renvoyait systématiquement des erreurs de fromatage d'URI et de liaison dynamique. La complexité de l'environnement natif a motivé l'abandon de cette méthode.

Implémentation avec ora2pg

L'exécution s'effectue dans un environnement conteneurisé pour garantir l'isolement des dépendances. Le processus exige une dissociation claire entre l'export de la structure et l'ingestion des données. Les paramètres sont centralisés dans un fichier de configuration dédié :

# /opt/migration/oracle_to_pg.conf
# Configuration source Oracle
ORACLE_DSN dbi:Oracle:host=10.20.30.40;sid=DBSOURCE
ORACLE_USER src_reader
ORACLE_PWD src_secure_key

# Configuration cible PostgreSQL
PG_DSN dbi:Pg:dbname=target_db;host=10.20.30.41;port=5432
PG_USER pg_admin
PG_PWD tgt_secure_key

# Règles d'extraction et de chargement
SCHEMA PROD_ENV
OUTPUT /tmp/schema_export.sql
DATA_LIMIT 10000
DATA yes
EXPORT_SCHEMA no
EXPORT_DATA yes
JOBS 8
TYPE COPY

# Mappage spécifique des types numériques
DATA_TYPE NUMBER(*,2):NUMERIC
DEFAULT_NUMERIC NUMERIC

La commande de lancement initialise le flux de copie. Les directives JOBS et DATA_LIMIT permettent de paralléliser les lectures tout en maintenant la consommatoin mémoire sous contrôle. L'outil s'arrête automatiquement une fois chaque phase terminée, nécessitant une relance manuelle pour bascuelr de l'export de schéma vers le transfert des lignes.

Vérification de l'intégrité des données

La cohérence post-migration est évaluée selon deux méthodologies :

• Comptage des entrées : Comparaison directe des agrégations COUNT(*) sur les tables homonymes.
• Contrôle par empreinte cryptographique : Application d'algorithmes de hachage (SHA-256 ou MD5) sur des enregistrements représentatifs. Cette technique génère une signature fixe pour chaque lot de données, permettant de détecter toute corruption ou altération lors du transit réseau ou de l'écriture sur le volume cible.

Considérations techniques sur les types numériques

Le comportement par défaut des outils de conversion consiste souvent à projeter les colonnes NUMBER Oracle vers le type BIGINT PostgreSQL, ce qui entraîne systématiquement l'effacement des décimales. Pour conserver la précision arithmétique, il est indispensable d'imposer une conversion explicite vers NUMERIC ou DECIMAL via les directives de configuration. Cette étape prévient les erreurs de calcul dans les modules financiers ou analytiques.