tablespace point in time recovery for not self-contained tablespaces

  • From: Ls Cheng <exriscer@xxxxxxxxx>
  • To: Oracle Mailinglist <oracle-l@xxxxxxxxxxxxx>
  • Date: Tue, 7 Mar 2017 21:04:45 +0100

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

Other related posts: