Backup and Recovery - Expert Consolidation in Oracle Database 12c - page 387

Will we be able to get the data back as it was before? One possible command to get the tables back is shown here.
It will create an auxiliary database instance using existing RMAN backups and restore it up to the SCN specified.
A Data Pump job will be started next to export the tables in the recover table clause and import it into the target
database. To prevent an error message indicating that the tables to be recovered exist, the example used the remap
table clause. Alternatively you could use the notableimport option instead which only creates the Data Pump export
file without importing it into the target database.
RMAN> recover table user1.t_1, user1.t_2, user1.t_3
2> of pluggable database pdb1
3> until scn 1993594
4> auxiliary destination '+DATA'
5> datapump destination '+DATA'
6> dump file 'user1.restore.dmp'
7> remap table user1.t_1:t_1_restore,user1.t_2:t_2_restore,user1.t_3:t_3_restore;
The command to recover the tables has a few more options. If you are using a Fast Recovery Area for example
then you do not need to specify the auxiliary destination; the temporary database files will be created in the FRA. You
can optionally specify that the data pump export file containing the tables specified in the recover table command will
not be imported in the live environment using the notableimport option.
You are not limited to recovering entire tables, if you need finer granularity then you can choose table partitions
as well. In the above example the DBA has decided to allow the import the dump file into the tables t_{1,2,3}_restore,
leaving the original tables untouched. Toward the end of the process you can clearly see the Data Pump activity:
Performing export of tables...
EXPDP> Starting "SYS"."TSPITR_EXP_iafj_nopB":
EXPDP> Estimate in progress using BLOCKS method...
EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
EXPDP> Total estimation using BLOCKS method: 33 MB
EXPDP> Processing object type TABLE_EXPORT/TABLE/TABLE
EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
EXPDP> Processing object type TABLE_EXPORT/TABLE/STATISTICS/MARKER
EXPDP> . . exported "USER1"."T_1" 8.540 MB 73754 rows
EXPDP> . . exported "USER1"."T_2" 8.540 MB 73753 rows
EXPDP> . . exported "USER1"."T_3" 8.540 MB 73753 rows
EXPDP> Master table "SYS"."TSPITR_EXP_iafj_nopB" successfully loaded/unloaded
EXPDP> ******************************************************************************
EXPDP> Dump file set for SYS.TSPITR_EXP_iafj_nopB is:
EXPDP> +DATA/user1.restore.dmp
EXPDP> Job "SYS"."TSPITR_EXP_iafj_nopB" successfully completed Sat Sep 21 22:41:23 2013 
elapsed 0 00:00:33
Export completed
This dump file which was deliberately created in ASM is subsequently imported into the life environment and the
auxiliary instance is removed. The end result is a success, as you can see for yourself:
USER1@PDB1> select count(1) from T_1_RESTORE union all
2 select count(1) from T_2_RESTORE union all
3 select count(1) from T_3_RESTORE union all
4 select count(1) from t_2 union all
5 select count(1) from t_3;