In earlier versions the RMAN DUPLICATE database command was a push-based method. One of the new features in Oracle 12c is that it has been changed to a pull-based method which has many advantages. Let us note the difference between the two methods.
In the earlier push-based method, the source database transfers the required database files to the auxiliary database as image copies. Now let us say we had a tablespace which had a 10GB data file, but the tablespace only contained say about 1 GB of data. Regardless, since it is an image copy, the entire 10 GB data file had to be copied over the network.
Now in Oracle 12c RMAN performs active database duplication using backup sets and not image copies. Taking the earlier example of a tablespace having a 10GB data file but say having only 1 GB of occupied data, only the 1 GB is now copied over the network as a backup set and not the entire 10 GB data file.
With backupsets there are a number of advantages.
So now in Oracle 12c this is what is new in the DUPLICATE …. FROM ACTIVE DATABASE command. And these new features certainly are providing advantages over the earlier pre-12c method.
- RMAN can employ unused block compression while creating backups, thus reducing the size of backups that are transported over the network (USING BACKUPSET, USING COMPRESSED BACKUPS clause).
- Using multi-section backups, backup sets can be created in parallel on the source database (SECTION SIZE clause).
- In addition we can also encrypt backup sets created on the source database via the SET ENCRYPTION command.
Let us look at an example using the pull-based method to create a duplicate database using RMAN backupsets from an active database.
Let us assume source database name is BSPRD and we are creating a clone of this database.
So what all preparation work we have to do for this RMAN Duplicate to work? – same as 11g – this part has not changed.
First and most important thing to do is to do the network part of the work.
Add a static entry in the listener.ora on the target and in the tnsnames.ora file on both database source and target servers add a TNS alias.
Then copy the password file from source to target and rename the file on the target if the ORACLE_SID on target is different to the source.
Create any required directories on the destination host as required if the directory path on the source and target are going to be different – for example we may need to create a directory for audit_dump_dest on the target.
If the ASM disk group names are different then we may have to connect via asmcmd on the target and create any directories we require.
Also don’t forget the DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT parameters in the target database parameter file if the directory structure is different on the target as compared to the source.
When using the SECTION SIZE parameter take into account the sizes of the data files and the parallelism we are going to use.
In the example I have shown the RMAN parallelism has been set to 4 and two of the bigger data files are 2.2 GB and 1.5 GB – so I have used a section size of 500 MB.
Note – also now when you create the duplicate database via RMAN, we cannot just issue the “TARGET /” command in RMAN.
We have to explicitly provide the user, password as well as the TNS alias for both the target database as well as the auxiliary database.
Like for example:
rman target sys/sys_passwd@bsprd auxiliary sys/sys_passwd@bsprd_dup
Note the RMAN DUPLICATE DATABASE command – it includes the USING BACKUPSET and SECTION SIZE clauses.
Recovery Manager: Release 12.1.0.2.0 - Production on Thu Aug 27 05:27:22 2015 Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved. connected to target database: BSPRD (DBID=3581332368) connected to auxiliary database: BSPRD (not mounted) RMAN> duplicate target database to bsprd from active database 2> using backupset 3> section size 500m;
Note the 4 auxiliary channels being created because we have configured RMAN with a parallelism of 4.
Starting Duplicate Db at 27-AUG-15 using target database control file instead of recovery catalog allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=19714 device type=DISK allocated channel: ORA_AUX_DISK_2 channel ORA_AUX_DISK_2: SID=19713 device type=DISK allocated channel: ORA_AUX_DISK_3 channel ORA_AUX_DISK_3: SID=6 device type=DISK allocated channel: ORA_AUX_DISK_4 channel ORA_AUX_DISK_4: SID=2820 device type=DISK current log archived
The SYSTEM tablespace data file was about 2.2 GB in my case. So we can see that RMAN has split this 2.2 GB based on the section size we allocated which was 500 MB. We have 4 auxiliary channels working on ‘sections’ of the single data file in parallel.
channel ORA_AUX_DISK_1: starting datafile backup set restore channel ORA_AUX_DISK_1: using network backup set from service bsprd channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set channel ORA_AUX_DISK_1: restoring datafile 00001 to +OEM_DATA/BSPRD/DATAFILE/system.302.888816535 channel ORA_AUX_DISK_1: restoring section 1 of 5 channel ORA_AUX_DISK_3: specifying datafile(s) to restore from backup set channel ORA_AUX_DISK_3: restoring datafile 00001 to +OEM_DATA/BSPRD/DATAFILE/system.302.888816535 channel ORA_AUX_DISK_3: restoring section 2 of 5 channel ORA_AUX_DISK_4: restore complete, elapsed time: 00:00:04 .... .... channel ORA_AUX_DISK_4: using network backup set from service bsprd channel ORA_AUX_DISK_4: specifying datafile(s) to restore from backup set channel ORA_AUX_DISK_4: restoring datafile 00001 to +OEM_DATA/BSPRD/DATAFILE/system.302.888816535 channel ORA_AUX_DISK_4: restoring section 5 of 5 channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:10
