Database Reference
In-Depth Information
OWNER NAME
------------------------------ ----------------------------
TABLESPACE_NAME TO_CHAR(CREATION_TI
------------------------------ -------------------
SCOTT TESTTABLE
USERS 2013-10-07:19:34:39
Rules, Rules, and More Rules
Finally, TSPITR involves a few rules you need to be aware of:
The target database must be in ARCHIVELOG mode.
You must have a backup that was taken before the point in time that you want to perform
the TSPITR.
You must have all archived redo logs generated since the last backup (complete or
incremental) up to the point to which you want to restore the transport set.
If you rename a tablespace, you cannot perform a TSPITR to any point in time before
that rename operation occurred.
If you have tables in tablespace_1 that have associated constraints in tablespace_2 ,
then you must transport both tablespaces.
If a tablespace contains the following objects, then that tablespace cannot be used
during a TSPITR:
Replicated master tables.
Incomplete tables; you must transport complete tables, including all partitions of a
partitioned table.
Any tables that contain VARRAY columns, nested tables, or external tables.
Snapshot-related objects (snapshot logs and snapshots).
Tablespaces with UNDO or rollback segments.
Any tablespace with objects owned by the SYS schema.
TSPITR Aftereffects
Some interesting things happen after a TSPITR:
If a data file was added to the tablespace on the target database after the point in time
for the recovery, then the resulting tablespace after the TSPITR process will have an
empty data file restored.
Once the TSPITR is complete, all backups associated with tablespaces in the transport
set taken before the point in time that you restored the tablespaces to are no longer
valid. You should run a backup after the TSPITR.
Search WWH ::




Custom Search