Fin de semaine en douceur sur lami-dba.
http://www.lami-dba.com/2018/03/oracle-12c-r2-sql-plus-history.html
enjoy.
Fin de semaine en douceur sur lami-dba.
http://www.lami-dba.com/2018/03/oracle-12c-r2-sql-plus-history.html
enjoy.
En Mars, l'ami-dba maintient le rythme.
http://www.lami-dba.com/2018/02/dataguard-resolve-gap-revover-from-service.html
Aimez, partagez, critiquez & inscrivez vous à la newsletter.
@+
LAO
Hello à toutes & à tous,
Un petit post pour vous alerter d'un nouvel article de Micka sur lami-dba.com pour sur l'auto-restart des pluggable database après un restart de l'instance ORACLE
http://www.lami-dba.com/2015/09/auto-start-pluggable-database-oracle-12c-multitenant.html
Une nouvelle fois je vous invite à vous abonner à la newsletter du nouveau blog lami-dba.com
@très bientôt sur http://www.lami-dba.com !!
@LAO
Hello !
Cette fois ci, j'ai décidé de parler d'une fonctionnalité SQL de la 12c que nous avons presque tous esperé avoir un jour, j'ai nommé le truncate cascade.
Un petit exemple valant mieux qu'un long discours, commencons par créer un petit jeu de test.
sqlplus lao/lao SQL> create table clients (idclient number primary key); Table created. SQL> create table factures(idfacture number primary key,idclient number); Table created. SQL> alter table factures add constraint fk_client foreign key (idclient) references clients(idclient) on delete cascade; Table altered. SQL> insert into clients values (1); 1 row created. SQL> insert into factures values (1,1); 1 row created. SQL> commit; Commit complete.
Maintenant que notre petit jeu de test est prêt, je vais tenter un truncate de la table clients
SQL> truncate table clients; truncate table clients * ERROR at line 1: ORA-02266: unique/primary keys in table referenced by enabled foreign keys
On obtient ici l'erreur classique que l'on aurait obtenu dans une version antérieure d'Oracle. Alors bien sur, il existait des moyens de contournement en désactivant les contraintes,... Mais avouons quand même que c'est plus pratique en ajoutant juste la clause cascade à notre commande truncate..
SQL> truncate table clients cascade; Table truncated. SQL> select count(*) from clients; COUNT(*) ---------- 0 SQL> select count(*) from factures; COUNT(*) ---------- 0
@++
LAO
Hello !
Aujourd'hui, j'ai décidé de vous parler d'une fonctionnalité de la 12c qui me parait bien pratique, le déplacement ou le renommage online de datafile ! Avant la 12c pour déplacer un datafile, il fallait le passer en OFFLINE, puis via le system (et donc pas sans risques) le déplacer, et enfin effectuer un rename. J'avais dailleurs écris un petit article sur le sujet:
http://www.lao-dba.com/article-27038563.html
La preuve par l'exemple...
SQL> select file_name from dba_data_files; FILE_NAME -------------------------------------------------------------------------------- /ORADB/oradata/ORADB/system01.dbf /ORADB/oradata/ORADB/sysaux01.dbf /ORADB/oradata/ORADB/undotbs01.dbf /ORADB/oradata/ORADB/users01.dbf
Afin d'illuster cette fonctionnalité, je vais déplacer mon datafile /ORADB/oradata/ORADB/users01.dbf vers l'emplacement /u02/ORADB/oradata
SQL> alter database move datafile '/ORADB/oradata/ORADB/users01.dbf' to '/u02/ORADB/oradata/user01.dbf';
Avant d'excuter la commande, ouvrez une autre session sur votre schema de test (lao dans mon cas) afin de vérifier que non seulement les données sont accessibles mais en plus vous pouvez continuer à en inserer.
En fonction de la taille du fichier à déplacer au bout de quelques instants, dans votre première session vous avez le message suivant.
Database altered.
Durant le période de la copie, comme je l'indiquais les donneés restent accessibles en lecture /écriture
SQL> connect lao/lao Connected. SQL> insert into t values (5); 1 row created. SQL> commit; Commit complete. SQL> select count(*) from t; COUNT(*) ---------- 14999991 SQL> insert into t values (5); 1 row created. SQL> commit; Commit complete. SQL> select count(*) from t; COUNT(*) ---------- 14999992
SQL> select file_name from dba_data_files; FILE_NAME -------------------------------------------------------------------------------- /ORADB/oradata/ORADB/system01.dbf /ORADB/oradata/ORADB/sysaux01.dbf /ORADB/oradata/ORADB/undotbs01.dbf /u02/ORADB/oradata/user01.dbf
et...
ls -lht /ORADB/oradata/ORADB/ total 6.1G -rw-r-----. 1 oracle oinstall 51M Jul 23 09:43 redo03.log -rw-r-----. 1 oracle oinstall 4.6G Jul 23 09:43 system01.dbf -rw-r-----. 1 oracle oinstall 451M Jul 23 09:43 undotbs01.dbf -rw-r-----. 1 oracle oinstall 551M Jul 23 09:35 sysaux01.dbf -rw-r-----. 1 oracle oinstall 51M Jul 23 09:10 redo02.log -rw-r-----. 1 oracle oinstall 51M Jul 23 09:10 redo01.log -rw-r-----. 1 oracle oinstall 351M Jul 22 10:09 temp01.dbf ls -lht /u02/ORADB/oradata/ total 1.4G -rw-r-----. 1 oracle oinstall 1.4G Jul 23 09:40 user01.dbf
Et voila, mon datafile a bien été déplacé pendant que mes données restaient accessibles !
Qui peut le plus peut le moins, donc avec cette fonctionnalité, on peut
-1/ juste renommer le datafile.
-2/ Egalement déplacer les datafiles concernant les tablespaces SYSTEM & SYSAUX
-3/ Via l'option KEEP en fin de ligne permet de faire conserver une copie du fichier à son emplacement d'origine.
-4/ Dans le cas de l'utilisation d'un flashback database, le fichier ne sera pas remis à son emplacement initial.
@++ LAO
Hello,
Continuons un peu avec datapump et ses nouveautés que peut être un jour vous auriez aimé avoir dans une version précédente. Il m'est déjà arrivé lors de batch de nuit incluant des exports / imports d'avoir des temps de traitement différents d'un jour sur l'autre que ce soit sur un export ou un import, et j'avoue que j'aurai assez apprécié avoir dans mes logs associés un peu plus d'informations.... Et bien maintenant c'est possible
le premier paramètre "LOGTIME" va ajouter au debut de chaque ligne l'heure de fin du traitement de l'opération en cours... Cool !
Ce paramètre peut prendre 4 valeurs.
-1/ NONE => aucun logs supplémentaire, si vous préférez rester dans le brouillard.
-2/ STATUS => l'information ne sera qu'à l'écran, mais pas dans le fichier de log.
-3/ LOGFILE => Vous l'aurez compris, cette fois l'information en sera que le fichier de log.
-4/ ALL => la totale... à l'écran et dans le log !
Un petit exemple...
impdp system/****** dumpfile=exp.dmp logfile=exp.log schemas=lao remap_schema=lao:lao_imp directory=exports logtime=ALL Import: Release 12.1.0.1.0 - Production on Mon Jul 22 09:57:52 2013 Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options 22-JUL-13 09:57:55.271: Master table "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully loaded/unloaded 22-JUL-13 09:57:55.545: Starting "SYSTEM"."SYS_IMPORT_SCHEMA_01": system/******** dumpfile=exp.dmp logfile=exp.log schemas=lao remap_schema=lao:lao_imp directory=exports logtime=ALL 22-JUL-13 09:57:55.581: Processing object type SCHEMA_EXPORT/USER 22-JUL-13 09:57:55.662: Processing object type SCHEMA_EXPORT/SYSTEM_GRANT 22-JUL-13 09:57:55.690: Processing object type SCHEMA_EXPORT/DEFAULT_ROLE 22-JUL-13 09:57:55.707: Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA 22-JUL-13 09:57:55.729: Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA 22-JUL-13 09:57:55.811: Processing object type SCHEMA_EXPORT/TABLE/TABLE 22-JUL-13 09:57:55.901: Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA 22-JUL-13 09:58:09.093: . . imported "LAO_IMP"."T" 133.2 MB 14999990 rows 22-JUL-13 09:58:22.674: . . imported "LAO_IMP"."T1" 133.2 MB 14999990 rows 22-JUL-13 09:58:22.692: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX 22-JUL-13 09:58:51.236: Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS 22-JUL-13 09:58:51.245: Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS 22-JUL-13 09:58:51.249: Processing object type SCHEMA_EXPORT/STATISTICS/MARKER 22-JUL-13 09:59:01.170: Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully completed at Mon Jul 22 09:59:01 2013 elapsed 0 00:01:07
Pas belle la vie... enfin presque, car pour avoir la durée d'une étape, je suis obligé de faire des soustractions entre des heures. Pas de panique, c'est maintenant qu'intervient le paramètre METRICS qui peut prendre la valeur YES ou NO(par défaut).
On remet ca !
sqlplus /nolog SQL*Plus: Release 12.1.0.1.0 Production on Mon Jul 22 09:40:10 2013 Copyright (c) 1982, 2013, Oracle. All rights reserved. SQL> connect / As sysdba Connected. SQL> drop user lao_imp cascade; User dropped. exit; impdp system/***** dumpfile=exp.dmp logfile=exp.log schemas=lao remap_schema=lao:lao_imp directory=exports logtime=ALL metrics=yes Import: Release 12.1.0.1.0 - Production on Mon Jul 22 10:07:22 2013 Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options 22-JUL-13 10:07:24.503: Startup took 1 seconds 22-JUL-13 10:07:25.111: Master table "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully loaded/unloaded 22-JUL-13 10:07:25.319: Starting "SYSTEM"."SYS_IMPORT_SCHEMA_01": system/******** dumpfile=exp.dmp logfile=exp.log schemas=lao remap_schema=lao:lao_imp directory=exports logtime=ALL metrics=yes 22-JUL-13 10:07:25.350: Processing object type SCHEMA_EXPORT/USER 22-JUL-13 10:07:25.427: Completed 1 USER objects in 0 seconds 22-JUL-13 10:07:25.429: Processing object type SCHEMA_EXPORT/SYSTEM_GRANT 22-JUL-13 10:07:25.457: Completed 2 SYSTEM_GRANT objects in 0 seconds 22-JUL-13 10:07:25.458: Processing object type SCHEMA_EXPORT/DEFAULT_ROLE 22-JUL-13 10:07:25.475: Completed 1 DEFAULT_ROLE objects in 0 seconds 22-JUL-13 10:07:25.477: Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA 22-JUL-13 10:07:25.495: Completed 1 TABLESPACE_QUOTA objects in 0 seconds 22-JUL-13 10:07:25.497: Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA 22-JUL-13 10:07:25.565: Completed 1 PROCACT_SCHEMA objects in 0 seconds 22-JUL-13 10:07:25.584: Processing object type SCHEMA_EXPORT/TABLE/TABLE 22-JUL-13 10:07:25.667: Completed 2 TABLE objects in 0 seconds 22-JUL-13 10:07:25.676: Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA 22-JUL-13 10:07:36.248: . . imported "LAO_IMP"."T" 133.2 MB 14999990 rows in 11 seconds 22-JUL-13 10:07:49.402: . . imported "LAO_IMP"."T1" 133.2 MB 14999990 rows in 13 seconds 22-JUL-13 10:07:49.419: Processing object type SCHEMA_EXPORT/TABLE/INDEX/INDEX 22-JUL-13 10:08:18.834: Completed 1 INDEX objects in 29 seconds 22-JUL-13 10:08:18.835: Processing object type SCHEMA_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS 22-JUL-13 10:08:18.839: Completed 1 INDEX_STATISTICS objects in 0 seconds 22-JUL-13 10:08:18.845: Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS 22-JUL-13 10:08:18.849: Completed 2 TABLE_STATISTICS objects in 0 seconds 22-JUL-13 10:08:18.850: Processing object type SCHEMA_EXPORT/STATISTICS/MARKER 22-JUL-13 10:08:28.793: Completed 1 MARKER objects in 10 seconds 22-JUL-13 10:08:28.815: Completed 2 SCHEMA_EXPORT/TABLE/TABLE_DATA objects in 24 seconds 22-JUL-13 10:08:28.841: Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully completed at Mon Jul 22 10:08:28 2013 elapsed 0 00:01:05
Plutôt sympa tout cela... des heures de début et de fin, des durées... Tout ce dont on à besoin pour investiguer...
@++
LAO
Hello !!
Et c'est donc parti avec la très attendue 12c. Dans les nouveautés de la 12c, il y en quelques unes qui m'ont fait plaisir non pas que les autres ne me plaisent pas, mais juste parce que sur les versions antérieures, il m'est arrivé de me dire "Et si je pouvais faire cela simplement....".
Dans la série de ces nouveautés, il y a par exemple la possibilité d'effectuer un import en ne générant pas d'archives log...
La preuve par l'exemple...
Histoire d’illustrer cette nouvelle fonctionnalité, il convient évidemment:
-1/ Ca va de soit, mais ca va mieux en le disant... La base doit être en archivelog !
-2/ D'avoir un schema de test avec quelques données... histoire de générer des archives lors d'un import
Je vais donc commmencer par faire un export de mon schema de test (lao).
expdp parfile=exp.par Export: Release 12.1.0.1.0 - Production on Sun Jul 21 20:57:11 2013 Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** parfile=exp.par Estimate in progress using BLOCKS method... Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA Total estimation using BLOCKS method: 368 MB Processing object type SCHEMA_EXPORT/USER Processing object type SCHEMA_EXPORT/SYSTEM_GRANT Processing object type SCHEMA_EXPORT/DEFAULT_ROLE Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA Processing object type SCHEMA_EXPORT/TABLE/TABLE Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS Processing object type SCHEMA_EXPORT/STATISTICS/MARKER . . exported "LAO"."T" 133.2 MB 14999990 rows . . exported "LAO"."T1" 133.2 MB 14999990 rows Master table "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully loaded/unloaded ****************************************************************************** Dump file set for SYSTEM.SYS_EXPORT_SCHEMA_01 is: /ORADB/dump/exp.dmp Job "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully completed at Sun Jul 21 20:57:42 2013 elapsed 0 00:00:28
Pour la petite histoire, le contenu du fichier exp.par
userid=system/****** schemas=lao directory=exports dumpfile=exp.dmp
Maintenant que nous avons notre fichier d'export, nous allons commencer par faire un import. J'ai choisi d'importer dans un nouveau schema via la clause remap_schemas
impdp parfile=imp.par Import: Release 12.1.0.1.0 - Production on Sun Jul 21 21:03:03 2013 Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded Starting "SYSTEM"."SYS_IMPORT_FULL_01": system/******** parfile=imp.par Processing object type SCHEMA_EXPORT/USER Processing object type SCHEMA_EXPORT/SYSTEM_GRANT Processing object type SCHEMA_EXPORT/DEFAULT_ROLE Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA Processing object type SCHEMA_EXPORT/TABLE/TABLE Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA . . imported "LAO_IMP"."T" 133.2 MB 14999990 rows . . imported "LAO_IMP"."T1" 133.2 MB 14999990 rows Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS Processing object type SCHEMA_EXPORT/STATISTICS/MARKER Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at Sun Jul 21 21:03:45 2013 elapsed 0 00:00:40
De la même façon, ci-dessous le contenu du fichier imp.par
userid=system/******* remap_schema=lao:lao_imp directory=exports dumpfile=exp.dmp
Ne perdons pas de vue, l'objectif de la démonstration, et allons jeter un œil ou sont stockés mes archives logs.
ls -lht /ORADB/arch/ total 358M -rw-r-----. 1 oracle oinstall 45M Jul 21 21:03 1_258_820855098.arc -rw-r-----. 1 oracle oinstall 45M Jul 21 21:03 1_257_820855098.arc -rw-r-----. 1 oracle oinstall 45M Jul 21 21:03 1_256_820855098.arc -rw-r-----. 1 oracle oinstall 45M Jul 21 21:03 1_255_820855098.arc -rw-r-----. 1 oracle oinstall 45M Jul 21 21:03 1_254_820855098.arc -rw-r-----. 1 oracle oinstall 45M Jul 21 21:03 1_253_820855098.arc -rw-r-----. 1 oracle oinstall 45M Jul 21 21:03 1_252_820855098.arc -rw-r-----. 1 oracle oinstall 45M Jul 21 21:03 1_251_820855098.arc
Ma base étant en archivelog, c'est tout à fait normalement que mon import a généré son lot d'archives. 8 pour être précis, soit un total de 358 MO. Nous allons maintenant refaire la même manipulation en supprimant au préalable le user lao_imp utilisé pour ce premier import et ajoutant dans le fichie imp.par la ligne suivante: transform=disable_archive_logging:y
sqlplus /nolog SQL*Plus: Release 12.1.0.1.0 Production on Sun Jul 21 21:11:05 2013 Copyright (c) 1982, 2013, Oracle. All rights reserved. SQL> connect / as sysdba Connected. SQL> drop user lao_imp cascade; User dropped.
Histoire de pouvoir plus facilement controler la différence, je vais également supprimer les archives logs présentes
rm /ORADB/arch/*.arc
ou plus proprement et plus secure...
rman target / Recovery Manager: Release 12.1.0.1.0 - Production on Sun Jul 21 21:15:15 2013 Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved. connected to target database: ORADB (DBID=2574119866) RMAN> delete archivelog all; using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=369 device type=DISK List of Archived Log Copies for database with db_unique_name ORADB ===================================================================== Key Thrd Seq S Low Time ------- ---- ------- - --------- 216 1 251 A 21-JUL-13 Name: /ORADB/arch/1_251_820855098.arc 217 1 252 A 21-JUL-13 Name: /ORADB/arch/1_252_820855098.arc 218 1 253 A 21-JUL-13 Name: /ORADB/arch/1_253_820855098.arc 219 1 254 A 21-JUL-13 Name: /ORADB/arch/1_254_820855098.arc 220 1 255 A 21-JUL-13 Name: /ORADB/arch/1_255_820855098.arc 221 1 256 A 21-JUL-13 Name: /ORADB/arch/1_256_820855098.arc 222 1 257 A 21-JUL-13 Name: /ORADB/arch/1_257_820855098.arc 223 1 258 A 21-JUL-13 Name: /ORADB/arch/1_258_820855098.arc Do you really want to delete the above objects (enter YES or NO)? yes deleted archived log archived log file name=/ORADB/arch/1_251_820855098.arc RECID=216 STAMP=821394190 deleted archived log archived log file name=/ORADB/arch/1_252_820855098.arc RECID=217 STAMP=821394191 deleted archived log archived log file name=/ORADB/arch/1_253_820855098.arc RECID=218 STAMP=821394195 deleted archived log archived log file name=/ORADB/arch/1_254_820855098.arc RECID=219 STAMP=821394197 deleted archived log archived log file name=/ORADB/arch/1_255_820855098.arc RECID=220 STAMP=821394204 deleted archived log archived log file name=/ORADB/arch/1_256_820855098.arc RECID=221 STAMP=821394207 deleted archived log archived log file name=/ORADB/arch/1_257_820855098.arc RECID=222 STAMP=821394211 deleted archived log archived log file name=/ORADB/arch/1_258_820855098.arc RECID=223 STAMP=821394213 Deleted 8 objects
Et c'est reparti pour un import ! (n'oubliez pas de modifier votre fichier imp.par et y ajouter transform=disable_archive_logging:y)
impdp parfile=imp.par Import: Release 12.1.0.1.0 - Production on Sun Jul 21 21:16:55 2013 Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/unloaded Starting "SYSTEM"."SYS_IMPORT_FULL_01": system/******** parfile=imp.par Processing object type SCHEMA_EXPORT/USER Processing object type SCHEMA_EXPORT/SYSTEM_GRANT Processing object type SCHEMA_EXPORT/DEFAULT_ROLE Processing object type SCHEMA_EXPORT/TABLESPACE_QUOTA Processing object type SCHEMA_EXPORT/PRE_SCHEMA/PROCACT_SCHEMA Processing object type SCHEMA_EXPORT/TABLE/TABLE Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA . . imported "LAO_IMP"."T" 133.2 MB 14999990 rows . . imported "LAO_IMP"."T1" 133.2 MB 14999990 rows Processing object type SCHEMA_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS Processing object type SCHEMA_EXPORT/STATISTICS/MARKER Job "SYSTEM"."SYS_IMPORT_FULL_01" successfully completed at Sun Jul 21 21:17:15 2013 elapsed 0 00:00:18
Et dans la foulée, une petite vérification au niveau des mes archives log...
ls -lht /ORADB/arch/ total 0
Comme attendu, plus aucune archive générée.... On notera également que la durée d'import a été diminué de moitie... Ce qui n'est pas négligeable.
En débutant mes tests, je m'étais dis tout betement que j'allais faire un remap_table pour mon import... et à ma grande surprise, j'ai constaté qu'en utilisant la clause remap_table, l'atttribut disbale_archive_logging n'avait aucun effet... Normal, bug, ai je raté quelque chose... A ce stade, je n'ai pas la réponse.
Normalement (c'est un prérequis), dans un environnement dataguard, la base de données est en mode "FORCE LOGGING" et par conséquent, cette nouvelle fonctionnalité de la 12c ne vous sera d'aucune utilité dans un environnement dataguard !
Si les données importées sont importantes et persistantes, il ne faudrait pas trop tarder à faire un backup full de votre base....
@ Bientôt, LAO