After 11.2 upgrade, RMAN-05548 when duplicating database
Here is an interesting issue I came across recently after an upgrade from 11.1 -> 11.2. This particular database has 15 development / test / qa copies and approximately 1/3 of the database is application auditing data that is generally not needed in the non-prod copies. So we skip the AUDITDATA tablespace during the duplication which makes the clonings faster and requires less disk space. In 11.1. we were able to create the duplicate databases using the following rman command
$rman target=sys@PRD1 auxiliary=/
RMAN> run {
2> set until time “TO_DATE(’01-NOV-2011 20:00:00′,’DD-MON-YYYY HH24:MI:SS’)”;
3> allocate auxiliary channel ch1 type disk;
4> duplicate target database to TST1 skip tablespace AUDITDATA;
5> }
this worked fine, rman performed the duplication, dropped the AUDITDATA tablespace and we subsequently did a CONTENT=METADATA_ONLY datapump export / import to recreate the empty objects in that tablespace and constraints (that were dropped cascade during the duplication). After the upgrade to 11.2 the exact same duplication fails with error
RMAN-05548: The set of duplicated tablespaces is not self-contained
Sure enough 11.2 has some nice RMAN enhancements
http://docs.oracle.com/cd/E11882_01/server.112/e22487/chapter1.htm
unfortunately the TTS check is preventing us from doing what we used to do. To cut a long story short the workaround is to perform the duplication without connecting to the primary database, since rman is not connected to the primary it cannot perform the TTS check which generates the error. So our clonings are now performed via
$rman auxiliary=/
RMAN> run {
2> set until time “TO_DATE(’14-FEB-2012 20:00:00′,’DD-MON-YYYY HH24:MI:SS’)”;
3> duplicate database to TST1 backup location ‘/orabackups/PRD1/rman’ skip tablespace AUDITDATA;
4>}
Notice the use of the (also new in 11.2) BACKUP LOCATION syntax which allows you to perform the duplication from any directory containing a copy of the Production backup, you no longer need to have to use the same path that the backup had used in Production.

Recent Comments