Documente Academic
Documente Profesional
Documente Cultură
Contents
1. Overview
2. Introduction to Transportable Tablespaces
3. Using Transportable Tablespaces
Overview
Oracle's Transportable Tablespace is one of those much awaited features that was introduced in
Oracle8i (8.1.5) and is commonly used in Data Warehouses (DW). Using transportable tablespaces is
much faster than using other utilities like export/import, SQL*Plus copy tables, or backup and
recovery options to copy data from one database to another.
This article provides a brief introduction into configuring and using transportable tablespaces.
• The use of transportable tablespaces are much faster than using export/import, SQL*Plus copy
tables, or backup and recovery options to copy data from one database to another.
• A transportable tablespace set is defined as two components:
o All of the datafiles that make up the tablespaces that will be moved.
AND
o An export that contains the data dictionary information about those tablespaces.
• COMPATIBLE must be set in both the source and target database to at least 8.1.
• When transporting a tablespace from an OLTP system to a data warehouse using the
Export/Import utility, you will most likely NOT need to transport TRIGGER and
CONSTRAINT information that is associated with the tables in the tablespace you are
exporting. That is, you will set the TRIGGERS and CONSTRAINTS Export utility parameters
equal to "N".
• The data in a data warehouse is inserted and altered under very controlled circumstances and
does not require the same usage of constraints and triggers as a typical operational system
does.
• It is common and recommended though that you use the GRANTS option by setting it to Y.
• The TRIGGERS option is new in Oracle8i for use with the export command. It is used to
control whether trigger information, associated with the tables in a tablespace, are included in
the tablespace transport.
Explanation: The metadata exported from the target database does not contain enough
information to create the user in the target database. The reason is that, if the metadata
contained the user details, it might overwrite the privileges of an existing user in the target
database.
(i.e. If the user by the same name already exists in the target database)
By not maintaining the user details, we preserve the security of the database.
In this example, we will be transporting the tablespaces, "FACT1, FACT2, and FACT_IDX" from a
database named DWDB to REPORTDB. The user that owns these tables will be "DW" and password "DW".
To verify that all tablespaces to transport are self-contained, we can use the TRANSPORT_SET_CHECK
procedure within the DBMS_TTS PL/SQL Package. The first parameter to this procedure is a list of the
tablespaces to transport. Keep in mind that all indexes for a table, partitions, and LOB column
segments in the tablespace must also reside in the tablespace set. The second parameter to this
procedure is a boolean value that indicates whether or not to check for referential integrity.
SQL> connect sys/change_on_install@dwdb as sysdba
VIOLATIONS
--------------------------------------------------------------------------------
Index DW.DEPT_PK in tablespace FACT_IDX enforces primary constriants of table D
W.DEPT in tablespace FACT1
no rows selected
To generate a Transportable Tablespace Set, you will need to perform the following:
1. Place all tablespace within the tablespace set in READ ONLY mode.
2. Use Export to gather tablespace data-dictionary information.
3. Copy datafiles and the export dump from the source location to the target location.
4. Place all tablespace within the tablespace set back to READ/WRITE.
% exp
userid=\"sys/change_on_install@dwdb as sysdba\"
transport_tablespace=y
tablespaces=fact1, fact2, fact_idx
triggers=y
constraints=y
grants=y
file=fact_dw.dmp
% cp /u10/app/oradata/DWDB/fact1_01.dbf /u10/app/oradata/REPORTDB/fact1_01.dbf
% cp /u10/app/oradata/DWDB/fact2_01.dbf /u10/app/oradata/REPORTDB/fact2_01.dbf
% cp /u09/app/oradata/DWDB/fact_idx01.dbf
/u09/app/oradata/REPORTDB/fact_idx01.dbf
To actually transport the tablespace, this is nothing more than copying (or FTP'ing) all tablespace set
datafiles to be put in their proper location on the target database. In the section previous to this, we did
that with the cp command in UNIX.
In some cases this would be necessary if the files where copied off to a staging area in the previous
step.
Before actually importing the tablespace(s) into the target database, you will need to ensure that all
users that own segments in the imported tablespaces exist. For this example, the only user that owns
segments in the exported tablespaces is DW. I will create this user:
% sqlplus "sys/change_on_install@reportdb as sysdba"
SQL> create user dw identified by dw default tablespace users;
SQL> grant dba, resource, connect to dw;
SQL> exit
We now use the Import utility to bring the tablespace set's data-dictionary information into the target
database.
% imp
userid=\"sys/change_on_install@reportdb as sysdba\"
transport_tablespace=y
datafiles='/u10/app/oradata/REPORTDB/fact1_01.dbf',
'/u10/app/oradata/REPORTDB/fact2_01.dbf',
'/u09/app/oradata/REPORTDB/fact_idx01.dbf'
file=fact_dw.dmp
Final Cleanup
When the tablespaces are successfully imported into the target database, they are in READ ONLY
mode. If you intend to use the tablespaces for READ WRITE, you will need to manually alter them:
% sqlplus "sys/change_on_install@reportdb as sysdba"
SQL> ALTER TABLESPACE fact1 READ WRITE;
SQL> ALTER TABLESPACE fact2 READ WRITE;
SQL> ALTER TABLESPACE fact_idx READ WRITE;
SQL> exit