Every Monday morning starts with the same routine: refreshing QA databases from PeopleSoft production. Even though the process is largely automated, the final steps typically take several hours. This is because the traditional DUPLICATE FROM ACTIVE DATABASE command performs image copies to the destination server.
However, the game has changed with Oracle Database 12c. The DUPLICATE mechanism has shifted to a "PULL" method, utilizing backup sets over the network. This evolution allows us to use USING COMPRESSED BACKUPSET and SECTION SIZE to significantly optimize the duplication process.
While the theoretical benefits of these new features are clear—shorter operation times and optimized network usage—the practical application can sometimes deviate from expectations. DBAs are notoriously careful with new features; we don't just need to know how they should work; we need to see them working reliably in the field.
I decided to put these 12c features to the test on a 2-node RAC database. While a standard duplication (without compression or section size) worked perfectly, I ran into a persistent wall when attempting to use the advanced clauses.
Every time I enabled COMPRESSED BACKUPSET or SECTION SIZE, the process failed during the recovery phase. I tested various configurations—switching from Easy Connect to TNS, trying standalone databases, and alternating between ASM and standard file systems—but the result was always the same: RMAN-06053.
RMAN-06402: Oracle instance shut down RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of Duplicate Db command at 09/08/2013 20:14:10 RMAN-05501: aborting duplication of target database RMAN-03015: error occurred in stored script Memory Script RMAN-06053: unable to perform media recovery because of missing log RMAN-06025: no backup of archived log for thread 1 with sequence 67 and starting SCN of 2178389 found to restore I have since opened a Service Request (SR) with My Oracle Support (MOS) and am currently waiting for their analysis.
Despite the issues with compression, a standard 12c active duplication is impressive. Below is the output from a successful run using the new network-based backup set method. Notice how RMAN now uses the service name to pull data directly.
[oracle@r121 ~]$ rman target sys/sys_pwd@t12 auxiliary sys/sys_pwd@c12 connected to target database: T12 (DBID=1222223202) connected to auxiliary database: T12 (not mounted) RMAN> duplicate target database to c12 from active database spfile parameter_value_convert 't12', 'c12' set db_file_name_convert 't12', 'c12' set log_file_name_convert 't12', 'c12' nofilenamecheck; Starting Duplicate Db at 06-SEP-13 ... executing Memory Script Starting restore at 06-SEP-13 channel ORA_AUX_DISK_1: starting datafile backup set restore channel ORA_AUX_DISK_1: using network backup set from service t12 channel ORA_AUX_DISK_1: restoring SPFILE ... database opened Finished Duplicate Db at 06-SEP-13 I hope to update this post soon with a definitive response from Oracle Support regarding the compression/section size errors. In the meantime, I'm curious: Do you prefer to wait for a full resolution before sharing these "unresolved" technical deep dives, or do you find value in discussing the investigation as it happens?
Ready to optimize your Oracle Database for the future?