Not sure if this will help you but
we used to duplicate database and skip a whole bunch of tablespaces during
that duplication...But these tablespaces were all linked (partitioned
tables).
this worked fine until we moved to oracle 11 when the duplicate would
complain about the the tablespaces not being self contained.
Solution was to NOT connect to the target database...
For us the duplicate would fail at the end because it could not drop the
skipped tablespaces but that was fine we manually ran some scripts to fix
it up.
Hope that gives you another entry point for troubleshooting
Jack van Zanen
-------------------------
This e-mail and any attachments may contain confidential material for the
sole use of the intended recipient. If you are not the intended recipient,
please be aware that any disclosure, copying, distribution or use of this
e-mail or any attachment is prohibited. If you have received this e-mail in
error, please contact the sender and delete all copies.
Thank you for your cooperation
On Wed, Mar 8, 2017 at 7:04 AM, Ls Cheng <exriscer@xxxxxxxxx> wrote:
Hi
Running 11.2.0.4 RAC in Linux x86-64.
One of my users asked us to restore a table from a year ago in a 8TB
database. The tablespace where the table is stored hast 70 tables and
around 120 indexes and a few LOB, the table itself has parents in other
tablespaces and child in other tablespaces. The tablespace is not a self
contained tablespace.
We would like to restore the table using tablespace point in time recovery
and according to the doc
https://docs.oracle.com/cd/E11882_01/backup.112/e10642/
rcmtspit.htm#BRADV009
We can make the tablespace self contained before run TSPITR which is what
we did, we could do this because we anspshot the database and start it in
another server. So far so good TRANSPORT_SET_VIOLATIONS is empty. But
during TSPITR when it restored system sysaux, undo and the tablespace one
of following step is EXPORT the tablespace, make it TTS, it failed
EXPDP> FLASHBACK automatically enabled to preserve database integrity.
EXPDP> Starting "SYS"."TSPITR_EXP_pfbm":
EXPDP> ORA-39123: Data Pump transportable tablespace job aborted
ORA-39187: The transportable set is not self-contained, violation list is
It is understandable because the backup is from 1 yea ago and obvisouly
the backup contains all the relations, indexes and lobs we have removed to
make TSPITR working. So this is sort of dead loop, we remove eveyrthing to
make the current tablespace self-contaned but the backup it restores isnt
so at the end of day we probably need to restore the entire 8TB database to
export a table.
So my question is. Does TSPITR work only for real SELF-CONTAINED
tablespaces? That is it is always self contained since the backups until
now. In this experience it seems to me that TSPITR is not very useful at
all. Or is there any workaround?
Thanks
