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