Export et import de données Oracle avec Data Pump (expdp / impdp)

Sauvegarder un schéma, migrer des données d’une base à une autre, copier des tables entre environnements : ces opérations font partie du quotidien de qui travaille avec Oracle. L’outil de référence pour cela est Data Pump, avec ses deux utilitaires expdp (export) et impdp (import). Rapide, souple et fiable, il a remplacé les anciens outils d’export/import et s’est imposé comme le standard.

Ce guide explique le fonctionnement de Data Pump, ses commandes et paramètres essentiels, et détaille les cas d’usage les plus courants : exporter un schéma, le réimporter ailleurs, transférer des données entre deux bases. Les exemples utilisent des noms de schémas et de répertoires fictifs, réutilisables en adaptant les valeurs.

Data Pump ou les anciens exp/imp ?

Une clarification s’impose d’emblée, car deux générations d’outils coexistent.

Les utilitaires historiques exp et imp (export/import classiques) existent depuis les débuts d’Oracle. Ils fonctionnent encore mais sont dépréciés : Oracle ne les fait plus évoluer et recommande de ne plus les utiliser pour de nouveaux besoins.

Depuis Oracle 10g, ils ont été remplacés par Data Pump (expdp / impdp), bien plus performant : traitement parallèle, reprise de travaux interrompus, filtrage fin des objets, et de nombreuses options de transformation. C’est la méthode moderne, et celle que ce guide détaille. Si vous croisez encore des scripts en exp/imp, sachez simplement qu’il s’agit de l’ancienne génération.

Le principe : un outil côté serveur

Un point fondamental à comprendre, car il déroute souvent les débutants : Data Pump s’exécute côté serveur, pas côté client. Les fichiers d’export (les « dumps ») sont écrits sur le serveur de base de données, et non sur votre poste de travail.

C’est pourquoi Data Pump repose sur la notion de DIRECTORY : un objet Oracle qui pointe vers un répertoire physique du serveur. Avant tout export ou import, il faut donc disposer d’un tel répertoire et des droits associés.

On le crée en SQL, puis on accorde les droits de lecture/écriture à l’utilisateur concerné :

CREATE OR REPLACE DIRECTORY dp_dir AS '/chemin/vers/dossier';
GRANT READ, WRITE ON DIRECTORY dp_dir TO mon_utilisateur;

Ce répertoire dp_dir sera ensuite référencé dans toutes les commandes. C’est là que Data Pump lira et écrira les fichiers.

Exporter avec expdp

L’export produit un fichier dump contenant les données et/ou les métadonnées. Data Pump propose trois grands modes d’export, selon ce qu’on veut extraire.

Exporter un schéma complet

C’est le cas le plus fréquent. Le paramètre SCHEMAS désigne le ou les schémas à exporter :

expdp mon_user/mot_de_passe schemas=RH directory=dp_dir dumpfile=rh.dmp logfile=exp_rh.log

Cette commande exporte tout le schéma RH (ses tables, données, index, etc.) dans le fichier rh.dmp, en consignant le déroulé dans exp_rh.log. Les quatre paramètres essentiels sont là : ce qu’on exporte (schemas), où (directory), dans quel fichier (dumpfile), et le journal (logfile).

Exporter des tables précises

Pour n’exporter que certaines tables, on utilise TABLES :

expdp mon_user/mot_de_passe tables=RH.EMPLOYES,RH.SERVICES directory=dp_dir dumpfile=tables.dmp logfile=exp_tables.log

Exporter la base entière

Le paramètre FULL=Y exporte l’intégralité de la base (réservé aux comptes disposant des privilèges nécessaires) :

expdp system/mot_de_passe full=Y directory=dp_dir dumpfile=full.dmp logfile=exp_full.log

Exporter les données ou la structure seule

Le paramètre CONTENT permet de choisir ce qu’on exporte : DATA_ONLY pour les seules données, METADATA_ONLY pour la seule structure (utile pour recréer un schéma vide).

expdp mon_user/mot_de_passe schemas=RH content=METADATA_ONLY directory=dp_dir dumpfile=structure.dmp logfile=exp_struct.log

Importer avec impdp

L’import relit un fichier dump pour recharger les données dans une base. La syntaxe est symétrique de l’export.

Importer un schéma

impdp mon_user/mot_de_passe schemas=RH directory=dp_dir dumpfile=rh.dmp logfile=imp_rh.log

Si le schéma et les objets existent déjà, il faut préciser le comportement attendu avec TABLE_EXISTS_ACTION, qui accepte quatre valeurs : SKIP (ignorer), APPEND (ajouter les données), TRUNCATE (vider puis recharger) ou REPLACE (recréer la table).

impdp mon_user/mot_de_passe schemas=RH directory=dp_dir dumpfile=rh.dmp logfile=imp_rh.log table_exists_action=APPEND

Importer dans un schéma différent

