Qui ne s’est jamais retrouvé dans la situation suivante :
Un appel des équipes de Dev ou de production disant qu’une table vient d’être corrompue suite à une erreur de manipulation ou a un traitement : « Est-ce que l’on peut récupérer la table avant telle heure? »
Le challenge est de récupérer les données à moindre coût et avec le moins d’effort.
La solution la plus simple est de faire un clonage de la base en utilisant une sauvegarde antérieure, mais cela implique la mise a disposition d’un serveur et du stockage. De plus, suivant la volumétrie de la base, cela va prendre du temps, temps pendant lequel votre base est sans doute indisponible suite à cette erreur.
L’autre solution est un export de la table avant que le problème ne survienne.
Cela implique certains pré-requis :

1) La table ne doit pas avoir de contraintes d’intégrité sinon il faut exporter l’ensemble des tables concernées par les différentes contraintes.

2) Le propriétaire de la table ne doit pas être SYS.

3) Les informations de redo doivent toujours être présentes dans le tablespace d’annulation. Ce qui va dépendre de la taille de votre tablespace, de la valeur du paramètre undo_retention et de l’activité transactionnelle sur votre base. On peut le vérifier en utilisant la fonctionnalité de flashback query :

SQL>SELECT  *  FROM MA_TABLE AS OF TIMESTAMP  TO_TIMESTAMP('2016-05-30 11:00:00','yyyy-mm-dd hh24:mi:ss') ;

4) Le droit EXECUTE sur la package DBMS_FLASHBACK doit impérativement être donné au user propriétaire de la table à récupérer avant que le problème ne survienne.

Ces quatre conditions étant remplies, on peut alors récupérer les données telles qu’elles étaient avant l’incident.
Pour cela, on fait un export de la table avec la commande suivante :

expdp user/password tables=ma_table dumpfile=mon_fichier.dmp directory=DUMP_DIRECTORY FLASHBACK_TIME="'2016-05-05:30:11:00'"

ou

exp user/password tables=ma_table dumpfile=mon_fichier.dmp directory=DUMP_DIRECTORY FLASHBACK_TIME="TO_TIMESTAMP('2016-05-30 11:00:00','yyyy-mm-dd hh24:mi:ss')"

 
Un fois l’export fait on lance l’import des données avec le mode TRUNCATE.

imp user/password dumpfile=mon_fichier.dmp directory=DUMP_DIRECTORY TABLES=MA_TABLE TABLE_EXISTS_ACTION=TRUNCATE

Les données sont restaurées tel qu’elles étaient avant l’incident.
Le seul pré-requis est de donner le droit EXECUTE sur le package DBMS_FLASHBACK et d’être en version 10g minimum, ce qui n’est pas excessif comme coût.
Il ne reste plus qu’à passer sur l’ensemble des utilisateurs de toutes vos bases de données pour donner le droit EXECUTE sur le package DBMS_FLASHBACK pour être prémuni de la perte de données. Si vous ne l’avez pas fait, vous pouvez cependant toujours utiliser le flashback query. Tout cela à condition d’avoir taillé correctement votre tablespace d’annulation.
Bon courage.