Duplicate DB, Bypass Contained Tablespace Check?

  • From: Kellyn Pot'vin <kellyn.potvin@xxxxxxxxx>
  • To: "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 9 Nov 2011 10:48:54 -0800 (PST)

I have a weekly process that takes a duplicate with excluded tablespace list, 
once restored, then we run a clean up script for the objects that violate what 
is causing me a headache with the 11g upgrade of the auxiliary database I'm 
currently testing from. I appreciate that 11g would like to check first for me 
if the tablespaces I'm excluding are going to impact the other ones retained, 
but I'm taking care of that post the duplicate and would really like a 
work-around! :)

Does anybody know what the correct work-around for the tablespace checks are 
when performing an RMAN duplicate?

database mountedChecking that duplicated tablespaces are
The following materialized objects were found in skipped
Materialized table MV_XXX1 on tablespace MV_DATA1 
Materialized table MV_XXX2 on tablespace MV_DATA2 ...so on, so forth...

following errors need to be fixed before peforming this
ORA-39907: Index DW_USER.JWS_XX_IDX2 in tablespace MEDIUM_IDX points to
table DW_M.JWS_STAGE2 in tablespace M_DATA1.
ORA-39907: Index DW_USER.JWS_XX_IDX3 in tablespace MEDIUM_IDX points to
table DW_M.JWS_STAGE3 in tablespace M_DATA1.
ORA-39907: Index DW_USER.PML_IDX02 in tablespace DB_INDX2 points to table
DW_USER.PML_TBL in tablespace PML_DATA1.....so on, so forth...

I've tried the following:

Tried new backup, attempted process and failed again!  This is the correct 
workaround from what I can see to bypass this check.  I need to bypass the 
checks for both the tablespaces and the mviews.  We would like to keep this 
process as similar to the current 10g process as possible, so an answer would 
be great.  I'm sure I'm just not searching with the right term in my rushed 
window of time.

Kellyn Pot'Vin
Sr. Database Administrator and Developer

Other related posts: