RE: Duplicate DB, Bypass Contained Tablespace Check?
- From: "Holvoet, Jo" <jo.holvoet@xxxxxxxxxxxxx>
- To: <kellyn.potvin@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 10 Nov 2011 09:32:12 +0100
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Kellyn Pot'vin
Sent: woensdag 9 november 2011 19:49
To: oracle-l@xxxxxxxxxxxxx
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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
