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