Sauvegardes logiques par exports/imports

Un outil de sauvegarde d’Oracle des plus classique est l’export de données et l’import de données, grâce à deux utilitaires fournis par Oracle EXP et IMP.

Ces utilitaires sont obsolètes depuis la version 10g et sont remplacés au profit de Datapump (expdp et impdp), mais exp et imp demeurent présents en 10g pour des raisons de compatibilité, ceux-ci seront sans doute supprimés dans la version 12x même s’ils existent encore dans la 11g.

1 - Introduction

L’export de données est apporté par l’utilitaire Oracle $ORACLE_BASE/bin/exp. Même si on en parle comme un outil de sauvegarde de données par abus de langage, cet outil doit plutôt être considéré comme un outil de transport de données (d’une machine à une autre, d’une version à une autre) car il demeure très pauvre en matière fonctionnelle comparé aux autres outils de sauvegardes définis comme tel par Oracle tels que RMAN.

Les outils d’export/import permettent néanmoins de reconstruire tous les objets présents dans une base de données, mais pas la base de données elle-même, ce qui signifie que vous devrez éventuellement créer une base vierge pour accueillir les données exportées et que, en aucun cas, l’export/import ne sait traiter cette phase là : Export / Import n’est pas un outil de sauvegarde de base de données mais ou outil d’isolation de données logiques (ordres SQL seulement).

Nous verrons par la suite que, la pluspart du temps, si la base de données est accessible par les utilisateurs en modification, il est fort à parier que l’export mette à disposition des données incohérentes et qu’il faille pour éviter cela stopper les accès tout en laissant la base ouverte… Nous vous avons dit que exp/imp n’était pas un “outil de sauvegarde” !

2 - L’outil d’export de données EXP

L’export permet donc, selon certains critères ou filtres, de générer dans un fichier DUMP Oracle (dmp) certaines instructions SQL capables de reconstruire les données à l’aide de l’outil d’import (imp).

L’export, qui exportera les données de la database définie par la variable d’nevironnement ORACLE_SID) utilise principalement les commutateurs suivants :

userid (chaine de connection Oracle à l'instance au sens de SqlPlus)
owner  (nom d'un schéma à exporter plustot que tous les schémas de la base)
rows   (doit on expoter les données (Y) ou seulement les structures de tables)
indexes(doit on exporter les index (Y))
grants (doit on exporter les grants (Y))
table  (si on ne doit export que certaines tables)
file   (nom du dump généré)
log    (nom du fichier log pour trace)
full   (doit on exporter toute la database (N))
statistics (méthode d'exportation des stats (estimate|none))
consistent (les données doivent-elles être consistantes (N))
etc ... (faire exp HELP=Y pour afficher tous les commutateurs)

exemple :
exp "'sys/oracle as sysdba'"
    owner=SCOTT
    file=/data/export_scott.dmp
    log=/data/export.log
    statistics=none
    consistent=Y

Export FULL:

Attention au commutateur FULL : il permet d’exporter toute la base de données, mais vous risquez d’avoir des problèmes à l’import, pensez à ne pas importer en mode FULL égallement sous peine de voir éclater vos tablespaces SYSTEM, SYSAUX, … par ceux importés et de d”étruire votre base de données ! Si un export est FULL, l’import doit être filtrant. Si un export est filtré, l’import peut être FULL.

Données consistantes :

Le commutateur CONSISTENT n’est pas Y par défaut, ce qui signifie que votre export risque de comporter des données inconsistantes. En fait, durant l’exportation d’une table (et seulement d’une table) il se peut que des données soient modifiées en fin de fichier alors que vous avez déjà sauvegardé le début de fichier, et dans ce cas là, vous possèderez peut être des données orphelines (données filles qui n’ont pas de parent) ce qui peut rendre votre applicatif purement inexpoitable.

Pour éviter cela, le commutateur CONSITENT doit être fixé à Y. Le SCN courant est alors observé par exp au début de la sauvegarde d’une table et l’ensemble des requêtes de sélection que va éffectuer l’export se fera par rapport à ce SCN => Les données insérées ou modifiées pendant la sauvegarde ne seront pas vues.

Attention, si vos tables sont très grandes, n’oubliez pas que votre tablespace UNDO doit être correctement dimensionné car auquel cas, vous risquez d’obtenir en résultat un message d’erreur “SNAPSHOT TOO OLD” car les données dont vous auriez eu besoin pour terminer l’export de votre table ont été éffacées par d’autres données indispensables à l’exécution de nouvelles transactions…

ATTENTION : Ce type de traitement ne vous enlève pas le risque d’avoir des données insonsistantes entre plusieurs tables, le paramètre CONSISTENT ne vous règle le problème que au sein d’une table, c’est pour cela qu’il est VIVEMENT CONSEILLE de stopper les accès utilisateurs à la database pendant un export (fermeture des serveurs d’applications, fermeture des listeners, toute bonne méthode au choix du DBA …).

3 - L’outil d’import de données IMP

L’import IMP est donc l’outil capable de lire des dumps réalisés par l’export d’Oracle, l’ordre dans lequel imp effectue les opérations est le suivant:

1:  création des tables (sans contraintes)

2: insertion des données des tables

3: créations des index

4: application des contraintes d’intégrité référentielles

5: création des triggers, des index bitmaps, …

Les commutateurs sont globalement les même que pour EXP, vous pouvez en avoir le détail avec IMP HELP=Y, mais en voici quelques uns indispensables :

userid  (chaine de connection Oracle à l'instance au sens de SqlPlus)
fromuser(liste des schémas à importer plustot que tous les schémas de la base)
tomuser (dans quels schémas faut il importer les données)
rows    (doit on importer les données (Y) ou seulement les structures de tables)
indexes (doit on exporter les index (Y))
grants  (doit on exporter les grants (Y))
table   (si on ne doit export que certaines tables)
file    (nom du dump généré)
log     (nom du fichier log pour trace)
full    (doit on exporter toute la database (N))
commit  (faut-il commiter chaque instruction SQL (N))

exemple :
imp "'sys/oracle as sysdba'"
    file=/data/export_scott.dmp
    log=/data/import.log
    full=Y <-- car on part du principe que l'exp n'est pas full!

Remarque:

Un export ou un import ne doit signaler aucunne erreur ni aucun warniong sous peine d’avoir des surprises lors de l’exploitation de vos données… Cependant, si vous n’avez pas pu fermer l’accès aux données lors de votre export et que IMP soit incapable d’appliquer les contraintes référentielles car certaines données sont incohérentes, vous pouvez toujours demander à Oracle de ne pas tenir compte des contraintes pour les données existantes mais d’en tenir compte pour les futures insertions avec la commande suivante :

ALTER TABLE <table_name> CONSTRAINT <constraint_name> ENABLE NOVALIDATE;

Attention, ceci vous permettra sans doute de démarrer votre instance et d’ouvrir votre database mais, vous l’aurez compris, à n’utiliser qu’en cas de dernier recours car ici, forcément, certaines données sont maintenant orphelines … Danger !