RE: Duplicate DB, Bypass Contained Tablespace Check?

From: Holvoet, Jo <jo.holvoet_at_thomascook.be>
Date: Thu, 10 Nov 2011 09:32:12 +0100
Message-ID: <CF9A39CD0F65EA49ADF70FCBF9BC2FF7029CE208_at_SW-GNETCW-MBX02.tcads.thomascook.com>



Kellyn,

Shouldn't the tablespaces in question be contained in a single call to DBMS_TTS.TRANSPORT_SET_CHECK, e.g. :

exec sys.DBMS_TTS.TRANSPORT_SET_CHECK('MV_DATA1,MEDIUM_IDX',true);

At least, that's the way I read the docs (and it wouldn't be the first time I read them wrong ...)

mvg / regards,
Jo Holvoet    

-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Kellyn Pot'vin Sent: woensdag 9 november 2011 19:49
To: oracle-l_at_freelists.org
Subject: Duplicate DB, Bypass Contained Tablespace Check?

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 self-contained
The following materialized objects were found in skipped tablespaces
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 command
     Violation:

ORA-39907: Index DW_USER.JWS_XX_IDX2 in tablespace MEDIUM_IDX points to table DW_M.JWS_STAGE2 in tablespace M_DATA1.
     Violation:

ORA-39907: Index DW_USER.JWS_XX_IDX3 in tablespace MEDIUM_IDX points to table DW_M.JWS_STAGE3 in tablespace M_DATA1.
     Violation:

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:
exec sys.DBMS_TTS.TRANSPORT_SET_CHECK('MV_DATA1',true); exec sys.DBMS_TTS.TRANSPORT_SET_CHECK('MEDIUM_IDX',true);

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 DBAKevlar.com

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l
Received on Thu Nov 10 2011 - 02:32:12 CST

Original text of this message