C’est l’un des cas les plus utiles en migration : importer les données d’un schéma source vers un schéma de nom différent. Le paramètre REMAP_SCHEMA fait la correspondance :

impdp system/mot_de_passe directory=dp_dir dumpfile=rh.dmp logfile=imp_remap.log remap_schema=RH:RH_TEST

Ici, les objets du schéma RH sont recréés dans le schéma RH_TEST. Très pratique pour dupliquer un schéma de production vers un environnement de test.

Importer dans un tablespace différent

De même, REMAP_TABLESPACE redirige les objets vers un autre tablespace que celui d’origine — indispensable quand la structure de stockage diffère entre les deux bases :

impdp system/mot_de_passe directory=dp_dir dumpfile=rh.dmp logfile=imp_ts.log remap_tablespace=USERS:DATA

Transférer directement entre deux bases

Data Pump peut transférer des données d’une base à une autre sans passer par un fichier dump intermédiaire, grâce au paramètre NETWORK_LINK, qui s’appuie sur un lien de base de données (database link). L’import va alors chercher les données directement dans la base source :

impdp mon_user/mot_de_passe directory=dp_dir logfile=imp_reseau.log network_link=LIEN_SOURCE schemas=RH

C’est une méthode élégante pour rafraîchir un environnement de test à partir de la production, sans manipuler de fichier.

Quelques paramètres utiles à connaître

Au-delà des bases, plusieurs paramètres facilitent la vie :

PARALLEL accélère les traitements volumineux en répartissant le travail sur plusieurs processus. On le combine avec le joker %U dans le nom du dump, pour générer (et relire) plusieurs fichiers :

expdp mon_user/mot_de_passe schemas=RH directory=dp_dir parallel=4 dumpfile=rh_%U.dmp logfile=exp_rh.log

COMPRESSION réduit la taille du dump (ALL pour tout compresser), pratique pour les gros volumes.

INCLUDE et EXCLUDE filtrent les objets à traiter (par exemple, exclure les index, ou n’inclure que certaines tables).

ESTIMATE_ONLY=Y calcule la taille qu’occuperait l’export sans l’exécuter — utile pour vérifier l’espace nécessaire avant de se lancer.

VERSION permet d’exporter dans un format compatible avec une version d’Oracle plus ancienne, pour transférer vers une base d’une version antérieure.

Pièges et bonnes pratiques

Quelques écueils reviennent régulièrement avec Data Pump :

Le répertoire et les droits. L’erreur la plus fréquente au démarrage : oublier de créer l’objet DIRECTORY ou d’accorder les droits READ/WRITE dessus. Sans cela, rien ne fonctionne.

Le fichier est sur le serveur, pas chez vous. Comme Data Pump écrit côté serveur, le dump se trouve dans le répertoire du serveur, pas sur votre poste. Il faut y accéder sur la machine, ou prévoir de le récupérer.

Le tablespace manquant à l’import. Si le tablespace d’origine n’existe pas dans la base cible, l’import échoue (erreur de tablespace inexistant). Solution : créer le tablespace au préalable, ou utiliser REMAP_TABLESPACE.

Les versions et fuseaux horaires. Transférer entre deux bases de versions différentes peut nécessiter le paramètre VERSION, et une incompatibilité de version de fichier de fuseau horaire peut bloquer un import. À vérifier lors des migrations entre environnements.

Surveiller le travail en cours. Un export ou import Data Pump est un « job » que l’on peut suivre. La vue DBA_DATAPUMP_JOBS permet de lister les travaux en cours, et le mode interactif (en appuyant sur Ctrl+C pendant l’exécution) donne accès à des commandes de contrôle.

En résumé

Data Pump est l’outil standard pour les mouvements de données sous Oracle :

• il remplace les anciens exp/imp et s’exécute côté serveur, via un objet DIRECTORY ;
• l’export (expdp) se fait par schéma (SCHEMAS), par tables (TABLES) ou en base entière (FULL=Y) ;
• l’import (impdp) relit le dump, avec TABLE_EXISTS_ACTION pour gérer l’existant ;
• les paramètres REMAP_SCHEMA et REMAP_TABLESPACE sont les clés des migrations vers un schéma ou un stockage différent ;
• NETWORK_LINK permet un transfert direct entre bases, et PARALLEL, COMPRESSION ou CONTENT affinent le traitement.

Le bon réflexe, comme souvent : tester d’abord sur un petit périmètre (une table, un schéma de test) avant d’exécuter une opération de grande ampleur, et toujours vérifier le fichier journal (logfile) qui consigne le détail de chaque traitement. Une fois ces mécanismes maîtrisés, Data Pump devient un outil sûr et rapide pour déplacer les données au quotidien.

Vous utilisez Data Pump pour des tâches récurrentes ? Les fichiers de paramètres (PARFILE) permettent d’enregistrer une commande complète pour la rejouer facilement — un gain de temps appréciable pour les exports réguliers.