Pourquoi utiliser flashback query avec EXPDP ?

Cette remarque vous paraitra sans doute évidente mais, je vous assure que ce n’est pas le cas pour tout le monde : « les exports datapump, pas plus que les exports classiques, n’assurent la cohérence des données entre les tables par défaut ».

Il faudra, dans la plupart des cas, arrêter l’activité dml ou utiliser flashback query, pour obtenir un ensemble cohérent de données de vos tables exportées. Avec expdp, vous prendrez donc soin d’utiliser flashback_scn ou flashback_time de la même manière que vous utilisiez consistent=y avec exp. Vous trouverez ci-dessous un petit test pour vous en persuader…

Créer un programme qui insère le même nombre de lignes dans 2 tables

Voici ci-dessous un programme qui crée 2 tables X et Y. Cet ensemble de 2 tables contient toujours le même nombre de lignes dans ce programme comme vous vous en rendrez compte en étudiant les frontières des transactions :

drop table x purge;
drop table y purge;
create table x(id number);
create table y(id number);

set timing on
begin
for i in 1..1000000 loop
insert into X values (i);
insert into Y values (i);
commit;
end loop;
end;
/

Export Data Pump pendant l’activité sans flashback

Lancez le programme ci-dessus dans une session SCOTT. Puis pendant que l’opération est en cours, lancez un export datapump avec la commande ci-dessous :

$ expdp "/ as sysdba" tables=scott.x,scott.y directory=dpdir dumpfile=t.dmp 

Export: Release 11.2.0.1.0 - Production on Sun Aug 15 12:06:38 2010

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYS"."SYS_EXPORT_TABLE_01": "/******** AS SYSDBA" tables=scott.x,scott.y directory=dpdir dumpfile=t.dmp
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 4 MB
Processing object type TABLE_EXPORT/TABLE/TABLE
. . exported "SCOTT"."X" 1.027 MB 120414 rows
. . exported "SCOTT"."Y" 1.031 MB 120911 rows
Master table "SYS"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.SYS_EXPORT_TABLE_01 is:
/u01/app/oracle/datapump/t.dmp
Job "SYS"."SYS_EXPORT_TABLE_01" successfully completed at 12:06:45

Comme vous pouvez vous en rendre compte, le nombre de lignes entre les 2 tables est différent ce qui signifie que la session datapump fonctionne en « committed reads » ou, autrement dit que si vous ré-importez vos données, les données ne sont pas cohérentes.

Export Data Pump pendant l’activité avec flashback

Relancez le programme qui crée X et Y dans une session SCOTT. Puis pendant que l’opération est en cours, lancez un export datapump avec une clause flashback_time ou flashback_scn comme ci-dessous :

rm /u01/app/oracle/datapump/t.dmp 

expdp "/ as sysdba" tables=scott.x,scott.y directory=dpdir dumpfile=t.dmp
FLASHBACK_TIME="TO_TIMESTAMP(TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS'),'YYYY-MM-DD HH24:MI:SS')"
Export: Release 11.2.0.1.0 - Production on Sun Aug 15 12:20:29 2010

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Starting "SYS"."SYS_EXPORT_TABLE_01": "/******** AS SYSDBA" tables=scott.x,scott.y directory=dpdir dumpfile=t.dmp FLASHBACK_TIME="TO_TIMESTAMP(TO_CHAR(SYSDATE,'YYYY-MM-DD HH24:MI:SS'),'YYYY-MM-DD HH24:MI:SS')"
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 6 MB
Processing object type TABLE_EXPORT/TABLE/TABLE
. . exported "SCOTT"."X" 1.819 MB 212748 rows. . exported "SCOTT"."Y" 1.819 MB 212748 rows
Master table "SYS"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYS.SYS_EXPORT_TABLE_01 is:
/u01/app/oracle/datapump/t.dmp
Job "SYS"."SYS_EXPORT_TABLE_01" successfully completed at 12:20:37

Comme vous pouvez vous en rendre compte, le nombre de lignes entre les 2 tables est identique; si vous ré-importez vos données, les données seront désormais cohérentes. Si vous exports durent longtemps, veillez à tailler vos tablespaces d’UNDO en conséquence…