Database Reference
In-Depth Information
This simple verification showed that the index
foo_1_indx
was built in the
USER_DATA
tablespace but the corresponding
foo_1
table is in the
USERS
tablespace, which is not included
in the transportable tablespace set. You must remedy this situation before you can transport
tablespace
USER_DATA
.
It is important at this time to discuss the concept of referential integrity constraints
relative to transportable tablespace sets. By default, referential integrity constraints
are not required to be included in the transportable set; however, you can test for con-
straint containment with the
DBMS_TTS.TRANSPORT_SET_CHECK
procedure. For the fol-
lowing example, we have created the table
FOO
in the
USER_DATA
tablespace and checked
the transportability. We then add an index on
FOO
in the
USERS
tablespace and create
a primary key constraint on the indexed column. We check the transportability of the
USER_DATA
tablespace as follows:
SQL> exec dbms_tts.transport_set_check ('USER_DATA',TRUE);
PL/SQL procedure successfully completed.
SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS;
no rows selected
SQL>
SQL> CREATE INDEX SCOTT.FOO_INDX
2 ON SCOTT.FOO (X)
3 TABLESPACE USERS;
Index created.
SQL> ALTER TABLE SCOTT.FOO ADD (PRIMARY KEY (x));
Table altered.
SQL> exec dbms_tts.transport_set_check ('USER_DATA',TRUE);
PL/SQL procedure successfully completed.
SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS;
VIOLATIONS
----------------------------------------------------------
ORA-39908: Index SCOTT.FOO_INDX in tablespace USERS
enforces primary constraints
of table SCOTT.FOO in tablespace USER_DATA.
SQL>
Before we can transport the
USER_DATA
tablespace, we need to resolve this constraint issue
by including the
USERS
tablespace, by rebuilding the index into the
USER_DATA
tablespace, by
dropping the primary key constraint, or by deciding not to include constraints in the trans-
portable set.
Search WWH ::
Custom Search